我从Cassandra 2.x群集中看到了非常奇怪的行为。
如果我执行以下查询（使用CL ONE或LOCAL_ONE）
select count(*) from api_cache;
查询可以在同一节点上随机占用20ms或800ms（该表有大约600行）
在第一种情况下，执行大约100次连续扫描，在第二种情况下执行大约2000次。我不知道为什么系统应该表现出这种非确定性的行为。
此问题仅发生在DC2（RF = 5的5个节点）中，而在DC1（3个节点RF = 3）中，相同的查询始终在大约15ms内返回。值得一提的其他要点是DC2是从DC1流式传输创建的，键空间使用sizeTiered压缩。所有节点都有16GB的RAM，用于/ var / lib / cassandra的专用SSD，并且负载非常轻。
我尝试过压实，修理，擦洗等 - 一切都没有效果。
任何帮助都会受到大力赞赏，
感谢。
以下是两种情况下的CQL tracings（编辑：每个来自DC1）
更新：
这很好。如果我使用CL = ALL从DC1运行查询，则每次返回大约30ms。换句话说，从DC1查询DC2比从DC2查询DC2快一个数量级！
请记住DC相距100英里，至少我们可以在任何节点上对网络和磁盘问题进行折扣....
关键区别在于DC1仅扫描一个范围，例如[min(-9223372036854775808), min(-9223372036854775808)]，而DC2扫描多个范围，例如(max(4772134901608081021), max(4787315709362044510)]。
还有一个事实是一个使用min而另一个使用多个最大值...
这显然是问题的核心 - 但我不知道如何解决它！
答案 0 :(得分：1)
count（*）表现取决于你有多少sstables。我查看了你的跟踪输出，很明显DC1有很少的sstables而DC2有很多。必须检查每一行以获得总数。启用vnode会通过在更多分区之间拆分数据来放大问题。
保持准确计数需要对每个突变进行读 - 修改 - 写和额外锁定，因此Cassandra不会这样做。 Count（*）实际上是基于每个sstable / memtable的行数的估计，这也是一个估计值。
有关详细信息，请阅读以下内容： http://www.wentnet.com/blog/?p=24
答案 1 :(得分：1)
这是在2.0.4和2.0.9之间引入的回归。
查询规划器不再能够计算给定节点的连续范围，因此不是为每个连续范围发出一次扫描，而是经常单独扫描每个范围。
有关详细信息，请参阅CASSANDRA-7535。