Cassandra VNodes交易表現如何？

我在6節點集羣上使用DataStax Cassandra 1.2.3，每個集羣都有四核3GHz處理器和8GB RAM。最近，我開始使用VNodes功能，將num_tokens設置爲256，然後設置爲128.我觀察到我正在使用的模式的性能下降[寫請求數/秒]。我主要有一個規範化的模式，混合了寬表&計數器列家族。Cassandra VNodes交易表現如何？

有沒有人觀察到使用VNodes的性能下降？是否有任何已知的優化技術可以更好地利用VNodes？
對於給定的硬件配置/節點，可以推導出num_tokens的最佳值嗎？
此外，我看到羣集幾乎平衡，一個節點自動獲得更高的負載份額，儘管我有一個同類羣集。在使用VNodes之前，我會手動平衡Murmer3Partitioner的羣集，並且性能很好。

感謝， VS

來源

2013-06-13 vinay sudhakar

性能有什麼區別？ – Richard

對不起，性能下降是由於發電機端的問題。整體表現實際上增加了大約7％。然而，如果有人知道爲什麼256被認爲是num_tokens的最佳值，我的問題2仍然有效？對於給定的硬件配置/節點，可以推導出num_tokens的最佳值嗎？ –

（這是我的文章的修改版本：http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Why-so-many-vnodes-td7588267.html）

每個節點的令牌（姑且稱之爲T和節點個數N）的數量， 256被選擇爲大多數簇大小的隨機令牌分配提供良好的負載平衡。對於小T來說，隨機選擇初始令牌在大多數情況下會導致數據分佈不良。 T越大，分佈越接近均勻，概率越高。另外，對於小型T，當添加一個新節點時，它將不會有很多分割範圍，因此無法獲得一個平滑的數據片。

因爲這個原因，T應該很大。但是，如果它太大，有太多的切片來跟蹤，因此性能會受到影響。查找哪些鍵生活在哪裏變得更加昂貴的功能以及處理個別vnode的操作例如修復變得緩慢。（一個極端的例子是SELECT * LIMIT 1，當沒有數據時，必須依次掃描每個vnode搜索單個行，這是O（NT），即使非常小的T也需要幾秒鐘的時間才能完成。）

所以256被選擇爲一個合理的平衡。我不認爲大多數用戶會覺得它太慢;具有極大集羣的用戶可能需要增加它。

來源

2013-06-17 11:13:26 Richard

非常感謝您的回覆 –

Cassandra VNodes交易表現如何？

回答

相關問題