羣集環境中Cassandra ByteOrderedPartitioner中的問題

Question

我在具有2個副本的4個節點的羣集環境中使用cassandra 1.2.15和ByteOrderedPartitioner。我想知道在集羣環境中使用上述分區器有什麼缺點？經過漫長的搜索，我發現一個缺點。我需要知道這種缺點的後果是什麼？

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，我已經找到了屬於卡桑德拉1.2 DOC這說明了爲什麼使用ByteOrderedPartitioner（BOP）後面的點是一個壞主意：

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

• 困難的負載均衡負載均衡集羣需要更多的管理開銷。有序分區程序 要求管理員根據分區對行鍵 分佈的估計值手動計算分區範圍 （以前稱爲令牌範圍）。實際上，這需要主動移動節點 ，以適應數據的實際分佈，一旦 被加載。

• 順序寫入會導致熱點如果應用趨向於寫或一次更新的行的連續塊，則 寫入不跨集羣分佈;他們都去 一個節點。對於使用時間戳數據處理 的應用程序來說，這通常是一個問題。

• 多個表格的不均衡負載均衡如果您的應用程序有多個表格，那麼這些表格可能有不同的行鍵和不同的數據分佈。對一個表進行平衡的分區器可能會導致同一集羣中另一個表的熱點和不均勻分佈。

由於這些原因，國際收支已被確定爲Cassandra anti-pattern。馬特·丹尼斯有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中訂購結果，但您只能在特定分區鍵的上下文中執行此操作。

另外，Cassandra自1.2.15以來已經有很多改進。你絕對應該考慮使用更新的（2.x）版本。