【问题标题】:Are secondary indices always a bad idea in Cassandra even if I specify them in conjunction with the partitioning key in all my queries?即使我在所有查询中将二级索引与分区键一起指定,二级索引在 Cassandra 中是否总是一个坏主意?
【发布时间】:2020-03-02 23:24:54
【问题描述】:

我知道 Cassandra 中的二级索引通常不是一个好主意,因为索引本地存储在每个节点中,即不分布在集群中,这可能导致查询扫描大量节点。但是,如果我总是在查询中指定分区键并且只使用二级索引作为最终过滤器,我不明白为什么它们仍然是一个坏主意。我读过即使我指定了分区键,它们也不会随着大量数据进行扩展。这是真的?如果是那为什么?

【问题讨论】:

    标签: cassandra


    【解决方案1】:

    一般来说二级索引是个坏主意,不仅对于分布式部分,而且对于索引大小和不同值的数量,所以如果你有一个基数高或低的字段,你会花时间扫描许多行或许多列。 在处理墓碑时你也可能遇到其他问题......

    为了回答您的问题,Cassandra 中的二级索引并不能很好地扩展,但如果您使用分区键并通过它告诉 Cassandra 哪个节点有数据,它的性能会更好! 您可以在 F 部分找到更多详细信息:

    https://www.datastax.com/blog/2016/04/cassandra-native-secondary-index-deep-dive

    我希望这会有所帮助!

    【讨论】:

      【解决方案2】:

      这些人对二级索引的性能影响写了一篇很好的文章:

      https://pantheon.io/blog/cassandra-scale-problem-secondary-indexes

      主要影响(来自帖子)是二级索引对于每个节点都是本地的,因此 通过索引值满足查询,每个节点必须查询自己的记录来构建 最终结果集(与确切知道哪个节点的主键查询相反 需要查询)。因此,不仅会影响写入,还会影响读取性能 嗯。

      【讨论】:

      • 感谢拉姆的回答。但是,我在问题中表示我知道此限制,并且当您在所有查询中使用分区键时它不成立,因此很遗憾这不能回答我的问题。
      【解决方案3】:

      Cassandra 在五台机器上,具有用户 ID 的主索引和用户电子邮件的辅助索引。如果您要通过他们的 ID 或他们的主索引键来查询用户,那么环中的任何机器都会知道哪台机器有该用户的记录。 一次查询,一次从磁盘读取。但是,要通过电子邮件或二级索引值查询用户,每台机器都必须查询自己的用户记录。 一次查询,从磁盘读取五次。通过缩放系统范围内的用户数量,或通过缩放环中的机器数量,噪声与信噪比的增加和读取的整体效率下降。在某些情况下也会超时。 有关二级索引的详细说明,请参阅下面的链接。 https://dzone.com/articles/cassandra-scale-problem

      【讨论】:

      • 显式定义分区键,而不是或,二级索引是我感兴趣的情况。在这种情况下,查询不会扫描所有节点。
      猜你喜欢
      • 2014-12-13
      • 2020-07-18
      • 1970-01-01
      • 2023-04-08
      • 2014-03-05
      • 2016-09-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多