時間視窗壓縮策略 (TWCS)
|
統一壓縮策略 (UCS) 是從 Cassandra 5.0 開始針對大多數工作負載建議的壓縮策略。如果您正在建立新表格，請使用此策略。 |
TimeWindowCompactionStrategy (TWCS) 是針對時間序列和到期生存時間 (TTL) 工作負載建議的壓縮策略。如果工作負載的資料依時間戳分組，TWCS 可用於依時間視窗分組 SSTable，然後在到期時刪除整個 SSTable。因此，與使用 STCS 或 LCS 相比，可以更可靠地回收磁碟空間。
TWCS 使用一系列時間視窗區段來壓縮 SSTable。在活動時間視窗期間，TWCS 會使用 STCS 將所有從記憶體中清除的 SSTable 壓縮成較大的 SSTable。在時間週期結束時，所有這些 SSTable 會根據 SSTable 最大時間戳壓縮成單一 SSTable。完成時間視窗的主要壓縮後，將不再進一步壓縮資料。此程序會從下一個時間視窗中寫入的 SSTable 重新開始。請注意，每個 TWCS 時間視窗都包含不同數量的資料。然後，下一個時間視窗開始，此程序會重複。
TimeWindowCompactionStrategy 操作問題
TWCS 的主要動機是按時間戳記在磁碟上分隔資料，並允許完全過期的 SSTable 更有效率地刪除。一種潛在的方式是，如果資料以無序的方式寫入 SSTable，則新的資料和舊的資料會在同一個 SSTable 中，這會破壞最佳行為。
無序資料可能以兩種方式出現
-
如果使用者在傳統寫入路徑中混合舊資料和新資料，資料將會在記憶表中混合，並刷新到同一個 SSTable 中，然後會繼續混合。
-
如果使用者的舊資料讀取要求導致讀取修復，將舊資料拉入目前的記憶表，該資料將會混合並刷新到同一個 SSTable 中。
雖然 TWCS 嘗試將混合資料的影響降到最低，但使用者應嘗試避免這種行為。具體來說，使用者應避免透過 CQL USING TIMESTAMP 明確設定時間戳記的查詢。此外，使用者應執行頻繁的修復（以不會混合資料的方式串流資料）。
|
|
TWCS 選項
| 子屬性 | 說明 |
|---|---|
enabled |
啟用背景壓縮。預設值：true |
tombstone_compaction_interval |
Cassandra 考慮 SSTable 進行墓碑壓縮之前，建立 SSTable 後的最小秒數。如果表格超過 |
tombstone_threshold |
可垃圾回收墓碑與所有包含欄位的比率。如果比率超過此限制，Cassandra 會開始單獨對該表格進行壓縮，以清除墓碑。預設值：0.2 |
unchecked_tombstone_compaction |
如果設定為 |
log_all |
啟用整個叢集的高階記錄。預設值：false |
compaction_window_unit |
用於定義儲存區大小的時間單位。此值基於 Java TimeUnit。有關有效值的清單，請參閱位於 docs.oracle.com/javase/8/docs/api/java/util/concurrent/TimeUnit.html 的 Java API TimeUnit 頁面。預設值：天數 |
compaction_window_size |
每個儲存區的單位。預設值：1 |
timestamp_resolution |
插入資料時使用的時間戳記解析度，可以是毫秒、微秒等（Java TimeUnit 應可理解）。除非您使用 TIMESTAMP 執行突變（或直接在客戶端中使用等效值），否則請勿變更此值。預設值：微秒 |
expired_sstable_check_frequency_seconds |
決定多久檢查一次過期的 SSTable。預設值：10 分鐘 |
unsafe_aggressive_sstable_expiration |
過期的 SSTable 將會被捨棄，而不會檢查其資料是否遮蔽其他 SSTable。這是一個潛在有風險的選項，可能會導致資料遺失或已刪除的資料重新出現，超出 |
綜合來說，操作員可以指定幾乎任何大小的視窗，而 TWCS 將會建立一個單一的 SSTable 來寫入該視窗中的資料。為了在寫入期間提高效率，最新的視窗將使用 STCS 進行壓縮。
理想情況下，操作員應選擇一個會產生大約 20-30 個視窗的 compaction_window_unit 和 compaction_window_size 配對。例如，如果寫入具有 90 天 TTL，那麼 3 天視窗將會是一個合理的選擇，將選項設定為 'compaction_window_unit':'DAYS' 和 'compaction_window_size':3。
