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

Question

我正在研究Cassandra，我知道它是一个没有主人或奴隶的同行数据库。

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

我的问题是围绕此方法的性能问题。

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

Answer 1

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

2）写入被缓冲，并且根据您的一致性级别，在多个节点上接受写入之前，您将不会收到写入确认。例如，对于一致性级别1，只要写入被单个节点接受，您就会收到ACK。其他节点将排队并传递写入但您不会收到有关它们的任何信息。在其中一个写入失败/无法传递的情况下，当副本重新联机时，将在协调器上存储提示以进行传递。显然，可以保存的提示数量有限制，所以在长时间停机后你应该进行修复。

具有更高的一致性级别，在CL中的节点数已接受写入之前，客户端将不会收到确认。

3）性能应随着写入总数而变化。如果一个集群可以维持每秒10k的净写入但是RF = 2.由于每次写入实际为2，你很可能每秒只能进行5k次写入。这将发生在你的一致性级别，因为即使你发送了这些写入他们没有等待他们的承认。

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

Answer 2

我没有2和3的答案，但是1和4的答案。

1）是的，这个可以引起额外的跳

4）是的，很好。 Datastax驱动程序以及Netflix Astynax驱动程序可以设置为Token Aware，这意味着它将监听环的八卦，以了解哪些节点具有哪个令牌范围，并将插入发送到节点上的协调器。存储在。消除额外的网络跃点。

Answer 3

要添加到Andrew的响应，请不要假设协调器跃点​​会导致显着的延迟。做你的疑问和衡量。考虑一致性级别而不是额外的跳跃。调整一致性以获得更高的读取速度或更高的写入速度，或两者之间的平衡。然后测量。如果发现延迟是不可接受的，那么您可能需要调整一致性级别和/或更改数据模型。