コンパクション・ストラテジの選択
最適なコンパクション・ストラテジを選択する方法に関する情報。
選択したコンパクション・ストラテジを実装するには:
- コンパクションおよびコンパクション・ストラテジの仕組みを理解するには、「データはどのように維持されるか」を参照してください。
- アプリケーションの要件を確認し、この情報を使用して以下の質問に答えてください。
- 最も適切なストラテジを使用するようにテーブルを構成します。
- 実際のデータに対してコンパクション・ストラテジをテストします。
最適なコンパクション・ストラテジ
以下の質問は、ストラテジを使用する開発者とユーザーの経験に基づいています。
- テーブルは時系列データを処理しますか?
- その場合、コンパクション・ストラテジTWCSが最適です。それ以外の場合は、以下の質問で選択の指針となるその他の考慮事項を確認してください。
- テーブルで、読み取りと書き込みのどちらをより多く処理しますか?
- LCSは、テーブルで読み取りを書き込みの2倍以上処理する場合、特にランダムな読み取りを処理する場合に適しています。読み取りの割合が書き込みに近い場合、LCSがもたらすパフォーマンスへの影響はそのメリットに見合わないことがあります。大量の書き込みがある場合、LCSのパフォーマンスが低下する可能性があることに注意してください。
- テーブル内のデータは頻繁に変更されますか?
- LCSのメリットの1つは、関連するデータを小さなSSTableセットに保持することです。データが不変な場合、または頻繁なupsertの対象でない場合、STCSはLCSパフォーマンスに影響を及ぼすことなく同様のグループ分けを行います。
- 読み取りと書き込みのアクティビティー・レベルが予測可能である必要がありますか?
- LCSを使用するとSSTableが予測可能なサイズと数に保たれます。たとえば、テーブルの読み取り/書き込み率が小さく、読み取りのサービス・レベル・アグリーメント(SLA)に準拠することが予想される場合は、読み取り速度とレイテンシーを予測可能なレベルに維持するためにLCSの書き込みパフォーマンス・ペナルティーを受ける価値があります。また、水平方向のスケーリング(ノードの追加)によってこの書き込みペナルティーを解消できる場合があります。
- バッチ処理でテーブルにデータが追加されますか?
- STCSは、読み取りと書き込みのどちらのバッチ処理でもLCSよりも優れたパフォーマンスを発揮します。バッチ処理では断片化がほとんど生じないので、LCSのメリットはありません。バッチ処理を行うとLCS構成のテーブルのパフォーマンスは低下する可能性があります。
- システムのディスク領域は限られていますか?
- LCSはSTCSよりも効率的にディスク領域を処理します。LCSでは、処理するデータが占める領域に加えて、約10%のヘッドルームが必要です。STCSとDTCSでは一般に、データ領域よりも50%も多く必要とする場合があります。DateTieredStorageStrategy(DTCS)は廃止される予定です。
- システムがI/Oの上限に達していますか?
- LCSでは、DTCSとSTCSよりもはるかにI/Oが多くなります。LCSに切り替えると、余分なI/O負荷が生じてメリットが相殺される場合があります。
コンパクションの構成と実行
CREATE TABLEコマンドまたはALTER TABLEコマンドのパラメーターで、テーブルのコンパクション・ストラテジを設定します。詳細については、「table_options」を参照してください。
nodetool compactコマンドを使用して、手動でコンパクションを開始することができます。
コンパクション・ストラテジのテスト
システムに最適なコンパクション・ストラテジを決定するための提案事項:
- コンパクション・ストラテジのいずれかを使用して3ノード・クラスターを作成し、cassandra-stressを使用してクラスターのストレス・テストを行い、結果を測定します。
- 既存のクラスターにノードを設定し、書き込みサーベイ・モードを使用して生データをサンプリングします。