我使用 DSE 进行 Cassandra/Solr 集成，以便数据存储在 Cassandra 中并在 Solr 中建立索引。很自然地分别使用 Cassandra 处理 CRUD 操作和使用 Solr 进行全文搜索，并且 DSE 确实可以简化 Cassandra 和 Solr 之间的数据同步。
然而，当涉及到查询时，实际上有两种方法可以选择：Cassandra 辅助/手动配置索引与 Solr。我想知道何时使用哪种方法以及一般情况下的性能差异是什么，特别是在 DSE 设置下。
这是我的项目中的一个示例用例。我有一个 Cassandra 表存储一些项目实体数据。除了基本的 CRUD 操作之外，我还需要在某个字段（例如类别）上按相等性检索项目，然后按某种顺序排序（在我的例子中，是一个 like_count 字段）。
我可以想到三种不同的方法来处理它：
- 在 Solr 模式中为类别和 like_count 字段声明“indexed=true”并在 Solr 中查询
- 在 Cassandra 中使用主键（类别、like_count、id）创建非规范化表
- 在Cassandra中创建一个带有主键（category、order、id）的非规范化表，并使用外部组件（例如Spark/Storm）按like_count对项目进行排序
第一种方法似乎是最容易实现和维护的。我只编写一些简单的 Solr 访问代码，其余的繁重工作由 Solr/DSE 搜索处理。
第二种方法需要在创建和更新时手动进行反规范化。我还需要维护一个单独的表。还有墓碑问题，因为 like_count 可能会频繁更新。好的部分是读取可能会更快（如果没有过多的墓碑）。
第三种方法可以缓解墓碑问题，但需要一个额外的排序组件。
您认为哪种方法是最佳选择？性能上有什么区别？
Cassandra 二级索引的用例有限：
- 不超过几列索引。
- 查询中只有一个索引列。
- 高基数数据的节点间流量过多（相对唯一的列值）
- 低基数数据的节点间流量过多（匹配的行百分比较高）
- 需要提前了解查询，以便可以围绕它们优化数据模型。
由于这些限制，应用程序通常会创建“索引表”，并按所需的任何列进行索引。这需要将数据从主表复制到每个索引表，或者需要额外的查询来读取索引表，然后在从索引表读取主键后从主表读取实际行。对多个列的查询必须提前手动建立索引，这使得即席查询出现问题。并且任何重复项都必须由应用程序手动更新到每个索引表中。
除此之外......在从适度数量的节点中选择“适度”数量的行的情况下，它们将正常工作，并且查询是提前指定的而不是临时的。
DSE/Solr 更适合：
- 中等数量的列被索引。
- 引用大量列/字段的复杂查询 - Lucene 并行匹配查询中的所有指定字段。 Lucene 对每个节点上的数据建立索引，因此节点可以并行查询。
- 一般而言，即席查询，其中预先不知道精确的查询。
- 富文本查询，例如关键字搜索、通配符、模糊/类似、范围、不等式。
使用 Solr 索引会产生性能和容量成本，因此建议进行概念验证实施来评估需要多少额外 RAM、存储和节点，这取决于您索引的列数、索引的文本量以及任何文本过滤复杂性（例如，n 元语法需要更多。）其范围可能是从相对较少数量的索引列增加 25% 到如果所有列都建立索引则增加 100%。此外，您需要有足够的节点，以便每个节点的 Solr 索引适合 RAM，或者如果使用 SSD，则大部分适合 RAM。目前不建议将 vnode 用于 Solr 数据中心。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
