何时在DSE中使用Cassandra vs. Solr？

Question

我正在使用DSE进行Cassandra/Solr集成,以便将数据存储在Cassandra中并在Solr中编制索引.使用Cassandra处理CRUD操作并分别使用Solr进行全文搜索是非常自然的,DSE可以真正简化Cassandra和Solr之间的数据同步.

但是,在查询方面,实际上有两种方法:Cassandra辅助/手动配置索引与Solr.我想知道何时使用哪种方法以及通常的性能差异,特别是在DSE设置下.

这是我项目中的一个示例用例.我有一个存储一些项目实体数据的Cassandra表.除了基本的CRUD操作之外,我还需要在某些字段(比如类别)上按等号检索项目,然后按某种顺序排序(在我的例子中,这是一个like_count字段).

我可以想到三种不同的方法来处理它:

1. 在Solr模式中为类别和like_count字段以及Solr中的查询声明'indexed = true'
2. 使用主键(category,like_count,id)在Cassandra中创建非规范化表
3. 使用主键(类别,顺序,ID)在Cassandra中创建非规范化表,并使用外部组件(如Spark/Storm)通过like_count对项目进行排序

第一种方法似乎是最简单的实现和维护.我只是写了一些简单的Solr访问代码,其余的繁重工作由Solr/DSE搜索处理.

第二种方法需要在创建和更新时进行手动非规范化.我还需要维护一个单独的表.还有墓碑问题,因为like_count可能会经常更新.好的部分是读取可能更快(如果没有过多的墓碑).

第三种方法可以以一个额外的分类组件为代价来减轻墓碑问题.

您认为哪种方法是最佳选择？性能有何不同？

Answer 1

Cassandra二级索引的用例有限:

1. 索引的列数不超过几列.
2. 查询中只有一个索引列.
3. 高基数数据的节点间流量过多(相对唯一的列值)
4. 低基数数据的节点间流量太多(行的高百分比将匹配)
5. 需要事先知道查询,以便围绕它们优化数据模型.

由于这些限制,应用程序通常会创建"索引表",索引表由所需的任何列索引.这要求将数据从主表复制到每个索引表,或者需要额外的查询来读取索引表,然后在从索引表中读取主键后从主表中读取实际行.必须事先手动索引多列上的查询,这使得即席查询有问题.并且任何重复的内容都必须由应用程序手动更新到每个索引表中.

除此之外......如果从适度数量的节点中选择"适度"行数,并且提前很好地指定查询而不是临时查询,它们将正常工作.

DSE/Solr更适合:

1. 索引中等数量的列.
2. 引用了多个列/字段的复杂查询 - Lucene并行匹配查询中的所有指定字段.Lucene为每个节点上的数据编制索引,因此节点并行查询.
3. 一般的即席查询,其中预先不知道精确查询.
4. 丰富的文本查询,如关键字搜索,通配符,模糊/类似,范围,不等式.

使用Solr索引会产生性能和容量成本,因此建议使用概念验证来评估需要多少额外的RAM,存储和节点,这取决于您索引的列数,索引的文本量以及任何文本过滤复杂性(例如,n-gram需要更多.)对于相对较少数量的索引列,其范围可以从25%增加到如果所有列都被索引的100%.此外,您需要有足够的节点,以便每个节点的Solr索引适合RAM,或者如果使用SSD,则大部分位于RAM中.目前,Solr数据中心不推荐使用vnodes.