solr - 何时在DSE中使用Cassandra与Solr？

Question

我正在使用DSE进行Cassandra/Solr集成，以便将数据存储在Cassandra中并在Solr中建立索引。使用Cassandra处理CRUD操作并分别使用Solr进行全文搜索是很自然的，而DSE确实可以简化Cassandra和Solr之间的数据同步。

但是，当涉及查询时，实际上有两种方法可供选择:Cassandra二级/手动配置索引与Solr。我想知道什么时候使用哪种方法，通常会有什么性能差异，尤其是在DSE设置下。

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

我可以想到三种不同的处理方式:

在Solr模式中为category和like_count字段声明'indexed = true'并在Solr中声明

使用主键(类别，like_count，id)在Cassandra中创建非规范化表

使用主键(类别，顺序，id)在Cassandra中创建非规范化表，并使用外部组件(例如Spark/Storm)按like_count

对项目进行排序

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

第二种方法要求在创建和更新时手动进行非规范化。我还需要维护一个单独的表。还有一个逻辑删除问题，因为like_count可能会经常更新。好消息是读取速度可能更快(如果没有过多的墓碑)。

第三种方法可以减轻墓碑问题，但要花费一个额外的组件进行分类。

您认为哪种方法是最佳选择？性能上有什么区别？

Answer 1

Cassandra二级索引的用例有限:

不超过几个已索引的列。

查询中只有一个索引列。

高基数数据(相对唯一的列值)的节点间流量过多

用于低基数数据的节点间流量过多(将匹配高百分比的行)

查询需要事先知道，以便可以围绕它们优化数据模型。

由于这些限制，应用程序通常会创建“索引表”，并根据需要的任何列对其进行索引。这要求要么将数据从主表复制到每个索引表，要么需要额外的查询以读取索引表，然后在从索引表中读取主键之后从主表中读取实际行。多列查询将必须事先手动索引，这使临时查询成为问题。应用程序必须手动将所有重复项更新到每个索引表中。

除此之外...在从适度的节点数中选择“适度”的行数，并且事先明确指定查询而不是临时的情况下，它们会很好地工作。

DSE/Solr更适合:

索引了中等数量的列。

引用了许多列/字段的复杂查询-Lucene并行匹配查询中的所有指定字段。 Lucene索引每个节点上的数据，因此节点并行查询。

一般情况下的临时查询，在这种情况下，事先不知道确切的查询。

富文本查询，例如关键字搜索，通配符，模糊/喜欢，范围，不等式。

使用Solr索引会产生性能和容量成本，因此建议进行概念验证，以评估需要多少额外的RAM，存储和节点，这取决于所索引的列数，索引的文本量以及任何文本过滤的复杂性(例如，n-gram都需要更多。)它的范围可以从相对少量的索引列增加25％到所有索引列都增加100％。另外，您需要有足够的节点，以使每个节点的Solr索引适合RAM，如果使用SSD，则适合大多数RAM。而且目前不建议将vnode用于Solr数据中心。