Compactionの目的
SSTable統合による読み取りオーバヘッドの削減
SSTableはmemtableの(定期的なflushによる)ダンプという形で作成されるため、経時とともに多くのファイルが作成されることになり、よって、読み取りクエリは複数のSSTableを読み取る形となり、オーバヘッドが発生する。このオーバヘッドの削減のため、SSTableファイルをソートマージする。
不要データの物理削除
Cassandraは更新処理や削除処理で元のデータの置換えを行わないことで、更新/削除処理時のI/Oオーバヘッドを軽減しているが、無駄なディスク容量が発生したままになる。このため、SSTableファイルをソートマージして、重複/期限切れデータを削除する。
※逆にいうと、物理的なレコード削除はCompactionのタイミングでしか行われない。
Compactionプロセス
発動タイミング
・発動タイミングは以下
・テーブルごとに定義したCompaction Strategyに基づく、バックグランド自動起動
・管理者によるnodetool compactコマンド実行
・SSTableの変換(nodetool upgradesstables等)、rebuild(nodetool rebuild)
・incremental repairに伴うCompaction
実行プロセス
・各SSTableのデータをマージ、tombstoneを排除して、SSTableを1つの新しいSSTableファイルに統合
・tombstoneの削除は、そのtombstoneの猶予秒( gc_grace_seconds )が終了している場合のみ実行
※猶予秒( gc_grace_seconds )のデフォルト: 864,000秒=10日間
( データのゴースト化復活回避のために、すべての廃棄( tombstone )がrepairで正常伝播される必要あり )
・古いSSTableファイルは、マージ完了後、継続中の読み取りによるファイルの使用が終了を待って削除
処理結果の確認
・system.logあるいはdebug.logに出力されるCompactionExecutorのログ出力で確認可能
・Compacting ～
Compaction処理対象のSSTableを確認可能
・Compacted ～
Compaction処理結果を確認可能
・Compacted ～ sstables to ... [SSTableをマージした数]
・～ bytes to ～ [前後のデータサイズ]
・～ total partitions merged to ～ [前後のパーティション数]
・{1:～, 2:～,} 何個のSSTableからいくつパーティションをマージしたか
例えば、「2:46」は、46パーティションを2つのSSTableからマージしたことを示す
Compactionの留意点
・Compaction処理時、新旧のSSTableが共存するため、ディスク領域の使用量が一時的に増加
・Compaction処理時、ディスクI/O、CPU使用が増加