コンパクションの概要

Cassandraのデータはmemtableに作成されます。 メモリしきい値に達すると、メモリを再び解放するために、データはディスク上に存在するSSTableと呼ばれる不変ファイルに書き込まれます。

SSTableは不変であるため、データが更新または削除された場合、古いデータは挿入や更新で上書きされたり、SSTableから削除されたりしません。 代わりに、新しいタイムスタンプで更新されたデータを含む新しいSSTableが作成され、古いSSTableは削除対象としてマークされます。 削除されたデータはトゥームストーンと呼ばれます。

時間の経過とともに、Cassandraは異なるSSTableに同じ行の複数のバージョンを書き込む場合があります。 各バージョンには、異なるタイムスタンプで格納された一意の列セットが含まれている場合があります。 SSTableが蓄積されると、データの分散により、完全な行を取得するために、アクセスする必要があるSSTableの数が増える可能性があります。

データベースを健全な状態に保つために、CassandraはSSTableを定期的にマージし、古いデータを破棄します。 このプロセスはコンパクションと呼ばれます。

SSTableは読み取り操作中に参照されるため、SSTableの数を少なくすることが重要です。 書き込み操作を行うとSSTableの数が増えるため、コンパクションが必要になります。 トゥームストーンの問題に加えて、データは有効期限（TTL）の満了など、他の理由でも削除されます。 データの削除、更新、または期限切れはすべて、コンパクションの有効なトリガーです。

コンパクションによって達成される2つの重要な要素は、パフォーマンスの向上とディスク容量の再利用です。 読み取る必要がある重複データがSSTableにある場合、読み取り操作は遅くなります。 トゥームストーンと重複が削除されると、読み取り操作は高速になります。 SSTableはディスク容量を使用し、コンパクションによってSSTableのサイズを削減することで、ディスク容量が解放されます。

コンパクションはSSTableのコレクションに対して機能します。 これらのSSTableから、コンパクションは各一意の行のすべてのバージョンを収集し、各行の列の最新バージョン（タイムスタンプ別）を使用して、1つの完全な行を組み立てます。 行は各SSTable内でパーティションキーでソートされ、マージプロセスはランダムI/Oを使用しないため、マージプロセスは高性能です。 各行の新しいバージョンは新しいSSTableに書き込まれます。 古いバージョンと削除準備のできた行は古いSSTableに残され、保留中の読み取りが完了するとすぐに削除されます。

コンパクションの概念は、Cassandraのさまざまな種類の操作に使用されます。これらの操作に共通しているのは、1つ以上のSSTableを取得し、マージして、新しいSSTableを出力することです。 コンパクションの種類は次のとおりです。

さまざまなワークロードを最適化するために、さまざまなコンパクション戦略が利用可能です。 ワークロードに適したコンパクション戦略を選択することで、クエリとコンパクション自体の両方で最高のパフォーマンスが確保されます。

Cassandraのデータには、Time To Liveと呼ばれる追加のプロパティを設定できます。これは、時間が経過すると期限切れのデータを自動的に削除するために使用されます。TTLが期限切れになると、データはトゥームストーンに変換され、少なくとも gc_grace_seconds の間保持されます。TTL付きのデータとTTLなしのデータ（またはTTLの長さが異なるだけ）を混在させると、パーティションが多くのSSTableにまたがり、すべてが一度にコンパクションされるわけではないため、Cassandraは作成されたトゥームストーンの削除に苦労することに注意してください。

上記と同様

増分修復では、Cassandraはどのデータが修復され、どのデータが未修復かを追跡する必要があります。アンチコンパクションにより、修復されたデータは修復済みと未修復のSSTableに分割されます。データを再び混在させないために、2つのデータセットに対して個別のコンパクション戦略インスタンスが実行され、各インスタンスは修復済みまたは未修復のSSTableのいずれかのみを認識します。これは、増分修復を1回だけ実行し、その後二度と実行しない場合、修復済みSSTableに非常に古いデータが存在し、未修復（おそらく新しい）SSTableのトゥームストーンの削除をコンパクションがブロックする可能性があることを意味します。

トゥームストーンとデータは異なるSSTableに存在する可能性があるため、SSTableを失うとデータが再びライブになる可能性があることを理解することが重要です。SSTableを失う最も一般的な方法は、ハードドライブの故障です。データをライブにしないようにするために、トゥームストーンと実際のデータは常に同じデータディレクトリにあります。こうすることで、ディスクが失われた場合、パーティションのすべてのバージョンが失われ、データが削除解除されることはありません。これを達成するために、修復済み/未修復データを含むコンパクション戦略インスタンスに加えて、データディレクトリごとにコンパクション戦略インスタンスが実行されます。これは、4つのデータディレクトリがある場合、8つのコンパクション戦略インスタンスが実行されることを意味します。これには、データの削除解除を防ぐ以上のメリットがいくつかあります。

SSTableが書き込まれると、トゥームストーンの有効期限を含むヒストグラムが作成され、これを使用してトゥームストーンが非常に多いSSTableを見つけ、そのSSTableで単一SSTableコンパクションを実行して、そのSSTableのトゥームストーンを削除できるようになります。これを開始する前に、トゥームストーンが実際に削除できる可能性、このSSTableが他のSSTableとどの程度重複しているかもチェックされます。これらのチェックのほとんどを回避するために、コンパクションオプション unchecked_tombstone_compaction を有効にすることができます。

すべてのコンパクション戦略に共通のオプションがいくつかあります。

さらに、具体的な追加オプションについては、各戦略に関するセクションを参照してください。

nodetool ユーティリティは、コンパクションに関連する多くのコマンドを提供します。

JMXを使用して単一ノードのコンパクション戦略とそのオプションを切り替えることができます。これは、クラスター全体に影響を与えることなく設定を試すのに最適な方法です。mbeanは

であり、変更する属性は、jconsoleまたはjmcを使用する場合は CompactionParameters または CompactionParametersJson です。たとえば、jsonバージョンの構文は、ALTER TABLE ステートメントで使用する構文と同じです。

設定は、コンパクション設定に触れるか、ノードを再起動する ALTER TABLE が実行されるまで保持されます。

コンパクションオプション log_all を有効にすると、より詳細なコンパクションログファイルがログディレクトリに生成されます。