【问题标题】:IN query on secondary index in cassandra when partition key is specified指定分区键时对 cassandra 中的二级索引进行查询
【发布时间】:2020-07-18 20:24:54
【问题描述】:

我正在使用一个在 cassandra 中使用二级索引以及复合主键的系统,例如

CREATE TABLE table (
  a bigint,
  b bigint,
  c bigint,
  PRIMARY KEY (a, b, c)
) WITH CLUSTERING ORDER BY (b ASC, c ASC)
CREATE INDEX secondary_index ON table (c);

应用程序中使用该表的操作之一是获取指定分区键和二级索引键的行数(通常为数十行)。目前,它对每个(分区键,辅助键)对执行一个查询,并行,工作正常,例如:

select * from table where a = ? and c = ?;

但是,我注意到系统的工作负载在大多数情况下,请求行之间的分区键存在大量重叠,有时其中一半以上具有相同的分区键。因此,我认为每个分区键执行一个查询可能更有效,在辅助键上使用 IN 子句,在大多数情况下将整体查询数量减少到个位数,并减少集群上的读取查询开销。

但是,至少从cqlsh执行,这似乎是不允许的:

select * from table where a = ? and c in (...);
InvalidRequest: Error from server: code=2200 [Invalid query] message="PRIMARY KEY column "c" cannot be restricted as preceding column "b" is not restricted"

这是不允许的,我必须继续进行个别查询吗?是否有某种原因实际上不会更有效?还是这只是CQL的限制,IN查询不能使用二级索引?可能有问题,因为二级索引键也在主键中,Cassandra 尝试使用它而不是二级索引?

【问题讨论】:

  • 使用二级索引有不同的限制,这可能取决于 Cassandra 的版本——你用的是什么?另外,每个分区有多少行?有时可以使用allow filtering 执行
  • cassandra 版本是 3.0.17,我所做的尝试是使用 cqlsh 5.0.1。每个分区的行数各不相同,但通常为数百或数千,甚至高达数十万。考虑到二级索引,并且考虑到与请求的行数相关的分区大小,查询似乎不应该需要过滤,我认为允许这样做并不好。跨度>

标签: cassandra cql


【解决方案1】:

你不能执行

select * from table where a = ? and c = ?;

因为这意味着 Cassandra 必须扫描整个分区 'a' 才能找到 c = 'your defined value' 的所有值。这是因为 Cassandra 没有关于 b 值的任何信息,也无法直接定位到该行。

此页面上对大多数查询模式都有很好的解释。 https://www.datastax.com/blog/deep-look-cql-where-clause

【讨论】:

  • 允许该查询,因为 c 上有二级索引。这就是现在在生产中执行的查询并且工作正常。
猜你喜欢
  • 2014-12-13
  • 1970-01-01
  • 2022-08-11
  • 1970-01-01
  • 2021-11-21
  • 2016-06-13
  • 2017-11-25
  • 1970-01-01
  • 2018-11-24
相关资源
最近更新 更多