データはどのように維持されるか
DataStax Enterpriseデータベースは、書き込みパスの複数の段階でデータを処理します。健全なSSTableを維持するためのコンパクションは、書き込みパス・プロセスの最後の段階です。
DataStax Enterprise（DSE）データベースの書き込みプロセスでは、SSTableと呼ばれるファイルにデータを格納します。SSTableは不変です。データベースは、既存の行を挿入や更新で上書きするのではなく、挿入または更新したデータの新しいバージョンをタイムスタンプ付きで新しいSSTableに書き込みます。削除されたデータを除去することで削除を行うわけではありません。代わりに、データベースは削除されたデータにトゥームストーンのマークを付けます。
時間が経過するにつれて、データベースは多くのバージョンの行をさまざまなSSTableに書き込むようになります。各バージョンには、タイムスタンプが異なる一連の固有のカラムが格納されていることがあります。SSTableが累積するにつれて、データ分散では、完全な行を取得するために、さらに多くのSSTableにアクセスする必要があります。
データベースを健全な状態に保つために、データベースは定期的にSSTableをマージし、古いデータを破棄します。このプロセスはコンパクションと呼ばれます。
コンパクション
コンパクションは、SSTableの収集に対して機能します。コンパクションでは、これらのSSTableから一意の各行のバージョンをすべて収集し、各行のカラムの最新バージョン（タイムスタンプ順）を使用して1つの完全な行にまとめます。各SSTable内のpartition keyで行がソートされるため、マージ・プロセスの効率が向上し、プロセスではランダムI/Oが使用されません。各行の新しいバージョンは、新しいSSTableに書き込まれます。古いバージョンと削除の準備ができている行は古いSSTableに残され、保留中の読み取りが完了すると削除されます。
コンパクションにより、古いSSTableと新しいSSTableが共存するため、ディスク領域の使用量とディスクI/Oが一時的に増加します。コンパクションが完了すると、古いSSTableにより占有されていたディスク領域が解放されます。段階的に古いSSTableをコンパクションされたSSTableに置き換えることで、読み取りパフォーマンスが向上します。データベースは、書き込みの終了前であっても、コンパクション・プロセス全体の終了を待たずに、新しいSSTableからデータを直接読み取ることができます。
DSEは、書き込みと読み取りの処理時に古いSSTableをメモリー内の新しいSSTableに置き換えることで、負荷が大きい場合でも予測可能な高パフォーマンスを提供します。新しいSSTableのキャッシュ操作はインクリメンタルであり、古いSSTableからの読み取りを指示しながら、極端なキャッシュ・ミス・ストームを起こしません。
コンパクション・ストラテジ
DSEデータベースは、さまざまなコンパクション・ストラテジをサポートしています。これらのストラテジは、コンパクションにどのSSTableを選択し、コンパクションされた行をどのように新しいSSTableにソートするかを制御します。各ストラテジには独自の強みがあります。以下のセクションでは、各コンパクション・ストラテジについて説明します。
以下の各セクションは一般的な推奨事項から始まりますが、多くの要因によりコンパクション・ストラテジの選択が複雑になっています。「コンパクション・ストラテジの選択」を参照してください。
- SizeTieredCompactionStrategy（STCS）
-
書き込みが多いワークロードに推奨されます。
- 長所：書き込みが多いワークロードを適切にコンパクションする。
- 短所：古いデータが長時間保持される場合がある。必要なメモリーが時間とともに増加する。
SizeTieredCompactionStrategy（STCS）は、データベースで同じようなサイズのSSTableが設定された数（デフォルトは4）まで累積すると、コンパクションを開始します。STCSは、これらのSSTableを1つの大きなSSTableにマージします。大きなSSTableが累積すると、STCSは、これらをさらに大きなSSTableにマージします。ある時点では、さまざまなサイズの複数のSSTableが存在します。
図 2. 何度も挿入した後のサイズ階層化コンパクション 
STCSは、書き込みが多いワークロードのコンパクションには効果的ですが、サイズごとのマージ・プロセスはデータを行別にグループ分けしないため、読み取り速度が低下します。これにより、特定の行のバージョンが多くのSSTableに分散する可能性が高くなります。また、STCSは、コンパクションのトリガーがSSTableサイズであり、SSTableが古いデータをマージおよび排除するのに十分な速さで増大しない可能性があるため、削除されたデータを予想通りに排除しません。最大サイズのSSTableが増大すると、STCSコンパクション中に、新しいSSTableと古いSSTableの両方に必要なディスク領域がノード上の通常のディスク領域を超えてしまう可能性があります。
- LeveledCompactionStrategy（LCS）
-
読み取りが多いワークロードに推奨されます。
- 長所：ディスク要件が予測しやすい。読み取り操作のレイテンシーが予測しやすい。古いデータがより高頻度で排除される。
- 短所：I/O使用率が非常に高くなるため、操作のレイテンシーに影響を及ぼす。
LeveledCompactionStrategy（LCS）は、STCSでの読み取り操作の問題の一部を軽減します。このストラテジは、一連のレベルで機能します。最初に、memtable内のデータを最初のレベル（L0）のSSTableにフラッシュします。LCSコンパクションは、これらの最初のSSTableを、レベルL1のより大きなSSTableとマージします。
図 3. 平準化されたコンパクション — SSTableの追加 
L1より大きいレベルのSSTableは、
sstable_size_in_mb（デフォルトは160 MB）以上のサイズのSSTableにマージされます。L1 SSTableがL2より大きいパーティションのデータを格納する場合、LCSはSSTableをL2の次のレベルに移動します。図 4. 何度も挿入した後の平準化されたコンパクション 
L0以上の各レベルでは、LCSはほぼ同じサイズのSSTableを作成します。各レベルは、最後のレベルのサイズの10倍であるため、レベルL1はL0のSSTable数の10倍になり、レベルL2では100倍になります。コンパクションの結果がレベルL1の10個のSSTableを超える場合、余分なSSTableはレベルL2に移動されます。注: LCSを使用する場合の最大オーバーヘッドは、N-1レベルの合計であることに注意してください。たとえば、最大テーブル・サイズが160 MBの場合（レベル3を超える）、オーバーヘッド要件はレベル4の1.7テラバイトからレベル5の17テラバイトに大幅に拡大します。L0 1 * 160 MB = 160 MB L1 10 * 160 MB = 1600 MB L2 100 * 160 MB = 16000 + 1600 = 17 GB L3 1000 * 160 MB = 160000 + 1600 + 16000 = 177 GB L4 10000 * 160 MB = 1600000 + 1600 + 16000 + 160000 = 1.7 TB L5 100000 * 160 MB = 16000000 + 1600 + 16000 + 160000 + 1600000 = 17 TB
この状況を緩和するには、STCSに切り替えてノードを追加するか、sstablesplitを使用してSSTableサイズを縮小します。LCSコンパクション・プロセスにより、L1から始まる各レベル内のSSTableにはオーバーラップするデータがないことが保証されます。このプロセスにより、多くの読み取りについて、データベースは1つまたは2つのSSTableからすべての必須データを取得できるようになります。実際、すべての読み取りの90%は、1つのSSTableから取得できます。ただし、LCSはL0のテーブルをコンパクションしないため、多くのL0 SSTableが関与するリソース使用量の多い読み取りが発生する可能性があります。
L0より上のレベルでは、コンパクションに必要なディスク領域が少なくなります。通常は、SSTableの固定サイズの10倍です。古いデータは、より高い頻度で排除されるため、削除されたデータが使用するディスク上のSSTableはさらに少なくなります。ただし、LCSコンパクション操作は頻繁に実行されるため、より多くのI/Oの負荷をノードに与えます。書き込みが多いワークロードでは、このストラテジを使用するメリットがI/O操作のパフォーマンスの損失に見合いません。多くの場合、LCS構成のテーブルのテストにより、書き込みおよびコンパクションでのI/O飽和が判明します。
注: LCSを使用して新しいノードをクラスターにブートストラップする場合、データベースはコンパクション操作をバイパスします。既存のデータがないため、元のデータが正しいレベルに直接移動され、レベルごとのパーティションの重複がなくなります。詳細については、「Apache Cassandra 2.2 - レベル化コンパクションのためのパフォーマンス向上のブートストラップ」ブログを参照してください。
- TimeWindowCompactionStrategy（TWCS）
- 時系列のデータおよび期限切れになるTime To Live（TTL）ワークロードに推奨されます。
- 長所：時系列データに適しており、すべてのデータにデフォルトのTTLを使用するテーブルに格納されます。TWCSの導入により廃止予定の、DateTieredCompactionStrategy（DTCS）よりも単純な構成。
- 短所：SSTableもコンパクションを行わないため、シーケンス外の時間データが必要な場合には適さない。また、ストレージが際限なく増大するため、TTLのないデータにも適さない。DTCSを使用したときよりも構成の微調整の精度が落ちる可能性がある。
TimeWindowCompactionStrategy（TWCS）は、設定が簡単なDTCSに似ています。TWCSは、一連の時間枠を使用してSSTableをグループ分けします。TWCSは、コンパクション時に、最新の時間枠の中でコンパクションされていないSSTableにSTCSを適用します。時間枠が終了すると、TWCSは、SSTableの最大タイムスタンプに基づいて、その時間枠に入るすべてのSSTableを1つのSSTableにコンパクションします。時間枠のメジャー・コンパクションが完了すると、データのそれ以上のコンパクションは行われませんが、トゥームストーン・コンパクションはcompaction_windowのしきい値を超えた後でも、SSTableで実行できます。プロセスは、次の時間枠に書き込まれたSSTableを使用して、もう一度やり直します。注: すべてのセルにTime To Live（TTL）が適用されているテーブル、またはデフォルトのTTLを使用するテーブルの場合、すべてのTTLが渡されると、gc_grace_seconds期間が期限切れになり、削除可能なトゥームストーンの比率が100%になると、SSTableはコンパクションなしで削除できます。図 5. TimeWindowCompactionStrategyの仕組み 
図に示すように、午前10時から午前11時までの間に、memtableがメモリーから100MBのSSTableにフラッシュされます。これらのSSTableは、STCSを使用して、より大きなSSTableにコンパクションされます。午前11時に、これらすべてのSSTableが1つのSSTableにコンパクションされます。以降、TWCSによって再度コンパクションされることはありません。
午後12時に、午前11時～午後12時の間に作成された新しいSSTableがSTCSを使用してコンパクションされ、時間枠が終了すると、TWCSコンパクションが繰り返されます。各TWCS時間枠にはさまざまな量のデータが含まれていることに注意してください。
TWCS構成には以下の2つの主要プロパティがあります。
- compaction_window_unit：時間枠のサイズ（ミリ秒、秒、時間など）を定義するために使用される時間単位
- compaction_window_size：時間枠当たりの単位の数（1、2、3など）
上記の構成例は次のとおりです。
compaction_window_unit = ‘minutes’,compaction_window_size = 60
- DateTieredCompactionStrategy（DTCS） - 廃止予定
-
代わりに、TimeWindowCompactionStrategy（TWCS）を使用します。
DateTieredCompactionStrategy（DTCS）はSTCSに似ています。ただし、DTCSでは、SSTableサイズに基づいてコンパクションするのではなく、SSTable ageに基づいてコンパクションします。SSTableの各カラムには、書き込み時にタイムスタンプが付けられます。SSTableのageとして、DTCSはSSTableに含まれるカラムのうち最も古い（最小）タイムスタンプを使用します）。