何时在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. 需要事先知道查询，以便围绕它们优化数据模型。

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

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

DSE / Solr更适合：

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

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