コンパクションの構成

「コンパクション」で説明されているように、コンパクション・プロセスは、キーをマージし、カラムを結合し、トゥームストーンを排除し、SSTableを統合し、マージされたSSTableに新しいインデックスを作成します。

cassandra.yamlファイルでは、以下のグローバルなコンパクション・パラメーターを構成します。

• snapshot_before_compaction
• concurrent_compactors
• compaction_throughput_mb_per_sec

compaction_throughput_mb_per_sec パラメーターは、大きいパーティションを対象として使用することを意図しています。これは、コンパクションをシステム全体で指定された合計スループットにスロットルします。

Cassandraには、実稼働環境のワークロードに影響を及ぼさずにコンパクション・ストラテジのテストを行うための起動オプションがあります。

CQLを使用して、コンパクション・ストラテジを構成します。

• SizeTieredCompactionStrategy（STCS）：デフォルトのコンパクション・ストラテジ。このストラテジは、ディスク上に、min_thresholdテーブル・サブプロパティで構成されているサイズに似たサイズのSSTableがいくつかあるときに、マイナー・コンパクションを発動します。マイナー・コンパクションでは、キースペースのすべてのテーブルが関与するわけではありません。「STCSコンパクション・サブプロパティ」も参照してください。
• DateTieredCompactionStrategy（DTCS）：このストラテジは時系列データの場合に特に役立ちます。DateTieredCompactionStrategyは、特定の期間内に書き込まれたデータを同じSSTableに格納します。たとえば、Cassandraは過去1時間のデータを1つのSSTable時間枠に格納し、次の4時間のデータを別の時間枠に格納できます。これらの時間枠でSSTableのmin_threshold（デフォルトでは4）に達すると、コンパクションがトリガーされます。時系列ワークロードに対する最も一般的なクエリーでは、データの最後の時刻/日/月が取得されます。CassandraではSSTableを制限し、関連データを含むSSTableのみが返されるようにすることができます。また、TTLを使用して期限切れとなるように設定されているデータを、だいたい同じ時刻に期限切れとなるようにスケジュールされている他のデータとともにSSTableに格納できます。その後、コンパクションを行わずにそのSSTableを削除できます。「DTCSコンパクション・サブプロパティ」および「DateTieredCompactionStrategy: Compaction for Time Series Data」も参照してください。
  注: DTCSを使用する場合は、読み取りリペアを無効にすることが推奨されます。必要に応じて、フル・リペアを使用します。
• LeveledCompactionStrategy（LCS）：レベル化コンパクション・ストラテジでは、いくつかのレベルにグループ分けされる、固定の、比較的小さなサイズ（デフォルトでは160 MB）のSSTableが作成されます。各レベル内で、SSTableがオーバーラップすることはありません。各レベル（L0、L1、L2など）は、1つ下のレベルに比べると10倍大きくなっています。SSTableは、継続的に、次第により大きなレベルへとコンパクションされていくため、レベルが低い場合よりもレベルが高い方が、ディスクI/Oが均等化され予測しやすくなります。レベルごとに、行キーはオーバーラップしないSSTableにマージされます。Cassandraが、各レベルのどのSSTableで行キー・データの有無を調べるかを特定できるため、読み取りのパフォーマンスが向上します。このコンパクション・ストラテジは、Googleのleveldb実装をモデルにしています。「LCSコンパクション・サブプロパティ」も参照してください。

コンパクション・ストラテジのプロパティおよびCQLのコンパクション・サブプロパティ（コンパクション対象にできるSSTableの最大数や最小のSSTableのサイズなど）を構成するには、CREATE TABLEまたはALTER TABLEを使用します。