ダンプと比較して、メジャーコンパクションは一般的に重要な操作であり、時間も比較的長くかかります。ベストプラクティスでは、通常1日に1回のメジャーコンパクション操作を行い、業務のオフピーク時に実施することが望ましいため、メジャーコンパクションは「日次コンパクション」と呼ばれることもあります。
メジャーコンパクション(Major Compaction)とは、動的および静的データをマージする操作であり、時間がかかるものです。ダンプによって生成された増分データが一定量蓄積された場合、Major Freezeを通じてメジャーバージョンのコンパクションが実現されます。これはダンプとの最大の違いとして、メジャーコンパクションはテナントが統一されたスナップショットポイントと対応する静的データをコンパクションする行為であり、最終的にはテナントレベルのスナップショットが形成されます。
| ミニコンパクション(Mini Compaction) | マイナーコンパクション(Minor Compaction) | メジャーコンパクション(Major Compaction) |
|---|---|---|
| パーティションまたはテナントレベルで、MemTableの物理化のみが行われる | パーティションレベル | テナントレベルで、テナントレベルのスナップショットが生成される |
| 各OBServerノード上の各テナントは、自身のMemTableのフリーズ操作を独立して決定し、プライマリとスタンバイのパーティション間では一貫性が保たれない | 各パーティションは、現在のSSTable(Mini SSTableおよびMinor SSTableを含む)の数に基づいて、パーティション内のマイナーコンパクションを実行する | テナントのすべてのパーティションで一括してMemTableのフリーズ操作が行われ、プライマリとスタンバイのパーティション間で一貫性が保たれることが求められる。コンパクション時にはデータの整合性チェックが行われる。 |
| 複数の異なるバージョンのデータ行を含む可能性がある | 複数の異なるバージョンのデータ行を含む可能性がある | スナップショットポイントのバージョン行のみを含む |
| 1つまたは複数のMemTableをミニSSTableとして永続化 | 複数のミニSSTableを1つのミニSSTableに統合するか、複数のミニSSTableと1つのマイナーSSTableを統合して新しいマイナーSSTableを生成する。この新しいSSTableには増分データのみが含まれ、最終的に削除される行は特別なマーカーが付けられる必要がある。 | コンパクションでは、現在の大きなバージョンのSSTableとMemTableを前の大きなバージョンの完全な静的データと統合し、新しい完全なデータを生成する。 |
メジャーコンパクションは時間がかかるものの、同時にデータベースに操作ウィンドウを提供します。このウィンドウ内でOceanBaseデータベースはメジャーコンパクションの特性を活用して複数の計算集約型タスクを完了し、全体的なリソース利用率を向上させることができます。
データ圧縮
メジャーコンパクション中、OceanBaseデータベースはデータに対して2層の圧縮を行います。1層目はデータベース内部でのセマンティックに基づくエンコード圧縮であり、2層目はユーザーが指定した圧縮アルゴリズムに基づく汎用的な圧縮です。lz4などの圧縮アルゴリズムを使用して、エンコード後のデータをさらに軽量化します。圧縮はストレージ容量を節約するだけでなく、クエリ性能も大幅に向上させます。現在、OceanBaseデータベースは(snappy、lz4、lzo、zstd)などの圧縮アルゴリズムをサポートしており、ユーザーは圧縮率と解凍時間の間でそれぞれバランスを取ることができます。MySQLやOracleもある程度データの圧縮をサポートしていますが、OceanBaseと比較すると、従来のデータベースは固定長ページ設計であるため、圧縮は避けられないストレージの空洞化を引き起こし、圧縮効率に影響を与えます。さらに重要なのは、OceanBaseデータベースのようなLSM-Treeアーキテクチャのストレージシステムでは、圧縮がデータ書き込み性能にほとんど影響を与えないということです。
データ検証
テナントレベルの一貫性スナップショットを用いたメジャーコンパクションにより、OceanBaseデータベースは容易に複数レプリカ間のデータ一貫性検証を行うことができます。メジャーコンパクション完了後、複数のレプリカはベースラインデータと直接比較することで、業務データが異なるレプリカ間で一貫していることを確認できます。また、このスナップショットベースラインデータを基に、主表とインデックス表のデータ検証を行い、主表とインデックス表間のデータの一貫性を保証することも可能です。
スキーマ変更
列の追加や削除などのスキーマ変更について、OceanBaseデータベースはメジャーコンパクション中にデータ変更操作を一括して完了できるため、DDL操作による業務への影響をよりスムーズにします。
統合方式
統合にはさまざまな方法があり、具体的な説明は以下の通りです。
フルコンパクション
フルコンパクションはOceanBaseデータベースの初期の統合アルゴリズムであり、HBaseやRocksDBのMajor Compactionプロセスと類似しています。フルコンパクションでは、現在の静的データをすべて読み出し、メモリ内の動的データと統合した後、新たな静的データとしてディスクに書き込みます。この過程で、すべてのデータが一度書き直されます。フルコンパクションはディスクI/Oと容量を大幅に消費するため、DBAが強制的に指示しない限り、現在のOceanBaseデータベースでは一般的に自動的にフルコンパクションは行われません。
インクリメンタルコンパクション
OceanBaseデータベースのストレージエンジンにおいて、マクロブロックは基本的なI/O書き込み単位です。多くの場合、すべてのマクロブロックが変更されるわけではありません。あるマクロブロックに増分変更がない場合、そのデータマクロブロックを直接再利用して統合を行うことができます。OceanBaseデータベースではこの統合方式をインクリメンタルコンパクションと呼んでいます。インクリメンタルコンパクションは統合作業量を大幅に削減し、現在OceanBaseデータベースのデフォルトの統合アルゴリズムとなっています。さらに、OceanBaseデータベースではマクロブロック内部でデータをより小さなマイクロブロックに分割しており、多くの場合、すべてのマイクロブロックが変更されるわけではありません。そのため、マイクロブロックを書き直す代わりに再利用することができます。マイクロブロックレベルのインクリメンタルコンパクションにより、統合時間がさらに短縮されます。
グラデーショナルコンパクション
ビジネスの急速な発展をサポートするため、ユーザーは避けられずにカラム追加、カラム削除、インデックス作成などの多くのDDL変更を行う必要があります。これらのDDL変更はデータベースにとって通常非常に高コストな操作です。MySQLは長い間オンラインDDL変更をサポートしていませんでした(バージョン5.6からようやくOnline DDLに対するサポートが改善されました)。そして今日に至るまで、DBAにとってMySQL 5.7でのOnline DDLは依然としてリスクの高い操作です。大規模なDDL変更はMySQLのプライマリ/スタンバイ間のレプリケーションラグを引き起こす可能性があるためです。
OceanBaseデータベースは設計段階からOnline DDLのニーズを考慮しており、現在ではOceanBaseデータベースにおけるカラム追加、カラム削除、インデックス作成などのDDL操作は読み書きをブロックせず、複数レプリカ間のPaxos同期にも影響を与えません。カラム追加・削除のDDL変更はリアルタイムで有効になり、ストレージデータへの変更は日次統合時にまとめて行われます。しかし、カラムの追加・削除など一部のDDL操作では、すべてのデータを一度書き直す必要があります。もし一度の日次統合処理ですべてのデータの書き直しが完了すると、ストレージ容量と統合時間に大きな負担がかかります。この問題を解決するため、OceanBaseデータベースはグラデーショナルコンパクションを導入し、DDL変更によるデータの書き直しを複数回の日次統合に分散して行います。例えば、グラデーショナルラウンド数を60に設定すると、一度の統合ではデータの60分の1だけが書き直され、60ラウンドの統合後にデータ全体が一度書き直されます。グラデーショナルコンパクションはDBAのDDL操作による負担を軽減し、同時にDDL変更をよりスムーズにします。
パラレルコンパクション
OceanBaseデータベースV1.0ではパーティションテーブルのサポートが追加されました。異なるデータパーティションに対して、統合は並行して行われます。ただし、データの偏りにより、特定のパーティションのデータ量が非常に大きくなる場合があります。インクリメンタルコンパクションは統合するデータ量を大幅に削減しますが、頻繁に更新されるビジネスにおいては、統合するデータ量が依然として非常に大きい場合があります。そのため、OceanBaseデータベースはパーティション内のパラレルコンパクションを導入しました。統合ではデータを異なるスレッドに分割して並行して統合を行うため、統合速度が大幅に向上します。
マージトリガー
マージトリガーには、自動トリガー、スケジュールトリガー、手動トリガーの3種類があります。
テナントのフリーズ(Minor Freeze)回数がしきい値を超えると、そのテナントのマージが自動的にトリガーされます。
パラメータ設定により、毎日の業務オフピーク時にマージをスケジュールしてトリガーすることもできます。
obclient> ALTER SYSTEM SET major_freeze_duty_time = '02:00' TENANT = t1;以下の運用コマンドを使用して、手動でマージをトリガーすることもできます。
システムテナントが他のテナントのマージを開始する
sysテナントに対するマージの開始obclient> ALTER SYSTEM MAJOR FREEZE TENANT = sys;すべてのユーザーテナントに対するマージの開始
obclient> ALTER SYSTEM MAJOR FREEZE TENANT = all_user;すべてのMETAテナントに対するマージの開始
obclient> ALTER SYSTEM MAJOR FREEZE TENANT = all_meta;テナントt1とt2に対するマージの開始
obclient> ALTER SYSTEM MAJOR FREEZE TENANT = t1,t2;
ユーザーテナントが自身のテナントのマージを開始する
obclient> ALTER SYSTEM MAJOR FREEZE;
関連ドキュメント
その他のマージ操作については、マージを参照してください。