如何确保一致的哈希工作?

时间:2015-06-03 03:51:23

标签: cassandra scalability consistent-hashing

我将在一堆节点上实现一致的散列。每个节点的容量都有限(比方说1GB)。我从一个节点开始,当它变满时我将添加另一个节点并使用一致的散列来重新分配数据并通过添加新节点继续前进。但是,仍有可能节点已满。我知道一些像cassandra这样的nosql数据库使用一致的散列来做类似于我正在做的事情。如何使用一致性散列来避免节点溢出?

2 个答案:

答案 0 :(得分:1)

Cassandra不会以您描述的方式使用一致的散列。

每个表都有一个分区键(您可以将其视为主键或RDBMS术语中的第一部分),此键使用murmur3算法进行哈希处理。整个哈希空间形成从最低可能哈希到最高哈希的连续环。之后,此环被分为块(vnode,默认为256),这些块在多个节点之间相当分布。每个节点不仅托管它自己的环的一部分,而且还根据复制因子维护其他vnode的复制副本。

这种做事方式有助于解决许多问题:

  • 平衡所有集群节点之间的数据负载,没有特定节点可以过载(数据大小,读写均匀分布,没有热点)
  • 如果您向群集添加新节点,它将处理它自己的部分响铃并从其他节点自动提取所需的vnode。无需手动重新分析。
  • 如果节点发生故障,由于复制,您不会错过任何数据,因为它已经存储在其他节点上。在这种情况下,您可以解除失败的节点,以便所有其他节点将在其中重新分配失败的环部分。无需为失败的数据库节点提供复杂的切换方案。

当然,您总是可以在应用程序层中的任何RDBMS之上实现类似的数据库行为,但它总是比使用现有的经过实战考验的解决方案更难并且不容易出错。

答案 1 :(得分:0)

我想您知道在添加或删除节点时密钥如何从一个节点移动到另一个节点。来到你的统一分配如何发生的问题?

你可以在这里拥有自己的逻辑来实现它。如果任何节点变热(处理更多密钥),则继续监视散列中的所有节点,在此节点之前插入另一个节点,以便在旧节点和新节点之间分配负载。类似地,如果任何节点未被利用,您可以删除它们,以便加载将转移到下一个节点。

希望这有帮助.. !!