データはどのように維持されるか

コンパクション 

Cassandraでは、その場での挿入/更新が行われないので、定期的なコンパクションを行って、Cassandraデータベースを健全な状態に保つ必要があります。挿入/更新が起きると、行を上書きする代わりに、挿入または更新されたデータの新しいバージョンをタイムスタンプ付きで別のSSTableに書き込みます。Cassandraではまた、SSTableが不変なため、その場での削除が行われません。代わりに、削除対象データには、トゥームストーンのマークが付けられます。トゥームストーンは、テーブルに対して設定されたgc_grace_secondsの値によって定義される構成された期間だけ存在します。

時間が経過するにつれて、多くのバージョンの行がさまざまなSSTableに存在する場合があります。各バージョンには、異なるカラムのセットが格納されています。SSTableが累積するにつれて、データの行全体を取得するためにより多くのSSTableが読み取られる必要があります。

コンパクションは、パーティション・キーごとに、タイムスタンプに基づいてストレージの最新データを選択して、各SSTableのデータをマージします。各SSTable内のパーティション・キーによって行がソートされるため、マージ・プロセスではランダムI/Oが使用されず、効率が向上します。トゥームストーンを排除して、削除されたデータ、カラム、および行を除去した後、コンパクション・プロセスはSSTableを1つの新しいSSTableファイルに統合します。古いSSTableファイルは、継続中の読み取りによるファイルの使用が終了すると、すぐに削除されます。

コンパクション中は、古いSSTableと新しいSSTableが共存するため、ディスク領域の使用量とディスクI/Oが一時的に増加します。古いSSTableで占められていたディスク領域は、新しいSSTableの準備が整うと、再利用が可能になります。Cassandra 2.1以降では、コンパクションされたSSTableのインクリメンタル置換のため、コンパクション後の読み取りパフォーマンスが向上します。Cassandraでは、コンパクション全体の終了を待ち、古いSSTableを破棄する代わりに、書き込みの終了前であっても、新しいSSTableからデータを直接読み取ることができます。

データが新しいSSTableに書き込まれ、読み取りが指示されると、古いSSTableの対応するデータはアクセスされなくなり、ページ・キャッシュから排除されます。このように、新しいSSTableのキャッシュのインクリメンタル・プロセスが開始され、古いSSTableからの読み取りの終了を指示しながら、極端なキャッシュの損失を防止します。Cassandraは、大きな負荷のもとでも、予測可能な高いパフォーマンスを発揮します。

コンパクションの種類 

さまざまなコンパクション・ストラテジがあり、強みと弱みがあります。各種類の機能を理解することは、アプリケーション・ワークロードを選択するのに重要です。書き込みが多いワークロードには、SizeTieredCompactionStrategy（STCS）が推奨されます。読み取りが多いワークロードには、LeveledCompactionStrategy（LCS）が推奨されます。時系列のデータおよび期限切れになるTTLデータには、DateTieredCompactionStrategy（DTCS）が推奨されます。

SizeTieredCompactionStrategy（STCS）

書き込みが多いワークロードに推奨されます。

長所：書き込みが多いワークロードを適切にコンパクションする。

短所：長時間にわたって古いデータが保持される場合がある。必要とされるメモリー量が長時間にわたって増加します。

SizeTieredCompactionStrategy（STCS）は、同じようなサイズの多数の（デフォルトは４）SSTableが累積すると、コンパクションを開始します。コンパクションによってSSTableがマージされ、大きな1つのSSTableが作成されます。より大きなSSTableが累積すると、同じプロセスが発生し、より大きなSSTableをさらに大きなSSTableにマージします。ある時点では、さまざまなサイズの複数のSSTableが存在します。このストラテジは書き込みが多いワークロードをコンパクションするのに十分に機能しますが、読み取りが必要な場合、ある行のすべてのデータを見つけるために複数のSSTableが取得される必要があります。行のデータが少数のSSTableに制限される保証はありません。また、削除されたデータの排除が不均一であることが予測され、SSTableサイズがコンパクションのトリガーであるため、SSTableが古いデータをマージおよび排除するのに十分な速さで増大しない場合があります。最大サイズのSSTableが増大すると、新しいSSTableと古いSSTableの両方を同時に保持するためにコンパクションに必要なメモリー量がノード上の通常のRAMの容量を超えてしまう可能性があります。

LeveledCompactionStrategy（LCS）

読み取りが多いワークロードに推奨されます。

長所：メモリー要件が単純で予測しやすい。読み取り操作のレイテンシーが予測しやすい。古いデータがより高頻度で排除される。

短所：I/O使用率が非常に高くなるため、操作のレイテンシーが影響を受ける可能性がある。

LeveledCompactionStrategy（LCS）は、SizeTieredCompactionStrategy（STCS）での読み取り操作の問題の一部を軽減することを意図しています。SSTableが特定の小さな固定サイズ（デフォルトは5MB）に達すると、最初のレベルであるL0に書き込まれ、最初のレベルであるL1にマージされます。各レベル内で、L1から開始され、すべてのSSTableのデータがオーバーラップすることはありません。データがオーバーラップしないため、LeveledCompactionStrategyでは場合によってはSSTableを分割およびマージし、ファイルを同じようなサイズに保持します。各レベルは、最後レベルのサイズの10倍であるため、レベルL1はL0のSSTable数の10倍になり、レベルL2では100倍になります。レベルL2は、L1が満杯になると開始されます。レベルにはオーバーラップするデータが含まれていないため、読み取りは非常に効率的に実行され、SSTableはほとんど取得されません。多くの読み取り操作について、読み取られるSSTableは1つか、2つです。実際、すべての読み取りの90%は、1つのSSTableの読み取りからで済みます。最悪な例は、レベルごとに1つのSSTableを読み取る必要がある場合です。このストラテジを使用すれば、コンパクションに必要なメモリーは少なくて済み、必要なSSTableの固定サイズの10倍です。古いデータは、より高い頻度で排除されるため、削除されたデータがディスク上のSSTableで占める割合はさらに少なくなります。ただし、LeveledCompactionStrategy（LCS）のコンパクション操作は頻繁に実行されるため、より多くのI/Oの負荷をノードに与えます。書き込みが多いワークロードでは、このストラテジを使用するメリットがI/O操作のパフォーマンスの損失に見合いません。Cassandra 2.2以降では、パフォーマンスが向上し、新しいノードをブートストラップする際のLCSを使用したクラスターへのコンパクション操作がバイパスされます。既存のデータがないため、元のデータが正しいレベルに直接移動され、レベルごとのパーティションの重複がなくなります。詳細については、「Apache Cassandra 2.2 - Bootstrapping Performance Improvements for Leveled Compaction」を参照してください。

DateTieredCompactionStrategy（DTCS）

時系列のデータおよび期限切れになるTTLワークロードに推奨されます。

長所：特に時系列のデータ向けに設計されている。

短所：順序を違反したデータの挿入はエラーの原因になる可能性がある。DTCSを使用する場合、読み取りリペアはオフにする必要があります。

DateTieredCompactionStrategy（DTCS）は、STCSと同じように機能しますが、SSTableサイズに基づいてコンパクションする代わりに、DTCSではSSTable ageに基づいてコンパクションを行います。時間枠が構成可能なため、マージされたSSTableで新しいデータと古いデータが混在しません。実際、DateTieredCompactionStrategy（DTCSO）では、Time-To-Live（TTL）タイムスタンプを使用することで、期限切れの古いデータについてSSTable全体が取り出されることがあります。このストラテジでは、時系列のデータが一定の速度で取り込まれるためSSTableのサイズが似たようになることがあります。SSTableは、SSTable数の特定の最小しきい値が構成可能な時間間隔内に達するとマージされます。SSTableは、要求されたSSTable数が時間間隔内に含まれると、サイズ階層化コンパクションと同様により大きなテーブルにマージされます。ただし、SSTableは、構成可能なageに達した後はコンパクションされず、データが再度書き込まれる回数は減少します。このストラテジを使用してコンパクションされたSSTableは、非常に効率的にデータの最後の時間の価値を要求するクエリーについて特に読み取られます。このストラテジを使用したときに困難を引き起こす可能性がある1つの問題は順序を違反した書き込みで、たとえば、タイムスタンプ付きのレコードが過去のタイムスタンプで書き込まれた場合です。読み取りリペアによって順序を違反したタイムスタンプが挿入される場合があるため、DateTieredCompactionStrategyを使用する場合は読み取りリペアをオフにしてください。コンパクション・ストラテジの詳細については、「When to Use Leveled Compaction」および「Leveled Compaction in Apache Cassandra」を参照してください。DateTieredCompactionStrategyについては、「DateTieredCompactionStrategy:Notes from the Field」、「Date-Tiered Compaction in Cassandra」、または「DateTieredCompactionStrategy:Compaction for Time Series Data」を参照してください。

コンパクションの開始 

nodetool compactコマンドを使用して、手動でコンパクションを開始することができます。