クエリオプティマイザの概要
一言でいうと
Doris クエリオプティマイザ（Nereids）は、Cascades フレームワークに基づく最新のクエリオプティマイザです。RBO（ルールベース最適化）と CBO（コストベース最適化）を組み合わせ、複雑なクエリに対して効率的な実行計画を生成します。
この記事で扱う内容
この記事を読む前に、次の内容を理解しておくことをお勧めします。
- データベースシステムにおけるクエリオプティマイザの基本的な役割
- SQL 実行計画の基本概念
- ルールベース最適化（RBO）とコストベース最適化（CBO）の違い
この記事では、次の順に説明します。
- クエリオプティマイザの開発背景
- Doris クエリオプティマイザの主な利点
- オプティマイザ全体の動作原理
- よく使うチューニング用セッション変数
開発背景
現在のクエリオプティマイザは、次の三種類の課題に直面しています。
| 課題 | 具体的な状況 |
|---|---|
| クエリの複雑化 | ユーザーのクエリはますます複雑になり、利用シーンも多様化している |
| 厳しいリアルタイム要件 | ユーザーはクエリ結果をすぐに得られることを期待している |
| 開発サイクルの高速化 | オプティマイザは次々と生まれる新しい要件にすばやく対応する必要がある |
こうした背景から、Doris は新しいクエリオプティマイザの開発に着手しました。このオプティマイザは最新のアーキテクチャを採用し、Doris の利用シーンにおけるクエリ要求をより効率的に処理するとともに、将来のさらに複雑な要件への拡張に向けた基盤を提供することを目指しています。
Doris クエリオプティマイザの利点
Doris クエリオプティマイザには、従来のオプティマイザと比べて、より高度な最適化、安定性、柔軟性という三つの面で大きな利点があります。
より高度な最適化
- オプティマイザは、RBO と CBO の各最適化処理を「ルール」という形で明確に表します。
- 各ルールは、クエリ計画の形を表すパターンを備えています。これにより、最適化できるクエリ計画を正確に検出できます。
- その結果、多段階にネストしたサブクエリなど、複雑なクエリ文にもより適切に対応できます。
CBO は高度な Cascades フレームワークに基づき、次の三種類の情報を十分に活用します。
- 豊富なデータ統計情報
- データの特性に関する情報
- 入念に調整されたコストモデル
これらの情報を使用することで、複数のテーブルを結合するような複雑なクエリにも対応できます。
より高い安定性
- すべての最適化ルールは、論理実行計画のツリー上で処理されます。
- クエリの構文と意味を解析した後、クエリをツリー構造に変換します。
- 新しいオプティマイザの内部データ構造は、従来のオプティマイザより合理的で統一されています。
サブクエリの処理を例にすると、新しいオプティマイザは新しいデータ構造を利用することで、従来のオプティマイザのように多数のルールがサブクエリを個別に処理する状況を避けています。これにより、最適化ルールに論理的な誤りが生じる可能性を減らします。
より高い柔軟性
オプティマイザには、適切に設計された最新のアーキテクチャが採用されており、最適化ルールや処理段階を容易に拡張できます。変化し続ける要件に対応するため、新しい機能をすばやく追加できます。
オプティマイザの動作原理
全体の処理フロー
オプティマイザの処理フローは、大きく次の四つのステップに分けられます。
| ステップ | 段階 | 説明 |
|---|---|---|
| 1 | 構文解析 | SQL テキストを抽象構文木（AST）に変換する。SQL が有効であれば続行し、そうでなければエラーを報告して終了する |
| 2 | 意味解析 | AST 内のテーブル、カラム、関数が存在するか、またそれらの使用方法が構文規則と意味規則に従っているかを確認する。有効であれば続行し、そうでなければエラーを報告して終了する |
| 3 | クエリ計画の書き換え（RBO） | 定義済みのルールを使ってクエリ計画を書き換える。代表的な手法には、カラムプルーニング、述語プッシュダウン、パーティションプルーニングがある |
| 4 | クエリ計画の最適化（CBO） | 探索空間内の等価な計画を列挙し、各計画の実行コストを評価して、コストが最も低い計画を最終的な実行計画として選択する |
各ステップの目的は次のとおりです。
- 構文解析: SQL テキストを有効な AST に解析できることを確認します。
- 意味解析: AST で参照されるオブジェクトが存在し、正しく使用されていることを確認します。
- RBO による書き換え: 決定的なルールを使って実行速度を最適化します。
- CBO による最適化: コストモデルに基づいて最適な実行計画を選択し、クエリを最も効率的に実行できるようにします。
よく使うセッション変数
nereids_timeout_second
| 項目 | 内容 |
|---|---|
| 用途 | クエリ計画の作成に許容する最大時間を設定する。計画の作成時間がこの値を超えると、処理を中止してエラーメッセージを返す |
| デフォルト値 | 30s |
| 適用場面 | 多数の外部テーブルを使用するクエリや、特に複雑なクエリ文では、クエリを正常に進められるよう、この値を適切に増やす |
設計上の目的: クエリ文の計画を作成する間、システムは SQL に含まれるすべてのテーブルに読み取りロックを取得します。タイムアウトを設ける主な目的は次のとおりです。
- クラスターの安定性を維持する
- 計画作成の長時間化による過剰なリソース消費を防ぐ
- ロックの競合を避ける
チューニングの提案:
- 計画作成時にタイムアウトエラーが発生したら、まず SQL が複雑すぎないか、使用するテーブルが多すぎないかを確認します。
- その利用シーンが妥当だと確認できた場合は、
SET nereids_timeout_second = <seconds>;でこの値を増やします。