クエリ処理

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を試みます。しかし、現在の実装では、データの主キーがメモリ内のデータやダンプ済みデータの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情報を最大限活用して高速化を図ることができます。