我正在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 /在任何时间点。 （网络接口在节点上的吞吐量是10/100 Mbps。）此外，由于网络可扩展性问题，我希望“num_tokens：1”设置在所有节点上显示最初的高CPU负载（协调器除外） ） - 或至少一些均匀分布的同时负载。
拜托，有人可以对此有所了解吗？
答案 0 :(得分：5)
count（*）有它的位置，但非常昂贵。协调器基本上必须从所有节点中拉下所有节点，合并并计算它们。它提供的唯一内容是＆＃34;阅读所有内容＆＃34;并在本地计算它们可以减少协调器和应用程序之间的一些网络负载。
如果您需要定期使用此指标，我建议您使用计数器或lwt来保持计数单次读取操作（围绕查询创建数据模型而不是数据的抽象）。如果需要它一次，或偶尔，hadoop / spark是一个很好的选择。您也可以从EstimatedPartitionSize指标（每个节点）获得一个不错的估计，具体取决于您的数据模型。