database - 协调器节点及其对性能的影响

Question

我正在研究 Cassandra，我知道它是一个没有主从的对等数据库。

每个读/写都由一个协调器节点促进，然后协调器节点使用复制策略和 Snitch 将读/写请求转发到特定节点。

我的问题是关于此方法的性能问题。

1. 没有额外的跃点吗？
2. 写入是否经过缓冲然后转发到正确的副本？
3. 性能如何随不同的复制而变化策略？
4. 我可以通过绕过协调器节点来提高性能吗？自己写入副本节点？

Answer 1

1) 偶尔会有一个额外的跃点，但您的驱动程序很可能有一个 TokenAware 策略来选择协调器，该策略将选择协调器作为给定分区的副本。

2) 写入被缓冲，并且根据您的一致性级别，您将不会收到写入的确认，直到它被多个节点接受。例如，对于一致性级别 1，您将在单个节点接受写入后立即收到 ACK。其他节点将有写入排队并交付，但您不会收到有关它们的任何信息。如果其中一个写入失败/无法交付，将在协调器上存储一个提示，以便在副本重新联机时交付。显然，可以保存的提示数量是有限制的，因此在长时间停机后您应该运行修复。

在一致性级别较高的情况下，在 CL 中的节点数量已接受写入之前，客户端不会收到确认。

3) 性能应与写入总数成比例。如果集群可以维持每秒 10k 的净写入但 RF = 2。您很可能每秒只能进行 5k 写入，因为每次写入实际上是 2。无论您的一致性级别如何，这都会发生，因为即使您发送了这些写入不等待他们的确认。

4) 真的没有办法绕过协调。 token 感知策略将选择一个好的协调器，这基本上是你能做的最好的。如果您手动尝试写入每个副本，您的写入仍会被接收请求的每个节点复制，因此您将得到 N 个协调事件而不是一个协调事件。这也很可能是一个坏主意，因为我假设您有更好的C* 节点之间的网络比从客户端到 c* 节点的网络。