我正在运行一个填充Scylla中一个表的Spark Job。表中的主键是长类型的，它基本上包含电话号码。如果我们谈论这个字段的潜在值，它肯定不会是统一的，因为大多数电话号码都集中在9-12位数字之间。
至于我的Scylla配置，它是一个具有3个节点的单个集群，复制因子为3。我的问题是，由于主键本身是偏斜的，所以每个节点的读/写操作是偏斜的，还是scylla在对主键进行散列后选择节点，从而使操作统一？
我已经看到，对于一个特定的节点，操作的数量有时会发生跳跃，但我想在采取任何步骤之前100%确定。
2条答案
按热度按时间1hdlvixo1#
分区的节点由主键的Murmur3散列确定。
例如，电话号码
920-458-3834被散列为3485763808729355786的令牌，并最终被写入负责包括3485763808729355786的令牌范围的节点。也许下一个电话号码与此类似，比如
920-458-3835。它被散列为-6305759902789073081，并且在大型集群中可能会被写入到不同的节点。我看到，对于特定节点，操作的数量有时会发生跳跃
不确定集群或应用程序设置，但这可能是一个协调器节点。
kknvjkwl2#
简单地说，使用电话号码作为分区键是完全可以的。它确实通过哈希函数来生成“令牌”，并且电话号码在这个令牌步骤中变得统一。
除了Aaron在适用于任何集群大小的公认答案中解释的内容（基本上是分区键被哈希），但在您的情况下，一个具有N=3个节点和RF=3的集群，情况甚至更简单：在这样的集群中，每个分区都被写入所有三个节点-它需要被写入三个节点，因为RF=3，但集群中只有三个节点。因此，无论你写什么数据，它都需要到达所有三个节点，无论你读什么数据，它都可以从三个节点中的任何一个节点读取。
如果你看到一个特定的节点比其他节点加载更多，这可能是一个暂时的随机事件，或者你的应用程序过度使用这个特定的节点作为一个协调器（发送所有的请求），因为驱动程序配置错误或其他原因（？）.