Time Window Compaction Strategy (TWCS)
|
Unified Compaction Strategy (UCS) は、Cassandra 5.0 以降のほとんどのワークロードに推奨されるコンパクション戦略です。新しいテーブルを作成する場合は、この戦略を使用してください。 |
TimeWindowCompactionStrategy (TWCS) は、タイムシリーズおよび Time-To-Live (TTL) ワークロードの期限切れに推奨されるコンパクション戦略です。ワークロードにタイムスタンプでグループ化されたデータがある場合、TWCS を使用して SSTable をタイムウィンドウでグループ化し、期限切れになったときに SSTable 全体を削除できます。したがって、STCS または LCS を使用する場合よりも、ディスクスペースをより確実に再利用できます。
TWCS は、一連のタイムウィンドウバケットを使用して SSTable をコンパクションします。アクティブなタイムウィンドウ中、TWCS はメモリからフラッシュされたすべての SSTable を STCS を使用してより大きな SSTable にコンパクションします。時間期間の終了時、これらのすべての SSTable は、SSTable の最大タイムスタンプに基づいて単一の SSTable にコンパクションされます。タイムウィンドウのメジャーコンパクションが完了すると、そのデータのコンパクションは二度と発生しません。プロセスは、次のタイムウィンドウに書き込まれた SSTable でやり直されます。各 TWCS タイムウィンドウには、さまざまな量のデータが含まれていることに注意してください。次に、次のタイムウィンドウが開始され、プロセスが繰り返されます。
TimeWindowCompactionStrategy の運用上の考慮事項
TWCS の主な動機は、ディスク上のデータをタイムスタンプで分離し、完全に期限切れになった SSTable をより効率的に削除できるようにすることです。この最適な動作を妨げる可能性のある 1 つの方法は、データが順不同で SSTable に書き込まれ、同じ SSTable に新しいデータと古いデータが混在している場合です。
順不同のデータは 2 つの方法で発生する可能性があります。
-
ユーザーが従来の書き込みパスで古いデータと新しいデータを混合すると、データは memtable 内で混ざり合い、同じ SSTable にフラッシュされ、そこで混ざり合ったままになります。
-
ユーザーの古いデータの読み取り要求によって、古いデータが現在の memtable にプルされる読み取り修復が発生した場合、そのデータは混ざり合い、同じ SSTable にフラッシュされます。
TWCS は混ざり合ったデータの影響を最小限に抑えようとしますが、ユーザーはこの動作を避けるようにしてください。特に、ユーザーは CQL USING TIMESTAMP を介してタイムスタンプを明示的に設定するクエリを避ける必要があります。さらに、ユーザーは頻繁な修復を実行する必要があります (混ざり合わないようにデータをストリーミングします)。
|
|
TWCS オプション
| サブプロパティ | 説明 |
|---|---|
enabled |
バックグラウンドコンパクションを有効にします。デフォルト値: true |
tombstone_compaction_interval |
SSTable が作成されてから、Cassandra が 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 ページを参照してください。デフォルト: days |
compaction_window_size |
バケットあたりの単位。デフォルト値: 1 |
timestamp_resolution |
データの挿入時に使用されるタイムスタンプ分解能。MILLISECONDS、MICROSECONDS などを使用できます (Java TimeUnit で理解できる必要があります)。 |
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 に設定します。
TimeWindowCompactionStrategy オプションの変更
既存のデータで TWCS を有効にしたいオペレーターは、最初にメジャーコンパクションを実行して、既存のすべてのデータを単一の (古い) ウィンドウに配置することを検討する必要があります。後続の新しい書き込みは、予想どおりに通常の SSTable を作成します。
compaction_window_unit または compaction_window_size を変更したいオペレーターは、変更できますが、隣接するウィンドウが結合されると追加のコンパクションがトリガーされる可能性があります。ウィンドウサイズが小さくなった場合 (たとえば、24 時間から 12 時間に変更した場合)、既存の SSTable は変更されません。TWCS は、既存の SSTable を複数のウィンドウに分割できません。
