Cassandra：CL！= ALL写入时会使集群过载

我正在运行一系列与Cassandra的基准测试。其中，我尝试了以下配置：1个客户端节点，3个服务器节点（相同的环）。Cassandra：CL！= ALL写入时会使集群过载

然后我从客户端节点（3副本，一致性任何/所有）运行cassandra-stress：

[stop/clean/start servers] 
./tools/bin/cassandra-stress -o INSERT -d server1,server2,server3 -l 3 -e ANY 
[224 seconds] 
[stop/clean/start servers] 
./tools/bin/cassandra-stress -o INSERT -d server1,server2,server3 -l 3 -e ALL 
[368 seconds]

人们可能会推断降低所有实验都清理服务器后运行一致性级别会提高性能但是，没有理由为什么会发生这种情况。瓶颈是服务器上的CPU和他们都必须最终做本地写。事实上，仔细阅读服务器日志，发现已经发生了暗示的切换。重复实验，我有时会在客户端上获取UnavailableException，并在服务器上收到“MUTATION messages dropped”消息。

此问题是否记录在案？如果CL！= ALL在写入时被认为是有害的？

来源

2013-03-04 user1202136

我不太清楚你的观点是什么。事情似乎按照设计工作。

是的，如果你在写CL.ONE将完成写入速度更快，在CL.ALL - 因为它只有从一个节点获得一个ACK - 不是所有的人。

但是，你没有测量将要采取修复数据的时间。您将花费时间排队并处理提示的切换 - 但是，节点只能维持一小时。

最终，你必须运行nodetool repair改正的一致性，并删除了墓碑。

来源

2013-03-04 22:59:23 Sarge

我的观点是（我认为你的回答证实了这一点），你实际上并没有使用CL.ONE代替CL.ALL提高性能。您的客户可以更快地畅通无阻，但您的服务器可能必须执行额外的处理，如提示或修理。在这种情况下，我想知道为什么有人会使用CL.ONE？ – user1202136 2013-03-05 08:01:06

你的观点是正确的 - 至于为什么要使用CL.ONE？这取决于您是否希望Cass更快地响应您的在线查询。通常，Cass服务器的负载并不是很重，以至于修复的处理时间是一个重要问题（尽管在某些情况下，修复时间可能会很长）。 – Sarge 2013-03-05 17:04:28

Cassandra：CL！= ALL写入时会使集群过载

回答

相关问题