何时在 DSE 中使用 Cassandra 与 Solr？

Question

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

然而，在查询方面，实际上有两种方法：Cassandra 辅助/手动配置索引与 Solr。我想知道何时使用哪种方法以及一般的性能差异是什么，尤其是在 DSE 设置下。

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

我能想到三种不同的处理方式：

1. 在 Solr 架构中为类别和 like_count 字段声明“indexed=true”并在 Solr 中查询
2. 在 Cassandra 中使用主键（类别、like_count、id）创建非规范化表
3. 在 Cassandra 中使用主键（类别、订单、id）创建一个非规范化表，并使用外部组件（如 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。目前不建议将 vnodes 用于 Solr 数据中心。