一致性ONE/LOCAL_QUORUM级别Cassandra读查询并行执行超时咨询

问题原因 #

• 多SASI索引联合查询的并发性能瓶颈：当前查询未指定主键中的分区键col5，完全依赖多个StorageAttachedIndex（SASI）做联合条件过滤，属于Cassandra的反查询模式。SASI索引本身扫描开销远高于原生主键查询，高并发下会大量占用节点CPU、内存和磁盘IO资源，多个并行查询同时触发索引扫描时，节点资源被占满，无法及时响应请求。
• 分页参数设置不合理：Fetch_Size配置为10000，单次分页需要拉取1万行数据，瞬时会给协调节点和数据节点带来极高的内存和网络压力，并行场景下会导致请求堆积，超过默认的读请求超时阈值。
• 全集群扫描开销过大：查询带PER PARTITION LIMIT 1配置，需要遍历集群中所有符合过滤条件的分区，本身单次查询耗时就超过1分钟，并行执行时会导致所有节点的资源持续被占用，后续请求无法得到及时处理。

解决方案 #

• 优先优化数据模型：针对该高频查询新建适配表，将查询条件中的col1、col2设为分区键前缀，后续查询直接走原生主键检索，性能可以提升10~100倍，从根源上避免索引查询的开销。
• 替换索引方案：如果无法修改数据模型，建议将多SASI索引替换为DSE Search索引（当前使用的DSE 6.8原生支持该功能），DSE Search对多条件组合过滤的并发支持远优于SASI索引。
• 调整请求配置：将Fetch_Size下调到1000~2000区间，降低单次分页的资源开销；同时适当调大驱动端的请求超时时间和服务端的read_request_timeout_in_ms参数，避免正常慢查询被误杀。
• 控制并发流量：同类型重查询的并行度控制在1~2以内，新增请求排队和退避重试逻辑，避免同时向集群发送大量重查询请求导致资源耗尽。
• 扩容集群资源：排查节点监控，如果CPU、内存或磁盘IO使用率长期超过70%，通过扩容节点提升集群的整体处理能力。

内容的提问来源于stack exchange，提问作者Jayavinoth