如何让节点同时执行读操作？

我正在一个6节点集群上试验Cassandra 3.0.2,发现"不直观"的读取 - 缩放/工作模式.

查询:

select count(*) from dvds

其中DVD有280k的记录.

使用默认的vnode设置(num_tokens:256),我发现将节点数从1增加到2会使读取性能提高约35%,但超过2个节点的每个额外节点会使性能降低约30%.

禁用vnode-s(手动设置num_tokens:1和initial_token-s)后,6节点集群的执行速度比使用num_tokens:256更好35%,但可以清楚地看到以下模式:协调器节点的CPU消耗约为50 %(CPU核心的总容量)或大约110-120%,而其他节点消耗单个核心的大约0%或60-70%的容量.不直观的部分是:当一个节点忙时,其他节点空闲.(当协调器CPU消耗为110-120%时,所有其他节点都非常空闲.当协调器的CPU为50%时,其中一个节点正忙.)

我能提出的最强有力的假设是群集无法处理网络流量,但协调员的网络流量(我认为,网络可扩展性问题最严重的地方)似乎没有超过1Mb/s时间点.(网络接口在节点上的吞吐量是10/100 Mbps.)此外,由于网络可扩展性问题,我希望"num_tokens:1"设置在所有节点上显示最初的高CPU负载(协调器除外) ) - 或至少一些均匀分布的同时负载.

拜托,有人可以对此有所了解吗？

1> Chris Lohfin..：

---

count(*)有它的位置,但非常昂贵.协调器基本上必须从所有节点中拉下所有节点,合并并计算它们.它提供的"读取所有内容"并在本地计算它们的唯一方法是减少协调器和应用程序之间的一些网络负载.

如果您需要定期使用此度量标准,我建议使用计数器或lwt将计数保持为单个读取操作(围绕查询创建数据模型而不是数据的抽象).如果需要它一次,或偶尔,hadoop/spark是一个很好的选择.您也可以从EstimatedPartitionSize指标(每个节点)获得一个合适的估计值,具体取决于您的数据模型.

---

因此,解释您在增加节点时所看到的行为.如果协调器拥有所有数据及其CL.ONE查询,它会跳过通常必须执行的大量工作,并且集合中减少的网络跃点也可以提高性能.小群集的性能略有提升,但这种跳跃应该被忽略,因为它有点人为.对于测试,您应该从5节点集群开始,并从那里增加以获得更好的感觉.

---

请记住,在CPU监视中,count(*)上的协调器必须执行大量通常不需要的工作,并且必须将大量内容加载到内存中,即使立即丢弃也会导致很多堆压力.高CPU(可能)归因于额外的垃圾收集.Spark应该更好地分配负载,而不是将其全部放在一个协调器上.