GCP印度区域Cassandra读查询延迟高于美国区域的原因及优化咨询

根因分析 #

从提供的查询追踪日志、nodetool info输出可以定位到以下核心原因：

• 行缓存命中率极低：当前行缓存命中率仅为0.144，查询日志中存在大量Row cache miss记录，绝大多数读请求无法命中缓存，必须穿透到磁盘层读取SSTable数据，产生大量随机IO开销。
• 单查询扫描SSTable数量过多：日志显示单次查询需要遍历13个非切片相交的SSTable，最终需要合并内存表和5个SSTable的数据才能返回结果，多次磁盘查找与数据合并操作直接拉长了查询耗时。该问题通常是集群刚完成数据迁移，还未完成全量SSTable合并导致。
• 键缓存命中率不足：键缓存当前命中率仅为0.286，远低于生产环境0.9以上的合理水位，定位SSTable分区位置时需要额外的磁盘查找开销，进一步放大了延迟。
• 可选排查项：可确认印度区域集群的磁盘规格、IOPS配置是否与美国区域对齐，GCP不同区域的同规格存储性能可能存在差异，低规格磁盘也会导致IO耗时升高。

优化方案 #

可按优先级执行以下操作降低读延迟：

• 缓存策略优化
  • 针对glusr_usr这类高频访问的表单独配置行缓存策略，调整行缓存的保存周期（当前配置为0，节点重启后缓存全部失效），逐步将行缓存命中率提升到0.8以上。
  • 键缓存当前仅使用了5.21MiB/500MiB的容量，无需扩容，可调整键缓存预热逻辑，重启后自动加载历史缓存，将键缓存命中率提升到0.9以上。
• SSTable合并优化
  • 对业务核心表对应的Keyspace手动执行nodetool compact触发全量合并，将零散的小SSTable合并为少量大SSTable，将单查询扫描的SSTable数量降到2个以内，大幅降低IO开销。
  • 若业务读多写少，可将表的Compaction策略从默认的SizeTieredCompactionStrategy调整为LeveledCompactionStrategy，该策略专为读场景优化，可稳定控制单查询扫描的SSTable数量。
• 读写策略调整
  • 若业务允许最终一致性，可将读一致性级别从LOCAL_QUORUM调整为LOCAL_ONE，无需等待多个副本的digest校验，直接返回单副本数据，可降低50%左右的查询延迟。
• 基础设施对齐
  • 确认印度集群的虚拟机规格、磁盘类型（优先使用本地SSD）、IOPS配置与美国区域完全一致，避免基础设施规格差异导致的性能落差。

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