クエリ処理

OceanBaseデータベースは現在、プルモードのtable_scan反復プロセスを使用しており、各行がSQL層に反復出力されるまでに実際には以下の段階を経ます：

1. 各SSTableは、query rangeによってスキャンが必要なマクロブロックと対応するマイクロブロックを特定し、各マイクロブロックについてスキャンを開始し、必要な行全体を吐き出します。

2. MemTable/Minor SSTable/Major SSTableの複数のiteratorがそれぞれ行を反復処理します。

3. ラッカー木を用いて、複数のiteratorの現在の行のrowkeyが同じかどうかを判断し、fuseに参加するためにどれだけの行を取得するかを決定します。

4. fuse後の最終結果行は、要件に応じて最終結果を投影し、最終結果行を取得します。

5. 最終結果行を用いてSQLのfilterコールバック関数を呼び出し、検査を行います。条件を満たせば、上位へと戻り続けます。

クエリのダウンプレッシャー

LSM-Treeアーキテクチャのストレージエンジンでは、クエリのプロセスで一般的に以下の問題に直面します：

• 過度かつ頻繁な反復処理および主キーの比較。特にOLAP業務など、多くのシナリオでは大部分のテーブルはほとんど更新されず、データは基本的にベースラインであるMajor SSTableに存在します。MemTableやMinor SSTableには、ごく少量の増分または更新データしか存在しません。理想的には、大部分のパスはmajor SSTableから直接高速にスキャンできるべきです。主キーに交差する可能性がある場合にのみ、複数のソース（すなわちMajor SSTable、MemTable、Minor SSTable）でfuseを試みるべきです。しかし、現在の実装では、データダンプやMemTable内のiteratorと行ごとに主キーが等しいかどうかを判断する必要があります。これにより、一方では効率が著しく低下し、他方では将来のベクトル化による拡張性もほぼ失われてしまいます。

• フィルター演算子の計算が遅すぎること。前述の点と組み合わせると、最終結果の正確性を保証するためには、すべての行はfuseを経て初めてデータが最新状態であることが保証されます。そのため、現在のフィルター演算子の検査は、各行の反復処理の最後に行われています。

• 大量の無駄な投影。マイクロブロックのスキャンで上がってくる行は、最終ユーザーが必要とするすべての列が既に投影されていることを保証する必要があります。複数回の反復処理およびfuseを経て、filter計算で条件に合致した場合は直接返却できますが、フィルター条件に合致しない場合は、filterに必要な列以外の投影列はすべて無駄になります。

以上の理由から、OceanBaseデータベースは、フィルター演算子をストレージ層にダウンプレッシャーすることで上記の問題を解決します。以下の図に示すように：

1. 演算子のダウンプレッシャー。OceanBaseデータベースは、データに交差がない状態を迅速に区別できます。つまり、major SSTableと増分データに交差がないデータ区間を認識できます。この区間のデータは、最新の最終状態を取得するためにmajor SSTableへのアクセスのみが必要なため、このデータに対しては直接フィルター演算子をダウンプレッシャーできます。

2. 演算子のフィルタリング。ダウンプレッシャーされた各filter式は、ストレージ層が理解できる式木に解析・分解され、対応する列情報および対応するフィルター条件式が含まれます。さらに、フィルター条件の複雑さに応じて、ブラックボックスモードとホワイトボックスモードの2種類に細分化することができます。

   1. SQL層に基づくフィルタリング（ブラックボックス）。例えば、a * 2 > 3 のような式計算型のフィルター条件は、ストレージ層では処理できません。SQL層の関数を呼び出して処理する必要があります。この場合、演算子がマイクロブロックdecoder層にダウンプレッシャーされると、それ以上ダウンプレッシャーすることはできません。filterノードの情報に基づいて対応する列を投影し、SQL層のコールバック関数を呼び出して結果を計算する必要があります。

   2. ストレージに基づくフィルタリング（ホワイトボックス）。例えば、a > 1 または b = 'abc' のような単純で一般的なフィルター条件は、ストレージ層が意味を理解し、処理できるfilterノードです。SQL層は、対応する演算子および対応する定数式をさらに解析するのを手伝い、ストレージ層はこの対応するfilterノードを各列に対応するデコードルールにさらにダウンプレッシャーできます。これにより、投影のオーバーヘッドをさらに削減できるとともに、encoding情報を最大限活用して高速化を図ることができます。