ALLOW FILTERING对Cassandra的影响及对其他应用的性能影响咨询

我来给你拆解一下ALLOW FILTERING在Cassandra里的坑，以及它对集群和其他应用的影响——这是很多Cassandra新手容易踩的雷。

首先得明确：Cassandra官方说它效率极低，绝对不是危言耸听。Cassandra是按分区键分片存储的，正常查询会先通过分区键定位到特定节点的特定分区，只扫描目标数据。但ALLOW FILTERING会跳过这个核心的分区过滤逻辑，强制Cassandra扫描多个甚至所有分区，然后在内存里筛选符合条件的数据——这就好比你要找一本书，不去查索引直接翻整个图书馆的书架，效率能高才怪。

接下来回答你最关心的问题：如果必须用这类查询，会对其他应用产生什么影响？

• 不止是单个线程变慢，严重时会拖垮整个集群
  执行ALLOW FILTERING的查询会疯狂消耗节点资源：

  • 磁盘IO：要读取大量SSTable文件（Cassandra的持久化存储文件），磁盘带宽被占满后，正常请求的磁盘读写会排队；
  • CPU&内存：扫描到的数据要在内存里过滤、排序，这会占用大量CPU和堆内存，导致节点的GC停顿时间变长，甚至出现OOM（内存溢出）；
  • 跨节点资源消耗：如果查询涉及多个节点（绝大多数非单分区的ALLOW FILTERING查询都会这样），每个被涉及的节点都会被消耗资源，协调器节点还要汇总所有节点的结果，压力翻倍。

• 对其他应用的连锁影响
  当节点的资源被这类查询占满时，它处理正常请求的能力会急剧下降：

  • 首先，依赖该节点的应用请求会出现延迟、超时；
  • 如果这类查询频繁执行，或者单次查询的数据量极大，整个集群的吞吐量会暴跌，所有依赖Cassandra的应用都会出现响应变慢的情况，甚至出现服务不可用。

如果必须使用ALLOW FILTERING，怎么降低影响？ #

虽然不推荐，但如果真的没办法，建议这么做：

• 加上LIMIT限制返回结果的数量，避免一次性扫描过多数据；
• 尽量附加能缩小分区范围的条件（比如指定一个分区键的时间范围），减少需要扫描的分区数量；
• 避开业务高峰时段执行这类查询；
• 长远来看，最好重新设计表结构（比如增加合适的二级索引，或者调整分区键、聚类键，让查询能天然匹配Cassandra的存储模型）。

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