二级索引在Cassandra中是如何工作的？

Question

CREATE TABLE update_audit (
  scopeid bigint,
  formid bigint,
  time timestamp,
  record_link_id bigint,
  ipaddress text,
  user_zuid bigint,
  value text,
  PRIMARY KEY ((scopeid, formid), time)
  ) WITH CLUSTERING ORDER BY (time DESC)

CREATE INDEX update_audit_id_idx ON update_audit (record_link_id);

CREATE INDEX update_audit_user_zuid_idx ON update_audit (user_zuid);

CREATE TABLE update_audit_id_idx(
    record_link_id bigint,
    scopeid bigint,
    formid bigint,
    time timestamp
    PRIMARY KEY ((record_link_id), scopeid, formid, time)
);

CREATE TABLE update_audit_user_zuid_idx(
    user_zuid bigint,
    scopeid bigint,
    formid bigint,
    time timestamp
    PRIMARY KEY ((user_zuid), scopeid, formid, time)
);

考虑以下查询：

select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;

1. 该查询将如何在Cassandra中“在引擎盖下”执行？
2. 高基数列索引(record_link_id)将如何影响其性能？
3. Cassandra会为上述查询接触所有节点吗？为什么？
4. 先执行哪个条件，基表partition_key还是辅助索引partition_key？Cassandra将如何将这两个结果相交？

Answer 1

select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;

上面的查询将如何在Cassandra内部工作？

实际上，分区scopeid=35和formid=78005的所有数据都将返回，然后由record_link_id索引进行筛选。它将查找9897的record_link_id条目，并尝试匹配与返回的行匹配的条目，其中scopeid=35和formid=78005。将返回分区键和索引键的行的交集。

高基数列(record_link_id)索引将如何影响上述查询的查询性能？

不是。它应该只触及负责scopeid=35和formid=78005分区的节点。索引同样存储在本地，只包含对本地节点有效的条目。

在高基数列上创建索引将是最快和最好的数据模型

这里的问题是这种方法不能伸缩，如果update_audit是一个大型数据集，这种方法将会很慢。MVP Richard Low有一篇关于二级索引（Cassandra二级索引的最佳位置）的文章，特别是关于这一点：

现在，您首先使用特定分区进行限制的方法将会有所帮助（因为您的分区肯定应该适合内存）。但我觉得这里性能更好的选择是将record_link_id设置为集群键，而不是依赖于辅助索引。

编辑

当有数百万用户时，即使我们提供了主键，在低基数索引上使用索引如何扩展

请考虑以下图表，摘自Java驱动程序文档(V3.6):

基本上，分页将导致查询自行分解并返回到集群以进行下一次结果迭代。超时的可能性较小，但性能会随着总结果集的大小和集群中节点的数量而下降。

TL；DR；分布在更多节点上的html" target="_blank">请求结果越多，所需时间就越长。