可以選擇計數（*）影響Cassandra中的寫入

我經歷了一個場景，每分鐘在表格上選擇一個計數（*）（肯定應該避免這種情況）導致Cassandra寫入大約150K寫入每秒。可以選擇計數（*）影響Cassandra中的寫入

任何人都可以解釋這種奇怪的行爲？爲什麼Select查詢會顯着增加Cassandra中的寫入次數？

謝謝！

2016-11-10 GPSS

這有點奇怪。我沒有看到爲什麼C *應該增加其寫入次數的任何觀點。你是如何衡量的？ – xmas79

我無法想象這會發生的原因。更有可能有另一個進程正在做... – RussS

請問可以澄清術語「寫入」嗎？只是爲了區分磁盤寫入和Cassandra突變。您是否看到在nodetool tpstats中備份的寫入請求，並刪除突變？或者你在觀察磁盤隊列嗎？每秒150K突變是很多流量。 – suiterdev

如果檢查

org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackground

和

org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking

指標，您可以看到，如果它的讀修理發送突變。如果數據不一致，讀取所有數據以維護計數（*）可能會導致大量讀取修復。如果這種情況下表read_repair_chance和dclocal_read_repair_chance降低表（ALTER TABLE）可以減少負荷。

其他可能的可能性是：

2016-11-10 19:46:44

謝謝克里斯！ Cassandra在選擇查詢期間確實執行了多次讀取修復，這很可能是我遇到問題的根本原因。 – GPSS

一個可能的解釋可能在the write path of an update發現：

在寫，卡桑德拉將每一個新行到數據庫，而上是否存在重複記錄檢查。該策略可以使數據庫中可能存在同一行的許多版本。

然後

大多數卡桑德拉設施儲存在兩個或多個節點的每一行的副本。每個節點獨立執行壓縮。這意味着即使一個行的過時版本已經從一個節點中刪除，它們仍可能存在於另一個節點上。

最後：

這就是爲什麼卡桑德拉執行期間讀取過程比較的另一輪。當客戶端使用特定的主鍵請求數據時，Cassandra會從一個或多個副本中檢索該行的許多版本。

2016-11-13 15:02:52 xmas79

回答