Cassandra修復-在啟用Leveled Compaction的情況下進行增量修復的情況下進行大量流式處理

Question

我使用Cassandra收集時間序列測量值。 為了實現良好的分區，在device-id旁邊添加了day-from-UTC-beginning和基於書面度量創建的存儲區 。 時間被添加為聚類鍵。 最終密鑰可以寫為

（（設備ID，從UTC開始的天，存儲桶），測量uuid）

使用IN的水桶根據該模式在大多數情況下，查詢需要用給定的設備ID和全行天從-UTC-開始 。 由於此查詢模式， Leveled Compaction看起來很完美，因為它極有可能確保一個SSTable保留一行。 禁用追加到表時，運行增量修復是可以的。 一次，修復工作在寫入壓力下進行，涉及大量流式傳輸。 看起來流傳輸的數據比上次修復后附加的數據多。

我嘗試使用多個表，每天使用一個。 當一天結束並且不再對給定的表進行寫操作時，修復運行順利。 我知道成千上萬個表的開銷，盡管看起來這只是一個可行的解決方案。

在重寫入情況下將“分層壓縮”與增量修復相結合的正確方法是什么？

Answer 1

當您有大量寫工作量時，“分層壓縮”不是一個好主意。 當讀取延遲很重要時，對於讀/寫混合工作負載來說更好。 另外，如果您的群集已被迫進行I / O操作，則切換到分層壓縮幾乎肯定只會使問題惡化。 因此，請確保您有SSD。 此時，對於寫入繁重的工作負載，分層大小是更好的選擇。 盡管在2.1中有一些改進。