所以我在这里看到 Cassandra 没有自动负载平衡，这在使用有序分区器时会出现（一组行的某个常见值范围将存储在相对较少的机器上，然后这些机器将服务于大多数查询）。
What's The Best Practice In Designing A Cassandra Data Model?
我对 Cassandra 以及它的工作原理还是很陌生。如何避免这个问题，以便范围查询仍然是可能的？关于将哈希附加到键，我并没有真正得到上述答案（链接的 url）的想法。
【问题讨论】：
标签： cassandra
我认为这个问题最好在 cassandra-user 邮件列表中处理；那是人们所在的地方。
Cassandra 还没有自动负载平衡，但它可能会在不久的将来这样做。 0.5 分支现在可能可以做到这一点。
本质上，当您在已经运行的系统上引导节点时，它应该在环中找到一个能够实现最佳负载平衡的位置并将自己放置在那里。如果您一次添加一个节点（即在添加另一个节点之前等待一个节点完成引导），只要您的密钥分配不会随着时间的推移发生太大变化，这应该会很好地工作。
但是，您的密钥可能会随着时间而改变（特别是如果它们是基于时间的），因此您可能需要一种解决方法。
这取决于您要进行范围扫描的内容。如果您只需要对键的PART 进行范围扫描，则可以散列您不想进行范围扫描的位，并将其用作键的第一部分。
我将在这里使用术语“分区”来指代您不想进行范围扫描的键部分
function makeWholeKey(partition, key) {
return concat(make_hash(partition), partition, key);
}
现在，如果您想对给定分区内的键进行范围扫描，您可以在 makeWholeKey(p,start) 和 makeWholeKey(p,end) 之间进行范围扫描
但是如果你想扫描分区，那你就不走运了。
但是您可以使您的节点具有在 make_hash() 输出范围内均匀分布的令牌，并且您将获得均匀分布的数据（假设您有足够的分区，它不会全部聚集在一两个哈希值）
【讨论】：
正如在另一篇文章中提到的，Cassandra 0.5 支持半自动负载平衡，您所要做的就是告诉一个节点进行负载平衡，它会自动移动到令牌环上更繁忙的地方。
【讨论】：
跨集群的数据分区由cassandra.yaml中的partitioner参数控制：
partitioner: org.apache.cassandra.dht.Murmur3Partitioner
使用Murmur3Partitioner会为Row Key生成随机哈希码并进行负载均衡。
使用 Cassandra 2.0，您可以在单个服务器中存储多个令牌 (256)，这也有助于负载平衡。使用OrderPreservingPartitioner 不是一个好习惯，已被弃用。
【讨论】：