不太清楚有關Cassandra的反模式

假設，存在結構如下表：不太清楚有關Cassandra的反模式

create table cities (
    root text, 
    name text, 
    primary key(root,name) 
) with clustering order by (name asc); -- for getting them sorted 

insert into cities(root,name) values('.','Moscow'); 
insert into cities(root,name) values('.','Tokio'); 
insert into cities(root,name) values('.','London'); 

select * from cities where root='.'; -- get'em sorted asc

在指定的3複製因子的密鑰空間和使用RandomPartitioner，將有3個副本每個行在3個節點上：主節點確定用於存儲該行的散列值和2個下一個散列值。爲什麼應該有一個熱點？從所有副本讀取不是負載平衡？

來源

2014-09-02 ejq11827

請勿使用RandomPartitioner。使用更新的Murmur3Partitioner。 – 2014-09-02 18:17:38

定義這樣一個表的分區鍵是root而name是一個集羣鍵。顧名思義，分區負責分區 - 分區如何工作？假設你有4個節點簇 - 我們有一個散列函數，它只生成8個鍵（A，B，C，D，E，F，G，H） - 散列在簇中的分佈方式

節點1 - （A，B）
節點2 - （C，d）
節點3 - （E，F）
節點4 - （G，H）

每個節點將作爲副本的以下2，所以節點1的副本是（2,3），節點2的副本是（3,4），節點3的副本是（4,1），並且最終節點4的副本是（1， 2）。

假設我們的函數hash(root)，當根值是.返回B屬於節點1-節點1將存儲信息和節點（2,3）將存儲副本。節點4是從不涉及到cities表中，因爲修復分區鍵，它不會包含任何有關此表的數據（對於不屬於該概念的提示情況的例外）。在這個例子中，您使用了大約75％的羣集，這看起來像是一個可接受的情況......讓我們假設您的應用程序受到影響，因爲涉及的3個節點無法處理讀/寫請求。現在，您可以根據需要添加儘可能多的節點，但使用此數據模型將無法水平縮放，因爲沒有其他節點將涉及到城市表。我看到在這種情況下解決問題的唯一方法是通過增加更多內存，更強大的CPU和I/O來增加這3個節點的功耗（垂直縮放）。創建不允許水平縮放的架構是反模式

來源

2014-09-02 07:06:01

謝謝你的完美解釋！ – ejq11827 2014-09-02 07:39:22

不太清楚有關Cassandra的反模式

回答

相關問題