一致性 ONE/LOCAL_QUORUM 读取查询期间的 Cassandra 超时

Question

表结构

CREATE TABLE tablename(
col1 text,
col2 text,
col3 timestamp,
col4 timestamp,
col5 text,
col6 timestamp,
.
.
PRIMARY KEY (col5, col6))
WITH CLUSTERING ORDER BY (col6 DESC)

CREATE CUSTOM INDEX indexname on tablename (col1) USING 'StorageAttachedIndex';
CREATE CUSTOM INDEX indexname on tablename (col2) USING 'StorageAttachedIndex';
CREATE CUSTOM INDEX indexname on tablename (col3) USING 'StorageAttachedIndex';
CREATE CUSTOM INDEX indexname on tablename (col4) USING 'StorageAttachedIndex';
CREATE CUSTOM INDEX indexname on tablename (col6) USING 'StorageAttachedIndex';

阅读查询：

select col1, col2, col3, col4, col.... from tablename
where col1='text'
and col2='text'
and col3>'timestamp'
and col4>='timestamp'
and col4<='timestamp'
PER PARTITION LIMIT 1;

在 Java 中，我编写了一个代码来执行查询以使用以下配置获取 100,000 条记录：

1. 执行异步
2. Fetch_Size = 10000
3. 不使用允许过滤
4. DSE - 6.8.9
5. 重庆 - 3.4.5
6. 卡桑德拉 - 4.0.0.681
7. Java 驱动程序 - 4.6.1

当我运行代码时，它完美地工作并在大约 1 分 20 秒内响应 100,000 行。

但是当我尝试在 2 个以上的窗口中并行运行时，只有一个窗口显示结果，其他窗口抛出超时错误。

一致性 ONE 读取查询期间的 Cassandra 超时

Answer 1

当我运行代码时，它运行良好并在大约 1 分 20 秒内响应

TBH 我很惊讶这会返回一个结果集。 Cassandra 并非旨在支持 OLAP 或需要对许多不同列进行过滤的查询。

它超时的原因是基于二级索引（或多个索引，在这种情况下）的查询给一个节点带来了额外的压力。 当它们运行时，会选择一个“协调器”节点。 然后该节点负责从所有其他节点提取数据并组装结果集（在 RAM 中）。

默认超时设置的特定目的是停止这样的查询，因为它们可能（并且经常会）导致节点崩溃。 我想并行支持两个类似的查询对于集群来说太多了。

解决这个问题的方法是确保您的查询始终过滤分区键（在本例中为col5 ）。 单分区查询确保只查询一个节点。 这就是为什么 Cassandra 的想法是围绕预期查询构建表。 在这种情况下，使用col1和col2分区键构建查询表将有助于确保这一点。 添加col3和col4聚类键将有助于您的其他条件：

PRIMARY KEY ((col1, col2),col3,col4)

当然，我是在不了解col1或col2的基数的情况下构建该定义的。 由于 Cassandra 的分区限制为 2GB 和 20 亿个单元，因此将分区大小保持在远低于该值总是一个好主意。 在这种情况下，一个额外的分区键并对数据集的较小部分运行多个查询将是可行的方法。

我建议查看DataStax Academy ，特别是有关数据建模的（免费）课程 DS220。