如何讓節點同時執行讀取操作？

我正在6節點集羣上試驗Cassandra 3.0.2，發現「不直觀的」讀取/縮放/工作模式。如何讓節點同時執行讀取操作？

查詢：

select count(*) from dvds

其中DVD具有280K記錄。

使用默認vnode設置（num_tokens：256），我發現節點數從1增加到2會將讀取性能提高約35％，但超過2個節點的每個額外節點會使性能下降約30％。

在禁用vnode-s（手動設置num_tokens：1和initial_token-s）的情況下，6節點羣集的性能比使用num_tokens：256的性能要好35％左右，但以下模式清晰可見：協調節點的CPU消耗要麼是CPU核心總容量的50％，要麼是大約110-120％，而其他節點則消耗單核心的大約0％或60-70％的容量。不直觀的部分是這樣的：當一個節點忙時，其他節點空閒。（當協調器CPU消耗在110-120％時，所有其他節點都非常閒置，當協調器的CPU爲50％時，其他節點中的一個節點忙）。

我可以想出最強的假設該集羣無法處理網絡流量，但協調器的網絡流量（我假設網絡可擴展性問題將受到最大打擊的情況下）在任何時間似乎都不會超過1Mb/s。（網絡接口在節點上的吞吐量爲10/100 Mbps。）另外，由於網絡可伸縮性問題，我期望「num_tokens：1」設置能夠顯示所有節點上的初始高CPU負載（協調器） - 或者至少有一些均勻分佈的同時加載。

請問任何人都可以對此有所瞭解？

來源

2016-01-03 The night manager

count（*）有它的位置，但是非常昂貴。協調員基本上必須從所有節點拉下所有東西，合併並計數它們。它提供的「讀取所有內容」並在本地統計它們的唯一方法是減少協調器和應用程序之間的網絡負載。

如果您需要定期使用此指標，我會建議使用計數器或lwt來保持計數爲單個讀取操作（創建數據模型而不是抽象數據）。如果需要它，或者很少，hadoop/spark是一個很好的選擇。您也可以根據您的數據模型從EstimatedPartitionSize度量標準（每個節點）獲得相當好的估計值。

來源

2016-01-03 15:52:59

非常感謝，克里斯！其實，我打算使用卡桑德拉表作爲Spark的「後備存儲」。我正在通過這個簡單的練習來理解「孤立地」（在向Spark中添加Spark之前）使用sc.cassandraTable（）創建RDD的性能影響。到目前爲止，count（*）似乎**最能夠模擬Cassandra **期望的工作負載**（任何與此相反的指針都是值得歡迎的）。看起來 - 用我當前的Cassandra-config - RDD分區將以串行方式（不是並行）加載，我猜想這是一種可以/應該改進的行爲。 –

因此，解釋你看到的增加節點的行爲。如果協調員擁有所有數據及其CL.ONE查詢，它將跳過通常需要做的大量工作，並且收集中減少的網絡跳數也可以提高性能。小團隊的表現略有提高，但這種跳躍應該被忽略，因爲它有點人爲。爲了進行測試，您應該從5節點集羣開始，並從那裏增加以獲得更好的感覺。 –

vnodes對性能的影響通常是負面的。查詢/修理必須走每個範圍;一般會按順序進行，這將會比較慢，特別是在存在很多空白區域的情況下，那麼浪費時間。也就是說，我仍然/強烈/建議使用vnodes以簡化操作，手動令牌管理是一種痛苦。 –

如何讓節點同時執行讀取操作？

回答

相關問題