我在 4 个节点和 2 个副本的集群环境中使用 cassandra 1.2.15 和 ByteOrderedPartitioner。我想知道在集群环境中使用上述分区器有什么缺点？经过长时间的搜索，我发现了一个缺点。我需要知道这种缺点的后果是什么？
1) Data will not distribute evenly.
What type of problem will occur if data are not distributed evenly?
上述分区器在集群环境中是否还有其他缺点，如果有，这些缺点的后果是什么？请解释清楚。
还有一个问题，假设如果我使用 Murmur3Partitioner，数据将均匀分布。但是不会保留顺序，但是可以通过集群排序（主键中的第二个键）克服这个缺点。我的理解是否正确？
【问题讨论】：
当您使用 Cassandra 1.2.15 时，我发现了一个与 Cassandra 1.2 相关的文档，该文档说明了为什么使用 ByteOrderedPartitioner (BOP) 是一个坏主意背后的要点：
负载平衡困难需要更多的管理开销来对集群进行负载平衡。有序分区器 需要管理员手动计算分区范围 （以前的令牌范围）基于他们对行键的估计 分配。在实践中，这需要主动移动节点 周围的令牌以适应数据的实际分布一次 它已加载。
顺序写入会导致热点如果您的应用程序倾向于一次写入或更新连续的行块，那么 写入不会分布在整个集群中；他们都去 一个节点。这通常是应用程序处理的问题 带有时间戳的数据。
多个表的负载平衡不均匀如果您的应用程序有多个表，则这些表可能具有不同的行键和不同的数据分布。有序
为一个表平衡的分区器可能会导致同一集群中另一个表的热点和分布不均匀。
由于这些原因，BOP 已被标识为Cassandra anti-pattern。 Matt Dennis 有一个slideshare presentation on Cassandra Anti-Patterns，他关于 BOP 的幻灯片如下所示：
说真的，不要使用 BOP。
“但是这个缺点可以通过集群排序（主键中的第二个键）来克服。我的理解是否正确？”
有点，是的。在 Cassandra 中，您可以通过使用集群键来指定行的顺序（在分区键内）。如果您想跟踪（例如）基于站点的天气数据，您的表定义可能如下所示：
CREATE TABLE stationreads (
stationid uuid,
readingdatetime timestamp,
temperature double,
windspeed double,
PRIMARY KEY ((stationid),readingdatetime));
使用此结构，您可以查询特定气象站的所有读数，并按readingdatetime 排序。但是，如果您查询所有数据（例如：SELECT * FROM stationreads;），结果可能不会以任何可识别的顺序排列。这是因为总结果集将按分区键（在本例中为 stationid）的（随机）散列值排序。因此，虽然“是”您可以在 Cassandra 中对结果进行排序，但您只能在特定分区键的上下文中这样做。
此外，自 1.2.15 以来，Cassandra 也进行了许多改进。您绝对应该考虑使用更新的 (2.x) 版本。
【讨论】：