集群环境中Cassandra ByteOrderedPartitioner中的问题

Question

我在4个节点和2个副本的集群环境中使用带有ByteOrderedPartitioner的cassandra 1.2.15。我想知道在集群环境中使用上面的分区器有什么缺点？经过长时间的搜索，我发现了一个缺点。我需要知道这种缺点的后果是什么？

1) Data will not distribute evenly. 
   What type of problem will occur if data are not distributed evenly?

如果集群环境中的上述分区程序有任何其他缺点，那么这些缺点会带来什么后果？请清楚解释一下。

还有一个问题是，假设如果我使用Murmur3Partitioner，数据将均匀分布。但是顺序不会被保留，但是这个缺点可以通过集群排序（主键中的第二个键）来克服。我的理解是否正确？

Answer 1

当您使用Cassandra 1.2.15时，我找到了一个与Cassandra 1.2相关的文档，其中说明了为什么使用ByteOrderedPartitioner（BOP）是一个坏主意：

http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePartitionerBOP_c.html

  

  

• 负载均衡困难负载均衡群集需要更多管理开销。一个有序的分区器   要求管理员手动计算分区范围   （以前的令牌范围）基于他们对行键的估计   分配。实际上，这需要主动移动节点   周围的标记，以容纳一次实际的数据分布   它已加载。

  

• 顺序写入会导致出现热点如果您的应用程序倾向于一次写入或更新连续的行块，那么   写入不是在集群中分布的;他们都去了   一个节点。这通常是应用程序处理的问题   带有时间戳的数据。

  

• 多个表的负载均衡不均匀如果您的应用程序有多个表，那么这些表可能具有不同的行键和不同的数据分布。订购的   为一个表平衡的分区程序可能会导致同一群集中另一个表的热点和分布不均。

  

由于这些原因，BOP已被确定为Cassandra anti-pattern。 Matt Dennis有一个slideshare presentation on Cassandra Anti-Patterns，他关于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）版本。