我正在研究 Cassandra，我知道它是一个没有主从的对等数据库。
每个读/写都由一个协调节点来促进，然后协调节点通过复制策略和 Snitch 将读/写请求转发到特定节点。
我的问题是关于这种方法的性能问题。
【问题讨论】：
标签： database cassandra cassandra-2.0 datastax
1) 偶尔会有额外的跃点，但您的驱动程序很可能有一个用于选择协调器的 TokenAware 策略，它将选择协调器作为给定分区的副本。
2) 写入被缓冲，根据您的一致性级别，在多个节点上接受写入之前，您不会收到写入确认。例如，对于一致性级别一，您将在写入被单个节点接受后立即收到 ACK。其他节点将排队并交付写入，但您不会收到有关它们的任何信息。在其中一个写入失败/无法交付的情况下，将在协调器上存储一个提示，以便在副本恢复在线时交付。显然，可以保存的提示数量是有限的，因此在长时间停机后，您应该运行修复。
对于更高的一致性级别，客户端在 CL 中的节点数接受写入之前不会收到确认。
3) 性能应该随着写入总数而扩展。如果一个集群可以维持每秒净 10k 写入但 RF = 2。您很可能每秒只能执行 5k 写入，因为每次写入实际上是 2。无论您的一致性级别如何，都会发生这种情况，因为即使您发送了这些写入不等待他们的承认。
4) 真的没有办法绕过协调。令牌感知策略将选择一个好的协调员，这基本上是你能做的最好的。如果您手动尝试写入每个副本，您的写入仍将由接收请求的每个节点复制，因此您将获得 N 而不是一个协调事件。这也很可能是一个坏主意，因为我假设您有一个更好的C* 节点之间的网络，而不是从客户端到 c* 节点的网络。
【讨论】：
我没有答案 2 和 3，但对于 1 和 4。
1) 是的，这可以导致额外的跳跃
4) 是的，很好。 Datastax 驱动程序以及 Netflix Astynax 驱动程序可以设置为Token Aware，这意味着它将侦听环的八卦以了解哪些节点具有哪些令牌范围，并将插入发送到将存储的节点上的协调器在。消除额外的网络跃点。
【讨论】：
为了增加 Andrew 的响应，不要假设协调器跃点会导致显着延迟。做你的查询和测量。考虑一致性级别而不是额外的跳跃。调整一致性以获得更高的读取或写入速度，或两者的平衡。然后测量。如果您发现延迟无法接受，则可能需要调整一致性级别和/或更改数据模型。
【讨论】：