OceanBaseデータベースのストレージエンジンは、LSM-Treeアーキテクチャに基づいており、データを静的なベースラインデータ（SSTableに格納）と動的な増分データ（MemTableに格納）の2つに分類します。SSTableは読み取り専用であり、一度生成されると変更されることはなく、ディスクに保存されます。MemTableは読み書きが可能で、メモリに保存されます。データベースのDML操作（挿入、更新、削除など）はまずMemTableに書き込まれ、MemTableが一定のサイズに達すると、ディスクにダンプされてSSTableとなります。クエリ実行時には、SSTableとMemTableに対して個別にクエリを実行し、その結果をマージしてSQL層に返します。同時に、メモリ内にBlock CacheとRow Cacheを実装しており、ベースラインデータへのランダムアクセスを回避します。
メモリ内の増分データが一定規模に達すると、増分データとベースラインデータのコンパクションがトリガーされ、増分データがディスクに永続化されます。また、毎晩のアイドルタイムには、システムが自動的に日次コンパクションも実行します。
OceanBaseデータベースは本質的にベースラインと増分のストレージエンジンであり、LSM-Treeアーキテクチャの利点を維持しつつ、従来のリレーショナルデータベースのストレージエンジンの一部の利点も取り入れています。
従来のデータベースではデータを多数のページに分割しますが、OceanBaseデータベースも従来のデータベースの考え方を参考にし、データファイルを2MBを基本単位として複数のマクロブロックに分割し、さらに各マクロブロック内部で可変長のマイクロブロックを複数作成します。コンパクション時には、マクロブロック単位でデータの再利用が行われ、更新されていないデータのマクロブロックは再度開いて読み取られることはありません。これにより、コンパクション期間中のライトアマウントをできるだけ抑え、従来のLSM-Treeアーキテクチャのデータベースと比較してコンパクションコストを大幅に低減します。
OceanBaseデータベースはベースラインと増分の設計を採用しているため、一部のデータはベースラインに、一部は増分に存在します。原理的には、各クエリではベースラインと増分の両方を読み取る必要があります。このため、OceanBaseデータベースでは特に単一行に対する最適化を含む多くの最適化が施されています。OceanBaseデータベース内部では、データブロックに対するキャッシュに加えて行キャッシュも行われ、行キャッシュは単一行のクエリ性能を大幅に高速化します。行が存在しない「空クエリ」に対しては、ブルームフィルターを構築し、そのブルームフィルターをキャッシュします。OLTP業務のほとんどの操作は小規模なクエリであり、小規模クエリの最適化により、OceanBaseデータベースは従来のデータベースがデータブロック全体を解析するオーバーヘッドを回避し、メモリデータベースに近い性能を実現しています。さらに、ベースラインデータは読み取り専用であり、内部では連続ストレージ方式を採用しているため、OceanBaseデータベースは比較的過激な圧縮アルゴリズムを使用できます。これにより、高い圧縮率を実現しつつもクエリ性能に影響を与えず、コストを大幅に削減できます。
古典的なデータベースの一部の利点を組み合わせて参考にすることで、OceanBaseデータベースはより汎用的なLSM-Treeアーキテクチャのリレーショナルデータベースストレージエンジンを提供し、以下の特徴を備えています：
低コスト：LSM-Treeのデータ書き込み後の更新不要という特性を活用し、独自の行列混合エンコーディングと汎用的な圧縮アルゴリズムを組み合わせることで、OceanBaseデータベースのデータストレージ圧縮率は従来のデータベースと比較して10倍以上向上します。
やさしさ：他のLSM-Treeデータベースとは異なり、OceanBaseデータベースはアクティブトランザクションの永続化をサポートすることで、ユーザーの大規模・長時間トランザクションの正常な実行やロールバックを保証し、多段階のコンパクションとダンプメカニズムを通じて、パフォーマンスと容量の間でより良いバランスを見つける手助けをします。
高パフォーマンス：一般的なポイントルックアップクエリに対しては、OceanBaseデータベースは複数段階のキャッシュを用いて極めて低い応答遅延を保証します。範囲スキャンに対しては、ストレージエンジンがデータエンコーディングの特性を活用してクエリフィルタ条件の計算をダウンストリーミングし、ネイティブなベクトル化サポートを提供します。
高信頼性：全リンクのデータ検証に加えて、ネイティブ分散型の利点を活用し、OceanBaseデータベースはグローバルコンパクション時に複数レプリカ間の比較および主表とインデックス表間の比較検証を行うことで、ユーザーデータの正確性を保証します。同時に、バックグラウンドスレッドによる定期的なスキャンを提供し、静的エラーを回避します。
ストレージエンジンの機能
機能モジュールによる分類では、OceanBaseデータベースのストレージエンジンは大まかに以下のいくつかの部分に分けられます。
データストレージ
データの組織化
他のLSM-Treeデータベースと同様に、OceanBaseデータベースもデータをメモリ上の増分データ（MemTable）と静的データ（SSTable）の2つの階層に分けています。SSTableは読み取り専用であり、一度生成されると変更されることはなく、ディスクに保存されます。MemTableは読み書きが可能で、メモリ上に保存されます。データベースのDML操作である挿入、更新、削除などはまずMemTableに書き込まれ、MemTableが一定のサイズに達すると、ディスク上のSSTableへとダンプされます。
さらに、OceanBaseデータベースでは、SSTableはMini SSTable、Minor SSTable、Major SSTableの3種類に細分化されます。MemTableはMini Compactionによってデータをディスク上のMini SSTableに転送し、複数のMini SSTableが一定のしきい値に達すると、Minor CompactionがトリガーされてMini SSTableまたはMinor SSTableとなります。また、OceanBaseデータベース特有の日次コンパクションが開始されると、各パーティションの元のベースラインSSTable（Major SSTable）とすべてのMini SSTableおよびMinor SSTableが統合されて新しいMajor SSTableとなります。
ストレージ構造
OceanBaseデータベースでは、各パーティションの基本ストレージ単位は個々のSSTableであり、すべてのストレージの基本粒度はマクロブロックです。データベース起動時に、データファイル全体を2MBの固定長でマクロブロックに分割します。各SSTableは実質的に複数のマクロブロックの集合体です。
各マクロブロック内部はさらに複数のマイクロブロックに分割されます。マイクロブロックという概念は従来のデータベースのページやブロックと似ていますが、LSM-Treeの特性を活用しているため、OceanBaseデータベースのマイクロブロックは圧縮されて長さが変化します。マイクロブロックの圧縮前のサイズは、テーブル作成時に指定する
block_sizeで決定できます。マイクロブロックはユーザーが指定したストレージ形式に応じて、encoding形式またはflat形式で格納されます。encoding形式のマイクロブロックでは、内部データは行と列のハイブリッドモードで保存されます。flat形式のマイクロブロックでは、すべてのデータ行がフラットに保存されます。
圧縮エンコーディング
OceanBaseデータベースは、マイクロブロック内のデータをユーザーが指定した形式に基づいてエンコードおよび圧縮します。ユーザーテーブルでencodingが有効になっている場合、各マイクロブロック内のデータは列ごとにそれぞれエンコードされます。エンコードルールには、辞書/ラン/定数/差分などが含まれます。各列の圧縮が完了すると、さらに複数の列に対して列間の等値/部分文字列などのルールでエンコードが行われます。エンコードにより、ユーザーはデータを大幅に圧縮できるだけでなく、抽出された列内の特徴情報によって後続のクエリ速度もさらに高速化されます。
エンコード圧縮後、OceanBaseデータベースはユーザーが指定した汎用的な圧縮アルゴリズムを用いてマイクロブロックデータに対して無損失圧縮を行うこともでき、データ圧縮率をさらに向上させることができます。
ダンプコンパクション
ダンプ
ダンプには2つのプロセスが含まれます：Mini CompactionとMinor Compaction。メモリ上のMemTableのサイズが一定のしきい値を超えると、MemTable内のデータをディスク上のMini SSTableに転送してメモリを解放する必要があり、このプロセスをMini Compactionと呼びます。ユーザーデータの書き込みに伴い、Mini SSTableの数が増え続けると、Mini SSTableの数が一定のしきい値を超えると、バックグラウンドで自動的にMinor Compactionがトリガーされます。
コンパクション
コンパクションとはMajor Compactionのことであり、OceanBaseデータベースでは日次コンパクションとも呼ばれます。概念は他のLSM-Treeデータベースと若干異なります。その名の通り、この概念は当初、毎日午前2時頃にクラスタ全体で一括コンパクションを行うことを想定して生まれました。コンパクションは通常、各テナントのRSが書き込み状態やユーザー設定に基づいてスケジューリングを開始します。各テナントの各コンパクションでは、グローバルなスナップショットポイントが選択され、テナント内のすべてのパーティションがこのスナップショットポイントのデータを用いてMajor Compactionを行います。このようにして、各コンパクションではテナントのすべてのデータがこの統一されたスナップショットポイントに基づいて対応するSSTableが生成されます。この仕組みにより、ユーザーは定期的に増分データを統合し、読み取り性能を向上させるだけでなく、自然なデータ検証ポイントも提供されます。グローバルな一貫性ポイントにより、OceanBaseデータベースは内部でマルチレプリカおよび主表インデックス表に対して多次元の物理データ検証を行うことができます。
クエリの読み書き
挿入
OceanBaseデータベースでは、すべてのデータテーブルはインデックス・クラスタテーブルと見なすことができます。主キーを持たないヒープテーブルであっても、内部では隠れた主キーが維持されます。そのため、ユーザーがデータを挿入する際には、新しいユーザーデータをMemTableに書き込む前に、現在のデータテーブル内に既に同一のデータ主キーが存在するかどうかを確認する必要があります。この重複する主キーのクエリ性能を高速化するため、各SSTableに対して、バックグラウンドスレッドが異なるマクロブロックの重複頻度に基づいて、BloomFilterの構築を非同期でスケジュールします。
更新
LSM-Treeデータベースとして、OceanBaseデータベースにおける各更新もまた、新しいデータ行を挿入します。Clogとは異なり、MemTableに書き込まれる更新データには、更新される列の新しい値と対応する主キー列のみが含まれ、更新行には必ずしもテーブルのすべての列のデータが含まれるわけではありません。継続的なバックグラウンドCompaction動作により、これらの増分更新が次第に統合され、ユーザーのクエリが高速化されます。
削除
更新と同様に、削除操作も元のデータに直接作用するのではなく、削除される行の主キーを用いて新しいデータ行を書き込み、行ヘッダのマーカーによって削除動作を示します。大量の削除操作はLSM-Treeデータベースにとって好ましくありません。これにより、あるデータ範囲が完全に削除された後でも、データベースは依然としてその範囲内のすべての削除マーク行をイテレーションし、統合処理を完了した後に初めて削除状態を確認する必要があります。このようなシナリオに対して、OceanBaseデータベースは固有の範囲削除マーカーロジックを提供しており、このような状況を回避することができます。また、ユーザーが明示的にテーブルモードを指定することも可能であり、特殊なダンプコンパクション方式を通じてこれらの削除行を事前に回収し、クエリを高速化することができます。
クエリ
増分更新の戦略により、各行データをクエリする際には、バージョンに基づいて新しいものから古いものへとすべてのMemTableおよびSSTableをトラバースし、各テーブル内の対応する主キーのデータを統合して返す必要があります。データアクセスプロセスでは、必要に応じてキャッシュを利用して高速化されます。また、大規模クエリシナリオに対しては、SQL層がフィルタ条件をストレージ層にプッシュダウンし、保存されたデータの特徴を利用して低レベルでの高速フィルタリングを実現します。さらに、ベクトル化シナリオにおける一括計算と結果の返却もサポートしています。
マルチレベルキャッシュ
パフォーマンス向上のため、OceanBaseデータベースはマルチレベルのキャッシュシステムをサポートしています。データマイクロブロックに対するBlock Cache、各SSTableに対するRow Cache、クエリ結合結果に対するFuse Row Cache、挿入時のNULLチェック用BloomFilter cacheなどがあります。同一テナント内のすべてのキャッシュはメモリを共有しており、MemTableへの書き込み速度が速すぎる場合は、現在の各種キャッシュオブジェクトから柔軟にメモリを割り当てて書き込みに使用することができます。
データ検証
金融業界向けのリレーショナルデータベースとして、OceanBaseデータベースは常にデータ品質とセキュリティを最優先に考えています。永続化されるデータに関わるデータリンク全体において、データ検証保護が追加されています。また、マルチレプリカストレージの固有の利点を活用し、レプリカ間のデータ検証も追加され、全体のデータ整合性をさらに検証します。
論理検証
一般的なデプロイメントモードでは、OceanBaseデータベースの各ユーザーテーブルには複数のレプリカが存在します。テナントの日次コンパクション時には、すべてのレプリカがグローバル統一のスナップショットバージョンに基づいて一貫したベースラインデータを生成します。この特性を利用して、コンパクション完了時にすべてのレプリカのデータのチェックサムを比較し、完全な整合性を保証します。さらに、ユーザーテーブルのインデックスに基づいて、インデックス列のチェックサムも比較し、最終的にユーザーに返されるデータがプログラム固有の問題によって誤っていないことを確認します。
物理検証
データストレージに対して、OceanBaseデータベースはデータストレージの最小I/O粒度であるマイクロブロックから始め、各マイクロブロック/マクロブロック/SSTable/パーティションに対してそれぞれチェックサムを記録しています。データ読み取り時には毎回データ検証が行われます。また、下層ストレージハードウェアの問題を防ぐため、ダンプコンパクションによるデータマクロブロックへの書き込み時にも、書き込み直後に再度データ検証が行われます。最後に、各Serverのバックグラウンドには定期的なデータ巡回スレッドがあり、全体のデータをスキャン検証し、ディスクの静的エラーを早期に発見することができます。