データベース オプティマイザー設計のウォークスルー ディスカバリ ツアー

著者：王晨（道教）

I.はじめに

百度百科事典からの引用: データベース技術開発の歴史において、1970 年は大きな転換点の年でした。なぜなら、この年の 6 月に、IBM サンノゼ研究所の主任研究員であるエドガー フランク コッド氏が、ACM のコミュニケーション部門にいたからです。大規模な共有データバンクのためのデータのリレーショナルモデル」。

その後、ACM はこの論文を、データベース システムの新しいモデル、つまりリレーショナル モデルを初めて明確かつ明確に提案したため、1983 年に 1958 年からの 25 年間で最も画期的な論文 25 件の 1 つとして挙げました。リレーショナル モデルの誕生以来、階層モデル (XML/JSON に似た) データベースとネットワーク モデル (グラフに似た) データベースは急速に消滅しました (もちろん今は復活しています)。1981 年のチューリング賞は当然のことながら「」に授与されました。リレーショナル データベースの父」。彼の研究成果により、IBM はリレーショナル データベース管理システムである System R の研究に多額の投資を行い、これに基づいて DB2 や SQL などの製品を発売しました。

1970 年以降、EFCodd は関係理論の改善と発展に取り組み続けました。1972 年に、彼はリレーショナル代数とリレーショナル微積分の概念を提案しました。伝統的な集合演算では、和集合、交差参照整合性、差分、拡張デカルト積と射影 (射影)、選択 (選択)、結合 (結合)、除算 (除算) です。およびその他の基本的な操作。

次に、1974 年に IBM のレイ ボイスとドン チェンバリンは、コッド リレーショナル データベースの 12 基準の数学的定義を単純なキーワード構文で表現し、マイルストーンとして SQL (構造化照会言語) 言語を提案しました。 Oracle は、リレーショナル データベース言語の米国標準として SQL を採用するよう ANSI を推進しました。

同時に、1973 年にカリフォルニア大学バークレー校の Michael Stonebraker と Eugene Wong は、System R の公開情報を使用して独自のリレーショナル データベース システム Ingres を開発しました。ただし、Ingres は、Stonebraker によって発明された QUEL (Query Language) クエリ テクノロジーを使用しています。これは、IBM の SQL とはまったく異なります。場所によっては、QUEL の方が SQL よりも優れています。2 つの言語の違いを感じることができます。

• それか

create student(name = c10, age = i4, sex = c1, state = c2)range of s is studentappend to s (name = "philip", age = 17, sex = "m", state = "FL")retrieve (s.all) where s.state = "FL"replace s (age=s.age+1)retrieve (s.all)delete s where s.name="philip"

• SQL

create table student(name char(10), age int, sex char(1), state char(2));insert into student (name, age, sex, state) values ('philip', 17, 'm', 'FL');select * from student where state = 'FL';update student set age=age+1;select * from student;delete from student where name='philip';

この小さな歴史を理解することは、オプティマイザーとどのような関係があるのでしょうか? システムを設計するのと同じように、まず目標は何でしょうか? それは顧客のどのような問題を解決しますか? 私たちは現在、データベース システム、完璧なオプティマイザ、効率的なエグゼキュータ、安定した安全なストレージなどのリッチ インタラクティブ言語を簡単に考えることができます。そのとき、データリレーショナルモデルとその操作をどのように定義し、シンプルかつ柔軟な対話型言語を確立するかが、その時点のデータベースソフトウェアの開発方向において最も重要なステップとなるでしょう。

2. オプティマイザー設計の探索

モデルと言語が定義されたので、本題に戻りましょう。入力言語要件を効率的に満たすシステムを効率的に設計するにはどうすればよいでしょうか? その場合、データベース オプティマイザーはデータベースの最も重要なコンポーネントの 1 つになります。言語があればパーサーがあり、モデル定義があれば意味解析が必要になります。2 つの重要なモジュールを通過した後、必要なプログラム コードを認識し、リレーショナル代数変換を実行できるリレーショナル代数構造 (Init Logical Plan)、つまりオプティマイザーの入力データ構造を形成しました。SQL は人々が見るものであり、Init Logical Plan はオプティマイザが見るものです。オプティマイザーは、「最適な」コストの実行計画を見つけることです。

「最適」が引用符で囲まれているのはなぜですか? まず第一に、最適なプランを見つけることは通常、NP 困難な問題であると考えられていることを覚えておいてください。オプティマイザーは真に最適な実行プランを生成することはできません。なぜですか?

• 見積り手法による最適なプランのコストの推測

• 計画の検索スペースを制限するためのヒューリスティック

2.1 オプティマイザーモジュール

上の図は従来のオプティマイザのアーキテクチャ図であるはずですが、ここでは、最初の論理プラン (ステップ 4) から「最適な」プラン生成の終了 (ステップ 6) までの探索プロセスに焦点を当てます。

✪ 2.1.1 論理計画と物理計画

論理プランとは、論理的な関係代数式から構成される構造体（ツリーまたはグラフ）であり、関係代数の等価変換により等価な論理プランを生成することができる。EF Codd の論文がデータベース関連の関係代数演算を拡張および追加していることはすでに述べました。Wikipedia の「Relational_algebra」を参照してください。論文とデータベース関連のコースでは、(A ⨝ (B ⨝ C)) = (B ⨝ (A ⨝ C)) など、論理を説明するための例として JOIN の交換法則と結合率が使用されます。初期の頃、IBM Research はデータベースのリレーショナル代数変換に関する多くの論文を作成しました。その 1 つである「リレーショナル データベース システムにおけるマジック セットの実装」を参照してください。IBM はヒューリスティックを説明するためにマジックを使用することを好みます。さらに、Oracle にはサブクエリに関するいくつかの記事があり、別の記事で詳しく説明する「Enhanced Subquery Optimizer in Oracle」という論文も非常に興味深いものです。

物理プランは論理プランによって生成され (必ずしも 1:1 である必要はありません)、特定の実行戦略とアルゴリズムが指定されます。例として JOIN を取り上げます (A ⨝ B) = { (A NL B) または (A HJ B ) または (A MJ B) …}。

✪ 2.1.2 物理コストモデルとコスト見積もり

コスト モデルには、予測される CPU サイクル、I/O コスト、キャッシュ ミス、メモリ消費量、プリフェッチの考慮事項などの物理コストが含まれます。これらはハードウェアに大きく依存します。通常、異なるコンピューティング能力と異なる共有ストレージ メディア (特許の可能性) に基づいて、従来のデータベースの展開とクラウドネイティブ データベースのコスト モデルを動的に再評価する必要があります。演算子の推定結果サイズ (結合)、複雑な演算子の実装コスト (並べ替え/実体化/Windows....) などを含む論理コスト。

✪ 2.1.3 最適化された粒度

最適化の粒度について話すのはなぜですか? これは顧客のシナリオに合わせて行う必要があります。オプティマイザーのアーキテクチャ設計の進化は、顧客のアプリケーション シナリオと密接に関連しています。OLTP の初期ソリューションから DSS、OLAP、ビッグ データ クエリに至るまで、単純なものから複雑なものまで、Sysbench、tpch、tpcds のデータ モデルはコンピューティング データ量の急増に関与しており、最適化手法はインデックス + サラブル検索からリレーショナル代数変換、マジック変換からプランの再利用、検索スペースの最適化、したがって、設計システムは、オプティマイザ自体によってもたらされる最適化を考慮する必要があります。MySQL と同様に、インターネット ユーザーの TP のニーズは、単純なヒューリスティック ルールと左側のディープ ツリー方式の計画列挙アルゴリズムを通じて迅速に解決できます。

✪ 2.1.4 終了条件の最適化

前述したように、最適化は通常 NP 困難問題であるため、オプティマイザーの最適化プロセス中に終了条件を導入する必要があります。最悪の場合は、考えられるすべての計画を計算することです。通常、それは最大最適化時間に達するか、または最適化 の消費値が 0 になった後、現在の最適なプランを選択します。これら 2 つの変数が変更されない場合、検索スペースを削減する (プラン プルーニング)、または並列最適化によって最適なプランを見つけるプロセスをどのように解決するかについては、後で説明します。

✪ 2.1.5 最適化戦略

最適化戦略に関しては、すでに探索の旅を始めることができますが、ここでは最初に関連する戦略を列挙し、その後、産業界と学術界が最適化フレームワークと戦略を 1 つずつ進化させていく様子をゆっくりと見ていきます。

• 経験則

• ヒューリスティック + コストベースの JOIN (ヒューリスティック + コストベースの結合順序検索)

• 階層化検索フレームワーク (階層化検索)

• 統合オプティマイザー フレームワーク (統合検索)

2.2 オプティマイザー アーキテクチャの調査ツアー

データベース オプティマイザーが解決すべき主な問題は、スケーラビリティと、より多くの分野 (データベース、AI など) をサポートできるシステムです。次に、過去に戻って、リレーショナル データベースの開発の歴史と、それぞれのオプティマイザーがどのように機能するかをレビューします。フレームワークが設計および開発されます。

✪ 2.2.1  Ingres オプティマイザー

INGRES ( IN teractive  Graphics RE trieval  System ) は、EF Codd の論文を読んだ Michael Stonebraker が構築することを決めたデータベース システムです。1970 年代に誕生し、System R よりも前に誕生しました。Ingres は、Sybase、 Microsoft 80 年代の主な競合相手は Oracle でしたが、残念ながら 1985 年に Oracle の市場競争と SQL 標準により徐々に市場から撤退してしまいました。

前述したように、Ingres と System R は両方ともリレーショナル理論に触発されたデータベースの初期のプロトタイプであるため、最初に独自のクエリ言語 QUEL を設計する必要があります。Ingre のオプティマイザー フレームワークは、次の図のように簡単に表すことができます。

Ingres のオプティマイザは、ヒューリスティックな貪欲分解に基づくテクノロジを提案しており、その設計目標は以下を満たす必要があります。

• デカルト積生成なし: 結果セットは、デカルト積によって直接生成されるのではなく、小さなセットの断片を組み立てることによって生成されます。

• 幾何学的拡大なし: スキャンされるタプルは可能な限り少なく保たれ、ほとんどのクエリ SQL はテーブルのカーディナリティよりもはるかに小さくなります。

以下は、次のことを前提として、単一値クエリへの分解とクエリからの値の置換の 2 つのステップを説明する簡単な例です。

表定义：Suppher (Sf, Sname, City)Parts (P#, Pname, Size)Supply (S#, PP, Quantity)QUEL查询(Q)：RANGE OF (S,P,Y) IS (Supplier, Parts, Supply)RETRIEVE (S.Sname) WHERE (S.City=‘New York’)AND (P.Pname=‘Bolt’)AND (P.Size=20)AND (Y.S#=S.S#)AND (Y.P#=P.P#)AND (Y.Quantity2200)

Qの部品が分解されてQ1とQ→Q'に置き換わっていることが分かり、論理変換も右図のように表すことができます。

フォローアップQ全体の解体プロセスは次のとおりです。

Q1 から Q3 の変数置換の場合、変数は 1 つだけであるため、任意に行うことができます。また、Q4 と Q5 の場合は、Q5 のような 2 つの変数です。 RETRIEVE (S.Sname) WHERE (YS#=SS#) (S# 列を想定)コンテンツが 101、107、203 の場合、置換プロセスは次のようになります。

Ingres を要約するには、ヒューリスティック ルールが使用されます。

• 制限的な SELECTION をできるだけ早く実行する

• JOIN の前にすべての SELELCTION を実行する

• 述語/制限/射影演算子がプッシュダウンされる

• JOIN の順序はカーディナリティに基づきます

Ingres の欠点も明らかです。ここでは 1986 年以降の PostgreSQL (Post-Ingres) について簡単に説明します。Starburst と同様に、オプティマイザを改善するためにルール システムの探索も続けられました。

✪ 2.2.2 システム R オプティマイザー + スターバースト プロジェクト

システムR

System R は、1974 年に IBM サンノゼ研究所が行ったデータベース システムベースの研究プロジェクトです。これは、現在のデータベース クエリ言語の標準としても知られる SQL 言語の最初のバージョンを提案しました。System R アーキテクチャは、データベースをユーザー プログラム、リレーショナル データ システム (RDS)、リレーショナル ストレージ システム (RSS)、および 2 つのインターフェイス (リレーショナル データ インターフェイス (RDI) とリレーショナル ストレージ システム (RSI)) の 3 つの部分に分割します。

System R オプティマイザーは、ボトムアップ動的プログラミング検索戦略を初めて提案し、その後の多くのシステムに影響を与えました。もう 1 つの革新的な点は、コストベースの最適化手法を提案し、検索可能な条件に従って選択を計算する方法と、アクセス方法 (アクセス パス) に影響を与える興味深い順序属性を追加することです。System R オプティマイザーは、次の 2 つの前提に基づいています。

• 各列の値は、ある最小値からある最大値まで均等に分布しています。

• 列値の分布は互いに独立しています

System R オプティマイザーがコスト パスを計算するときは、リレーショナル テーブル内のタプルの数 (R)、リレーショナル テーブルが占有するページ数 (D)、および含まれるタプルの平均数の点を考慮する必要があります。各ページ (T= R/D)、インデックス内の異なるフィールドの数 (I)、および CPU コスト係数 (H、1/H はタプル比較の数がディスク ページ アクセスのコストと等しいかどうか) )、オプションのインデックスに従って、どのスキャン方法を使用するかを決定します。

• 方法 1: クラスター化インデックスと比較演算子は「=」、予想コスト = R/(T×I) ページ アクセス。

• 方法 2: クラスター化インデックスと比較演算子が '=' ではありません。タプルの半分が条件を満たすと仮定すると、予想コスト=R/(2×T)となります。

• 方法 3: 非クラスター化インデックスと比較演算子は「=」です。各タプルにはページ アクセスが必要です。予想される COST=R/I。

• 方法 4: 非クラスター化インデックスで比較演算子が「=」ではない場合、予想コスト = R/2。

• 方法 5: クラスター化インデックスとインデックスが述語に一致しません。予想コスト = (R/T)+H×R×N (N はクエリ内の述語の数)。

• 方法 6: 非クラスター化インデックスとインデックスが述語に一致しません (予想コスト = R+H×R×N)。

• 方法 7: テーブル スキャン、独立セグメント、予想コスト = (R/T)+H×R×N。

• 方法 8: テーブルのスキャンと他のテーブルとの共有セグメント、予想コスト>=(R/T)+H×R×N。

次に、次のルールに従って上記の方法のいずれかを選択します。

• 方法 1 が利用可能な場合は、方法 1 を選択します。

• 2、3、5、7 の方法がある場合は、コストが最も低い方法を選択してください。

• 上記 2 つの項目のいずれも満たされない場合、4 が方法 4 の選択を満たしている場合は、方法 6 と 8 を一度に検討し、可能であれば直接選択します。

System R オプティマイザーの検索プロセス全体は、1 つのテーブル、2 つのテーブルに分割されます。次の図は例です。

SELECT NAME,TITLE,SAL,DNAMEFROM EMP,DEPT,JOBWHERE TITLE=‘CLERK’AND LOC=‘DENVER’AND EMP.DNO=DEPT.DNOAND EMP.JOB=JOB.JOB

まず、アクセス パスに関する 1 つのテーブルの最適化プロセスを確認します。これは、3 つのテーブルのアクセス方法 (インデックス/セグメント スキャン) とその統計情報を示します。たとえば、C (EMP.DNO) は DNO を介したスキャンのコストです。 Ni は結果カードを表し、単一テーブルの検索ツリーを形成します。

次に、2 つのテーブルの検索ツリーを展開すると、ノードの最初の層が上から下に (EMP、DEPT) などの 2 つのテーブルの接続シーケンスを表し、選択されたアクセス方法と統計が記録されていることがわかります。アクセス順序に従って、左端のIndex EMP.DNOなどの情報はインデックススキャンでEMPテーブルにアクセスすることを意味し、次のエッジはIndex DEPT.DNOで、インデックススキャンでDEPTテーブルにアクセスすることを意味します。その後、最下位に達すると、特定の価格、カードと興味深い注文の組み合わせなどが得られます。

システム R では、最後に相関サブクエリと非相関サブクエリの推定方法についても最初に言及しましたが、これについては以降の論文で説明します。System R の古典的な設計は、実際にその後の多くのデータベースの設計に影響を与えました。

スターバーストプロジェクト

Starburst プロジェクトは主にクエリ リライト モジュールを対象としており、論理関係の代数変換をより適切に実現するために一連のスケーラブルなルール エンジンを実装することを革新的に提案しました。当時の設計目標は次のとおりでした。

• クエリをできるだけ宣言的に作成し、入力クエリ ステートメントでターゲットを表現するようにし、結果を生成するためにデータベース エンジンがどのように実行されるかを無視します。

• 自然なヒューリスティックを実行し、条件付きプッシュダウンなどのヒューリスティック手法によるクエリの書き換えにより、パフォーマンスを大幅に向上させることができます。

要約すると、System R と Starburst を完全に組み合わせたからこそ、DB2 が正式に誕生し、リレーショナル データベースの商用化が実現したのです。関連する最適化の詳細については、記事「データベースを掘る先祖の墓シリーズ - DB2 Database Optimizer の概要」で詳しく紹介されているため、この記事では繰り返しません。

✪ 2.2.3  EXODUS オプティマイザージェネレーター

EXODUS は拡張可能なデータベースです。目標は、データベース実装者が効率的なアプリケーション固有のデータベース システムを迅速に実装できるように支援することです。このデータベース システムはデータ モデルから独立でき、一般的なストレージ マネージャーやタイプ マネージャーなどのコア コンポーネントを提供し、一連の共通アーキテクチャを提供します。ツールとコンポーネントについては、「EXODUS Extensible DBMS のアーキテクチャ」を参照してください。

この記事の主な焦点は依然としてオプティマイザーにありますが、初期の理論はオプティマイザーを完成させるだけでなく、さまざまなデータ モデルを対象にすることができるため、初期の論文ではジェネレーターという言葉が追加されることがわかりますが、これは実際にはオプティマイザーです。抽象的なアーキテクチャと生成システム、そして多くの概念は当時の AI システムの言語、関係、システムに由来しており、現在のクラウド ビッグ データ プラットフォームやコンピューティング プラットフォームに少し似ています。

以下はEXODUS Optimizer Generatorのアーキテクチャ図で、入力はクエリツリー変換に関わる演算子一式、メソッド実装と関係代数変換ルール一式、演算子とメソッド実装間の記述情報(モデル記述ファイル)です。

オプティマイザー ジェネレーターへの入力

データベースが構築されると、ジェネレーターは、モデル記述ファイルに従って指定されたオプティマイザーを生成する責任を負います。これは、実行時にユーザー インターフェイスに従って対応するクエリ ツリーに変換され、オプティマイザーを通じて対応する実行プランに変換されます。 、実行可能プログラムとしてインタープリターに解析されます。すべての初期クエリ ツリーと、オプティマイザで変換された等価リレーショナル代数ツリーは MESH のハッシュ構造に配置され、変換ルールは OPEN の優先キューに配置されます。簡単なアルゴリズムは次のように説明されます。

モデル記述ファイルは 2 つの部分に分かれており、1 つの部分は説明部分です。次に例を示します。

1 つの部分は、次のような変換ルールと実装ルールを含むルール部分です。

一部のルールは、次のような対応する条件に従って双方向にすることができます。

EXODUS Optimizer Generator のルール体系では、繰り返しのルールが存在することができますが、例えば、実運用時に特定のルールを常に結合できる場合には、結合したルールを追加することができます。

モデル記述ファイルの他に、C言語ベースの演算子ごとのプロパティ関数一式、関数ごとのプロパティ関数とコスト関数、パラメータの比較やメモリ確保などができるサポート関数も必要です。

生成されたオプティマイザーの操作

探索プロセス全体を通じて、ルール変換を満たす等価クエリ ツリーと等価実行プランが MESH 構造に格納されるため、不必要な繰り返し構造を削減するメカニズムが必要です。 2 つの変換 (フィルター プッシュダウンと結合列挙) の使用を表します。この変換では、構造が可能な限り再利用され、新しく生成されたノードが以前のノードで下から上に置き換えられます。

2 つのノードが同じ演算子、演算子パラメータ、同じ入力を持つ場合、新しいノードが生成されて MESH にコピーされるときに、共通の式 (共通の部分式) をハッシュ構造を通じてできるだけ早く見つけて、重複と関連付けを減らすことができます。

以前に繰り返されたノードを見つけることが実際に不可能な場合は、実装ルールと照合して最適なプランを見つけ、さらにノードのサブクエリを変換ルールと照合します。適合したルールが見つかったら、それを OPEN に入れます。構造を変更し、参照やパラメータ入力を含む古いサブクエリを含むすべての親ノードを実装ルールと照合し、サブクエリの変換によるコスト改善をパスします。このプロセスは、図のフィトラーのプッシュダウンなど、再分析されます。 3 (オリジナル - >I)、新しいコストが再計算されます。

最後に、親ノードは、新しいプランが生成される可能性があるため、変換ルールを再度照合します。このプロセスは再照合と呼ばれます。下の図 4 に示すように、結合結合則 (I->II) を照合した後、新しいプランが生成されます。それは再戦のプロセスでもあります。

検索戦略と学習 

複雑なクエリの場合、OPEN では多数の変換が行われる可能性があるため、クエリが妥当な時間範囲内で最適化できる場合、理想的な状況は、最終的に最適化された実行プランの変換のみを含むことですが、これは明らかに問題です。可能ですので、確実にコストを大幅に削減できる変換を選択してください。

Promiseの概念を導入し、変換ごとに期待コスト係数、つまり変換前後の係数を加算し、コスト削減が必要かどうかを事前に確認した上で変換ルールの適用を決定します。選択プッシュダウンのような設定の場合は f < 1、結合交換則のような中立的な遷移の場合は f = 1 です。ただし、EXOUS では具体的なモデルがわからないためこの係数を設定することができず、実行フィードバックに基づいた計算方法を提供しており、計算式にはいくつかの種類があります。

また、後続の演算子のために演算子の係数を調整するか、すでに見積もられたサブクエリに基づいてコストを削減するかを検討します。EXOUS の戦略は、現在の計画が最適な計画であるかどうかを判断することはまだ不可能であるため、検索を続けて、以前の最適な計画のコスト * 山登り係数を計算時に比較し、コストが低ければ、変換ルールは次のようになります。中古です。

ヒルクライミングファクターは通常 1.05 ～ 1.5 の間に設定され、EXOUS ではリレーショナル モデルのヒルクライミングファクターが 1 に近いことも示しています。最後に、再分析係数ですが、前述の再分析プロセスでは、新しいサブクエリが以前に最適化されたサブクエリのコスト * 再分析係数よりも大幅に高い場合、再分析に時間を浪費することはありません。

もちろん、ここまでは言っておきますが、フィードバックと学習も行う必要があるため、これらのパラメータもデータ モデルに従って与えられます。

結論として、EXOUS Optimizer Generator の最大の貢献は、データ モデルと検索戦略を切り離し、論理変換ルールと論理演算子を物理変換ルールと物理演算子から分離する、提案されたトップダウン オプティマイザ ジェネレータ フレームワークです。拡張するのは簡単ではありませんが、その後の Cascades オプティマイザーの優れた基盤を築きました。

✪ 2.2.4 火山オプティマイザージェネレーター

Volcano は実際には、オプティマイザーとアクチュエーター設計フレームワークを含む研究プロジェクトであり、研究の背景には次の 2 つの目標があります。

1) スケーラビリティのフレームワーク設計を把握し、増大するデータ規模とさまざまなアプリケーションシナリオに適応するデータベースシステムを解決すること。

2) 最適化と並列化という 2 つの主要なテクノロジを活用してデータベースのパフォーマンス問題を解決し、これまでのファイル システムのツールとテクノロジを置き換えることです。次の 2 つの記事を参照してください。

[1] 《Volcano - 拡張可能な並列クエリ評価システム》

[2] 《Volcano Optimizer Generator : 拡張性と効率的な検索》

Volcano は EXODUS、System R、Ingres を利用しており、主に EXODUS の問題点を強化および比較しています。Sysmtem R は、Volcano が優れた拡張に使用できることにも気づきましたが、並列スケーラビリティの問題をあまりうまく解決できませんでした。つまり、スケーラビリティと並列実行は互いに独立しています (直交性)。

まず全体的な設計フレームワークを見ると、Volcano のシステム設計のアイデアがデータベースの使用のみに基づいているわけではないことがわかります。

リレーショナル データに基づくシステム クエリ プロセスはリレーショナル代数に基づいているため、スケーラビリティとオブジェクト指向も、リレーショナル代数演算子とそれに相当する変更を定義するためのルールや、実装に適したアルゴリズムなどのリレーショナル代数関連テクノロジに基づいています。 。

Volcano オプティマイザは、論理関係代数と物理関係代数という 2 つのタイプの関係代数を定義します。オプティマイザは、クエリを表す論理関係代数 (論理代数) を、特定のアルゴリズム実装を含む同等の物理関係代数 (物理代数) に変換する役割を果たします。プラン。この目標を達成するには、完全な論理関係代数変換 (変換) とコストベース (コストベース) の論理関係代数から物理アルゴリズムへのマッピング方法が必要です。ルールも、データベース オプティマイザーで広く使用されているシンプルなモジュール式コンポーネントです。

Volcano のオプティマイザーのルールは互いに独立しており、検索エンジンで結合されてクエリを最適化します。Volcano は、検索エンジンによって選択できる、複数の同等の変更を含む最適化計画のマッピングも提案します。Volcano 氏はまた、ルール システムを解析するかコンパイルするかについても説明しました。解析は柔軟ですが、最適化は通常 CPU に依存するため、EXODUS オプティマイザーと同じコンパイル方法が選択されるため、実行プロセスは非常に高速になります。オプティマイザにとって新しいルールはそれほど高速ではありません。

要約すると、Volcano オプティマイザーがデータベース オプティマイザーの設計と実装に必要なコンポーネントは次のとおりです。

1) 論理演算子のセット。

２）条件判断を伴う関係代数変換のルールセット。

3) 物理的なアルゴリズムとエンフォーサーのセット。

4) 条件付き判断を伴う論理から物理への実装のための一連のルール。

５）抽象データ型のコスト（コスト）。

6) 抽象データ型の物理特性ベクトル。

7) 各アルゴリズムまたはエンフォーサーが物理属性ベクトルの要件に適用できるかどうかを判断するために使用される関数 (適用関数)。

8) 各アルゴリズムまたはエンフォーサーがコストを見積もるために使用するコスト関数。

9) 各オペレーター、アルゴリズム、またはエンフォーサーの属性関数。複雑に思えますが、Volcano Optimizer は System R の Optimizer フレームワーク以来最も画期的なフレームワークであり、過去 20 年間で唯一の画期的なイノベーションになる可能性があります。また、後続のオプティマイザーの設計者が最初から始めることも防止します。

基本コンポーネントを配置した後、これらのコンポーネントをどのようにして迅速に連携させることができるでしょうか? それは、考えられるさまざまなプランを列挙して最適なプランを選択するために使用される検索エンジンでなければなりません。Volcano オプティマイザーの目標は、上の図のような汎用オプティマイザーを設計することです。

EXODUS とは異なり、可能性を完全に列挙するのではなく、よりターゲットを絞った動的プログラミング アルゴリズムを使用します。System R と Starburst も動的プログラミングを使用しますが、選択-プロジェクト-結合クエリ シナリオでのみ使用されます。Volcano は有向動的プログラミング アルゴリズム (有向動的プログラミング) を採用しており、最適な計画を見つけるために特定の目標に向けたトップダウンの制御戦略をサポートしています。この利点は、より一般的なリレーショナル代数変換をサポートできることです。また、効果的な実行プランの候補をより効率的に見つけることができます。検索エンジンの一般的なロジックは次のとおりです。

リレーショナル代数変換 (Transformation) を Rewrite 部分に入れる Starburst オプティマイザーと比較すると、Volcano オプティマイザーはこの変換を単なる追加オプションとみなし、フレームワークに入れます。Volcano オプティマイザーでは、分岐限定最適化枝刈りのコスト制限も適用されますが、このコスト制限は部分式に戻されるため、徹底的に検索しても比較的適切なプランが見つかります。

ここでは、Volcano オプティマイザーをサポートするエグゼキュータの革新についても少し触れます。

1) Volcano executor によって提案されるクエリ実行の演算子には、open、next、close のパラダイムが含まれます。

2) プラン演算子を選択した 2 つの重要な演算子は、パラメーター変更の問題によって引き起こされる動的なプラン選択を解決するために提案され、交換演算子はデータベース クエリ実行中の同時実行性の問題を解決するために使用されます。

最後に、Volcano オプティマイザーが EXODUS オプティマイザーをどのように改善するかについて説明します。

1) Volcano の論理表現と物理表現は分離されています。

2) 物理的属性は EXODU ほどカジュアルには扱われません。

3) Volcano のアルゴリズムはトップダウンであり、部分式は必要な場合にのみ最適化する必要がありますが、EXODUS は変換とコスト推定がすべてです。

4) コストは抽象型を定義します。抽象型は単純な数値、消費時間、CPU 時間と I/O 時間を含む構造、さらには関数の場合もあります。

5) 検索戦略は非常に柔軟で、物理的プロパティ、分枝枝刈り、ヒューリサイト ガイダンスなどを含みます。

✪ 2.2.5 カスケードフレームワーク

ここで、最も重要な Cascades オプティマイザーに移ります。このオプティマイザーは、EXODUS および Volcano Optimizer ジェネレーターに基づいた Graefe の改良版です。今回はタイトルが変更されています。オプティマイザー ジェネレーターではなく、クエリ最適化のための明確なフレームワークです。 Framework は Cascades のクラスベースの実装 (C++ 言語機能を使用) に基づいており、分析関数呼び出しには基づいていないと主に考えられています。多くの商用オプティマイザはカスケードの考え方に基づいているため、この章はかなり長くなります。

EXODUS の主な貢献は、ルール、ロジック、および物理関係代数のためのオプティマイザーの動的コード生成のセットに基づく新しいジェネレーター アーキテクチャの設計にあり、オプティマイザーを DBI によって定義されたモジュール式コンポーネントとインターフェイスに分割します。一方、Volcano は主に、 Volcano は、動的計画法と記憶化に基づいて、より効率的な検索エンジン (検索エンジン) を改良しており、論理最適化と物理最適化の段階を明確に区別しています。関係代数は、考えられるすべての論理演算子を生成し、次に物理演算子を最適化します。計算および検索スペース。

まず第一に、Cascades はフレームワークから大幅な改良を加えました。すべてオブジェクト (オブジェクト) + タスク (タスク) を使用して、以前の関数呼び出し方法を置き換え、グラフを使用してトポロジーとそれらの間の依存関係を示すことができるようになりました。 LIFOスタック構造管理により、ヒューリスティックガイダンス（ヒューリスティックガイダンス）に従って並べ替えや調整が容易になり、並列最適化も可能です。

以下の図は、タスクベースオプティマイザの検索アルゴリズムの枠組みと含まれるタスクの種類を示しており、実線の矢印はどの種類のタスクが他のタスクを呼び出すかを示し、点線の矢印は入力に関連する呼び出しを示します。optimize() を呼び出して最初のクエリ関係式ツリーを MEMO にコピーした後、最適化プロセスが継続的にトリガーされ、より多くの部分式ツリーの最適化に分解されます。最適化プロセス全体には、動的プログラミングと記憶のアルゴリズムが採用されています。

• グループ: 同じ論理出力属性を持つ expr のコレクションを含む論理等価クラス。

• 式: 演算子を含むリレーショナル代数式。

• 最適化目標: コスト制限、必要な物理的特性と除外される物理的特性 (出力物理特性) など、Volcano Optimizer ジェネレーターの概念が参照されます。

• グループの最適化: 最適化の目標に従って、グループを最適化します。つまり、グループ内の各式を最適化して、最適なプランを見つけます。

• 式の最適化: 式を最適化し、ルールを使用して最適化ルール (ルールの適用) を式に適用し、すべてのルールが適用された後、グループ内でコストが最小の式を見つけます。

• グループの探索と式の探索: 式の最適化に使用され、新しいグループと式が生成される可能性があり、探索プロセスは論理演算子に対して同等の変更を実行します。Volcano では論理変換と物理変換の 2 段階が採用されているため、このステップは Volcano と比べてまったく新しい概念です。

• ルールの適用: 特定の最適化ルールを適用し、論理式から同等の論理式に変換するか、論理式から物理式に変換します。

• 入力の最適化: Expression のコストの推定は、子ノードの統計とコストを再帰的に計算し、次に現在のノードを計算し、新しいコスト制限を可能な限り枝刈りして維持する必要があるボトムアップ プロセスです。

• メモ: サーチ スペース管理。これには、最初のクエリ関係式ツリーとすべての同等の論理式および物理式、および重複排除を担当する構造が含まれます。

このプロセスは論文には記載されていないため、他の論文の説明を借用します。

​​​​​​​

optimize(qry, guidance) {
   
      for i=1 to pass_count do {
   
           push "opt_group" task for the root of the query        while task_list is not empty            pop task            perform task   }   return plan}

次に、Cascades は統合探索方式 (Explore) を採用しており、論理式と物理式を区別するのではなく、Volcano が最初の段階ですべてのロジックを網羅的に生成することを回避するオンデマンド探索方式を採用しています。Explore のグループ/式はタスクで必要なパターンと一致する必要があり、必要に応じて変換が適用され、すべての式または同等の変換が生成されます。さらに、Cascades はヒューリスティック ガイダンスと重複防止適用ルールを備えたパターン メモリ構造を備えており、Cascades は Volcano よりも確実に効率的であり、最悪の場合のみ Volcano の検索戦略と同じになります。

3 番目に、データ クラス インターフェイスとユーザー インターフェイスを明確に定義して、スケーラビリティと対話インターフェイスを向上させます。

演算子と引数

クラス OP-ARG は、論理/物理に厳密に分けられておらず、特定の操作を記述するだけで、論理的メソッドと物理メソッド、一部の演算子など、各式に対応する特性を記述するために使用される情報媒体のように感じられます。 starburst に似た「非端末」は論理演算子でも物理演算子でもありませんが、Sargable 述語演算子は論理演算子でも物理演算子でもあります。

上記の 2 つの関数に加えて、カスケードの最も重要なステップ (約束による手の順序付け) を指定するために使用される opt-cutoff メソッドも含める必要があります。また、繰り返し式の検索、論理属性 (スキーマ/選択性/出力サイズ) の検索と更新など、論理演算子に特化したメソッドもいくつかあります。

最後に、パターンメモリに従って露光タスクのステップが決定されます。オペレーターの出力属性の表示、オペレーターのコスト関数 (ローカルコスト自体のコスト、入力、物理的なコストを含むサブプラン全体のコスト) の計算と確認など、物理オペレーターに適用できるメソッドもいくつかあります。属性とその独自のコストを決定し、コスト制限を超えないようにして、新しいコスト制限を設定します)。最後に、オペレーターのコスト制限 (必須および除外) の物理的プロパティをマッピングする input-reqd-prop と呼ばれる関数があります。

論理的および物理的特性/コスト

クラス COST、クラス OP-ARG などの他のクラスの入力と出力の場合、唯一の方法は比較することです。

クラス SYNTH-LOG-PROP、論理演算子プロパティ。式を迅速に取得して重複排除するためのハッシュ構造が含まれます。

クラス SYNTH-PHYS-PROP、物理演算子プロパティ、メソッドなし。

クラス REQD-PHYS-PROP、必須の物理演算子属性。唯一の方法は、物理属性インスタンスに必須の物理演算子属性が含まれているかどうかを判断することです。たとえば、結果は A、B、C、および必須のソート属性によってソートされます。が A 、B のみの場合、比較結果は MORE を返し、デフォルトの戻り結果は UNDEFINED です。

表現木

クラス EXPR はツリー構造であり、演算子ノードとその入力ノードが含まれます。入力ノードは演算子のパラメータに対応する必要があります。この方法には、演算子または演算子の入力を抽出するステップと、再帰的マッチング方法が含まれる。

Multi-EXPR は、メモリ使用量を削減し、メモ化テクノロジを最大限に活用するために、Expression をグループ形式で記述します。これは、次の図に従って理解できます。

検索ガイド

ヒューリスティック制御ルールとステップの適用に使用されるクラス GUIDANCE は、最適な計画の生成時間を大幅に短縮できますが、ガイダンスが間違っている場合は、大きな逸脱も引き起こします。たとえば、交換を伴う一部のルール (JOIN 交換法) は、ONCE-GUIDANCE/ONCE-RULE と呼ばれ、1 回のみ適用されます。研究者の中には、これらのルール専用にモジュールを分割している人もいます。

パターンメモリー

パターン メモリは各グループに 1 つあり、グループ内で同じパターンを 2 回繰り返し探索することを避けるために使用されます。最も複雑なのは、エクスプレッション内で変換されたパターンなど、2 つのグループのパターン メモリをマージすることです。

ルール

Cascades で最も重要な class RULE は実行時に動的に作成でき、前述の EXODUS と Volcano は論理と物理を区別するルールであり、Cascades は is-logical と is -physical という判定方法によってマージされます。RULE は、名前、事前順序付けパターン (パターンの前)、および同等の結果 (置換) を提供します。パターンと置換は両方とも式のツリー構造であり、任意の複雑な形式をサポートしますが、EXODUS と Volcano は 1 つの物理演算子のみをサポートしますが、依然として制限があります。 top の置換演算子は論理演算子である必要があります。

RULE には、promise とcondition という 2 つの重要な関数が含まれています。

2 つの Promise 関数は、それぞれ最適化タスクと探索タスクの重み情報を提供します。RULE が非常に重要である可能性があることを伝えます。網羅的な検索の場合、すべての Promise 関数は 1.0 を返し、<=0 はオプティマイザによるさらなる最適化を妨げる可能性があります。デフォルト 実装ルールのpromise = 2、変換ルールのpromise = 1。

条件関数は、新しい式を探索して生成する前に、RULE が適用可能かどうかを判断するために使用されます。また、単純なルールか関数ルールかを判断するrule-type、検索メモリ内の先頭の演算子と一致するかどうかを判断するtop-match関数、opt-casesなどの小さな関数もいくつかあります。属性の最適化の頻度は、通常、最適化ごとに 1 回カウントされます。もちろん、特殊なケースもあります。たとえば、条件 (RA=SA および RB=SB) によって生成されたマージ ソートの場合、実際には、 A と B に従ってソートするか、B と A に従ってソートします。これら 2 つのソート順序は最適化としてカウントされます。

最適化および探索タスク用の GUIDANCE の opt-guidance、expl-guidance、input-opt-guidance、input-expl-guidance を生成する関数がまだいくつか残っています。

ここでは、RULES の重要なクラス、エンフォーサ ルール、出力の物理属性を保証するために物理属性を挿入するために使用される演算子について個別に紹介します。たとえば、merge-sort-join 演算子の入力は並べ替える必要があるため、並べ替えエンフォーサ ルールによって入力に並べ替え演算子が挿入される可能性があるため、並べ替え演算子の input-reqd-prop 関数で除外を設定できる必要があります。これを回避するためのsortプロパティ 出力ソート属性がソート要件をすでに満たしている入力は、ソート演算子に挿入されます。

クラス FUNCTION-RULE では、場合によっては、同じ変換を行うように多数のルール セットを設計および制御する代わりに、1 つの関数のみを使用して式の同等の変換を実行できるため、Cascades はこのタイプの RULE をサポートします。式全体 式ツリーがパターンを満たす場合、そのインターレーター関数を繰り返し呼び出して、すべての同等の変換を作成できます。たとえば、複雑な結合述語を左右の入力に分解すると、入力は決定的になります。

極端な例では、Cascades の設計フレームワークは破壊されますが、少数の関数ですべての式の変換を完了できます。

要約すると、Cascades は大幅な改善を行いました。

• ルール（変換ルール/実装ルール）はオブジェクトとして実装されます。

• Group オブジェクトを使用して、論理同値クラス、つまり論理式を記述します。

• スキーマ/クエリ機能のルールは拡張できます。

• Enforcer の追加はルールによっても記述されます。

• 変換ルールはパターンに基づいて照合され、適用可能かどうかが判断されます。

• 述語は演算子の引数ではなく独立した演算子になるため、述語の配置などの同等の変換を実行できます。

• 変換ルールを適用する際には、下位層グループの探索が必要に応じて実行されます。これは、同等の変更を行うプロセスに相当し、下位層演算子の論理/物理変換は必要に応じて段階的に実行されます。 Volcano の論文で使用されている、最初に変換を行ってから実装を検討するという 2 段階モデル​​ではありません。

• ガイダンスの概念が検索プロセスに導入され、ルールの適用戦略をガイドできます。

• ルールには、その優先順位を示す約束を持たせることができます。

• 検索プロセスを複数の段階に分割し、タスクの概念を抽象化します。タスクは最適化プロセスにおけるスケジューリングの主体です。異なるタスク間には依存関係があり、DAG (有向非巡回グラフ) を形成するため、並列検索が可能です。

もちろん、より成功しているのは、その設計アイデアとフレームワークが商用製品の Microsoft SQL Server と Tandem の NonStop SQL によって証明されていることです。

✪ 2.2.6 コロンビアオプティマイザー

以前紹介した Cascades Optimizer Framework はより詳細であり、Columbia Optimizer はそれを改良したものであるため、ここでは違いと関連する構造について簡単に紹介します。次の図は、オプティマイザーのアーキテクチャを示しています。

オプティマイザー入力の改善

上の図から、オプティマイザーの入力クエリ、カタログ、およびコスト モデルはすべてテキスト ファイルに基づいていることがわかります。これは、ハードコーディングされたメソッドを使用する代わりに、Columbia オプティマイザーが主張する重要な改善でもあります。

クエリ LISP 言語の説明。クエリの論理式をテキストで直接記述します。

Columbia の入力カタログ情報のテキスト式:

Columbia の入力コスト テキスト式:

ここでは、Columbia Optimizer のさまざまな最適化の出力物理表現も観察します。

検索エンジンの改善

上の図は Search, Search Space Struture の構造を示しています. SSP (Cascades の呼び出しメモ) も動的プログラミングとメモ化の技術を採用しています. SSP には論理的等価物をグループ化するための GROUP 配列が含まれています. SSP にはルート GROUP が含まれています, それぞれGROUP には ID と式 multi-EXPR のグループが含まれており、GROUP の各グループはルートまたは他の multi-EXPR 入力のいずれかになります。

SSP には、新しい同等のマルチ EXPR または新しい GROUP とそのマルチ EXPR をコピーする役割を担う CopyIn 関数と、最適化の完了後に最適なプランを出力する役割を担う CopyOut という 2 つの関数が含まれています。SSP の重複排除では引き続き静的ハッシュ方式が使用されますが、Columbia Optimizer は検索パフォーマンスを向上させるために lookup2 アルゴリズムを使用します。

グループの改善

グループの下限

トップダウンの最適化では、特定のグループに固有の場合、対応する検索コンテキスト (カスケードでの最適化目標) が存在します。これには、[必要な物理的特性、コスト制限 (コスト上限)] の 2 つの部分が含まれます。下方向に検索すると、現在のグループによって出力された物理属性が必要になり、サブプラン全体のコストがコストの上限よりも小さくなる必要があります。

サブプランのコストは、現在のグループの物理 m-expr コスト + 各入力グループの最適な物理 m-expr のコストです。入力グループを最適化する前に、入力グループのコストが高すぎると判断して枝刈りを実現することはできますか? Columbia は、各グループのコスト下限を計算し、グループによって列挙された物理 m-expr に対応するサブプランがcost(m-expr) > 下限を持つことを保証します。

下限はグループの論理プロパティに基づいて計算され、特定の演算子の実装とは関係なく、グループの作成時に計算されます。次の図は疑似コードです。より詳細な理解のために論文を読むことができます。

論理的および物理的な複数式の分離

論理演算子式と物理演算子式のリストを構造的に分割するのは主にバインディングによるコストを改善するためであり、物理式では物理属性と計算コストのみを計算する必要があり、論理式はルールが使用できるかどうかに依存します。使用後は最適化されるため、実行効率が大幅に向上しました。

勝者のためのより良い構造

この最適化は依然としてメモ化テクノロジの拡張に基づいています。GROUP はさまざまな検索コンテキストに基づいて繰り返し最適化を行うため、各コンテキストは最適なプランを見つける必要があり、これらのプランは後で再利用できるように GROUP の勝者リストに保存されます。

Columbia は主に Winner の構造を単純化します。これには、[現在のグループ内の最良の (物理的) m-expr + 最良の計画コスト + 必要な物理的プロパティ] の配列のみが含まれ、次の勝者へのポインターは含まれません。現在の検索コンテキストに基づいて検索プロセス中に取得された最適解 (一時的) も勝者構造に保存されます。

さらに、最終的に要件を満たすプランが見つからなかった場合でも、勝者オブジェクトは作成されますが、その中の m-expr は null ポインターであり、コンテキストに対する最適なソリューションが見つからないことを示します。保存して繰り返し使用できる結果でもあります。

EXPRESSIONの改善点

Columbia は Cacades の式 (1.67:1) を減算し、膨大なメモリを節約します。

ルール改善

Columbia は主に Cacades の RULE の設計を継承しましたが、バインディング アルゴリズムと処理エンフォーサにいくつかの改良を加えました。まず、バインディングの状態が減少し、CPU 使用率が減少し、3 状態のバインディング関数 BINDERY::advance() がより効率的になります。

次に、Columbia は、複雑さとメモリの増加を理由に除外された物理属性を非推奨にし、エンフォーサの再利用を防ぐために RuleMask ビットマップ構造を追加しました。

最後に、Columbia のエンフォーサはパラメータのない物理演算子属性です。たとえば、Cacades にパラメータを含める以前の方法と比較して、QSORT 演算子には並べ替えられた列属性 <AX, BY> と並べ替え方法 ASC/DESC が含まれています。エンフォーサはこれに準拠し、新しい式 QSORT(<AX, BY>) が生成され、GROUP にも保存されるため、同じ名前と複数のパラメーターを持つ式はすべて GROUP に保存されます。

RuleMask を利用することで、一度適用された物理属性は再度適用されなくなります。新しい物理属性が適用された後は、重畳されたコストに基づいて計算コストも計算されます。物理属性を含む式がこれに応じて、勝者の構造体には通常の式と同じものが保持されます。最適な計画が決定された後、コロンビアは特定の執行者オペレーターのパラメーターを決定するためにさらに一歩を踏み出します。

タスク - 検索アルゴリズムの改善

Columbia は、未処理のタスクを処理するために PTasks を実装しています。

class TASK{
   
     friend class PTASKS;private :  TASK        * next;         // Used by class PTASKprotected :  int  ContextID;      // Index to CONT::vc, the shared set of contexts  int      ParentTaskNo;   // The task which created me   public :  virtual void perform ()=0;  //TaskNo is current task number, which will}; // TASKclass PTASKS{
   
   private :  TASK        * first;        // anchor of PTASKS stackpublic :  void push (TASK * task);  //##ModelId=3B0C085D016B  TASK * pop ();}; // PTASKS

オプティマイザの呼び出しエントリは次のとおりです。

void SSP::optimize(){   //Create initial context, with no requested properties, infinite upper bound,  // zero lower bound, not yet done.  Later this may be specified by user.  PTasks.push (new O_GROUP (RootGID, 0, 0));  // main loop of optimization  // while there are tasks undone, do one  while (! PTasks.empty ())  {
   
       TaskNo ++;                TASK * NextTask = PTasks.pop ();    NextTask -> perform ();        }}  // SSP::optimize()

TASKは5種類に分かれており、Cacadesで挙げられているグループ最適化(O_GROUP)、グループ探索(E_GROUP)、式最適化(O_EXPR)、入力最適化(O_INPUTS)、ルール適用(APPLY_RULE)のタスクと比較すると、次の図のようになります。それらの間の関係 呼び出し関係図。ここでは改善されたタスクのみを紹介します。

O_GROUP は O_EXPR と O_INPUTS を生成します。最適化が成功した場合は勝者のプランを生成し、そうでない場合は NULL プランを保存します。O_GROUP は 2 つのケースで呼び出されます。1 つ目は初期ケースで、論理式が 1 つだけ存在するケース、もう 1 つは異なる物理属性の検索コンテキストです。

Cacade は、グループ最適化 (O_GROUP) ステージでは物理演算子式を処理しません。つまり、グループ最適化が異なる物理属性コンテキストで再検索する場合、コストは再生成されて計算されますが、論理演算子式と物理演算子式はリスト内で処理されます。 , この段階では、以前に生成されたすべての物理演算子式も無視されるため、パフォーマンスが向上します。

E_GROUP は、新しい GROUP とその論理演算子 (JOIN の交換法則 RULE など) を生成します。Cascades では、グループ探索 (E_GROUP) は、複数の式を生成するために別のタスク E_EXPR を生成します。Columbia では、E_EXPR は O_EXPR に直接マージされますが、異なる関数をマークするためにフラグ (最適化/探索) が追加されます。

O_INPUTS ではプルーニング テクノロジが改良されました。これについては後で説明します。

剪定テクニックの改善

下限グループ プルーニング: トップダウン オプティマイザーは物理コストの計算に非常に時間がかかるため、最適化された上限最適化を使用するのは明らかですが、実際には、最適化全体では必要のない中間上限がまだいくつかあります。そのため、初期のグループ プルーニングにはコロンビア論理属性が使用されます。以下の図は、Lower Bound Group Pruning のアルゴリズムを示しています。

以下の図は、下限グループ プルーニングを使用することによってもたらされる巨大なプルーニング スペースの最適化を比較しています。

グローバル イプシロン プルーニング: オプティマイザは相対的に最適な実行プランしか取得できず、最適ではない可能性があるため、このグローバル変数を使用して検索時間を制御します。この値より小さいプランが見つかる限り、検索は続行されません。 。

O_INPUTS の Starburst/Pruning/CuCardPruning/GlobepsPruning 4 フラグを使用してプルーニング戦略を設定します。

1) スターバースト、プルーニング技術は採用されていません。

2) 枝刈りは従来のトップダウンの分岐と境界であり、現在の累積コストとコスト制限と比較されます。

3) CuCardPruning は、下限枝刈りを有効にすることを意味します。Pruning との違いは、最適化されていないグループ i の場合、InputCost[i] が 0 ではなく、グループの作成時に計算された下限コストになることです。

4) 最適化が完了した時点で GlobepsPruning が判定を行い、十分であると判断された場合はそのまま勝者として記録されます。

Columbia Optimizer for Cascades Optimizer Framework のいくつかの改善点を要約します。

1) より分離されたオプティマイザー フレームワークと DBI 標準。

2) C++ オブジェクト指向仮想メソッドを最大限に活用してスケーラビリティを実現します。

3) オブジェクトの頻繁な割り当てと破棄によって生じるパフォーマンスの問題。

4) トップダウン プルーニング テクノロジの改善は、単純に、より効率的な Cascades Optimizer フレームワークです。

✪ 2.2.7  Microsoft SQL サーバー

SQL Server 7.0 以降、Microsoft は Cascades Optimizer Framework アーキテクチャに基づいてオプティマイザーをリファクタリングしました。

SQL Server 以外の最も重要な派生製品も、引き続きこの拡張アーキテクチャを採用しています。

1) 並列実行に最適化された構造化計算 (SCOPE-並列実行に最適化された構造化計算は、Microsoft のデータ分析プラットフォームです。

2) SQL Server 並列データ ウェアハウス (PDW-並列データ ウェアハウス)。

3) SQL Server PDW V2 は、標準 SQL を使用して Haddop クラスター上のデータを管理およびアクセスする製品である Polybase をサポートします。

スペースの問題のため、この記事では PDW オプティマイザーについて簡単に紹介します。次の図は、PDW の全体的なアーキテクチャを示しています。PDW は、既存の SQL Server オプティマイザーを使用して変換された MPP アーキテクチャでもあります。

主なアイデアは次のとおりです。

• 分散テーブルのメタデータ情報や各計算ノードが集約した統計情報はシェルデータベースを通じて提供され、アプリケーションの統一的な入り口とシステムを提供します。

• シェル データベースを通じて、SQL Server の既存の強力なオプティマイザーを最大限に活用して、さまざまなオプションの実行計画 (MEMO) を生成できます。

• 生成されたオプションの実行プランにデータ移動操作を直接追加し、コストに基づいて最適な分散実行プランを評価および選択します。

SQL Server オプティマイザーのシリアル プランは、元のオプティマイザーが MPP を目的としていないため、データ分散を意識していないため、最適なプランを生成できませんが、PDW では、JOIN/GROUP BY などの演算子が MPP 上でどのように再分散されるかを考慮する必要があります。シリアル計画全体のメモは、XML ジェネレーター コンポーネントを通じて PDW オプティマイザーに渡されます。

以下の図からわかるように、グループ 1 ～ 4 はシリアル プランのメモであり、グループ 5 ～ 6 以降は拡張 MPP のメモです。

PDW はボトムアップの検索戦略を採用し (実際、PDW はトップダウン戦略にすることもできますが、DMS により検索スペースが膨大になります)、同時に System R の興味深い特性を利用します。 ) 結合述部の列と ( b) グループ化列。

ここで違いを強調する必要があります。生成された最良の物理的実行プランが最終的に DPlan を生成します。DPlan は、Greenplum などのデータベースとは異なる方法を選択しました。つまり、コンピューティング ノードで実行されたプランを SQL に逆コンパイルするには QRel コンポーネントが必要で、その結果は Temp テーブルにキャッシュされ、その後再配布またはコピーされる必要があります。 DMS コンポーネント: 実装の次のステップについては、興味があれば、論文の Q20 に関する DPlan の内容を読むことができます。

PDW のアーキテクチャを要約すると、非 MPP データベースに新しい設計アイデアを提供します。これは、既存の強力なオプティマイザーを使用して、コントロール ノード + シェル データベースのメカニズムとデータ移動サービス モジュールを追加することで分散 MPP の問題を解決するというものです。エントリーとシステムを統一。

✪ 2.2.8  MemSQL オプティマイザー

MemSQL は、メモリベースのクラウドネイティブ分散データベースで、リアルタイムのトランザクションと分析の負荷、より高い同時実行性、および優れたスケーラビリティをより適切にサポートします。MemSQL は統合データベース エンジンを提供し、メモリ内の行ストレージとディスクバックの列ストレージを通じてデータを保存し、究極の HTAP 機能を提供します。ここで紹介する主な理由は、分散メモリ データベースに基づいて、HTAP ロードの革新的な機能強化のいくつかを学ぶことができるためです。

MemSQL のオプティマイザーは、メモリ最適化されたロックフリー スキップ リスト インデックス、列ストア エンジン、リアルタイム ストリーミング分析などの革新的なエンジンを目指しており、メモリに基づいているため、最適化された予算が非常に限られているため、多くの独自の設計が行われています。 。Optimizer for MemSQL はモジュール式で、次の 3 つの主要な部分に分かれています。

• リライターは、主に SQL から SQL への書き換えを行います。ワークロードの特性に応じて、ヒュースティック手法または分散コストに基づいて書き換えを選択します。オプティマイザーは、ボトムアップを使用してトップダウンでインテリジェントに実行できます。最適化: 2 つのアプローチを織り交ぜて最適化し、両方の利点を最大限に活用します。

• 最も重要なモジュールである Enumerator は、主にコストに基づいて分散結合の順序とデータ移動方法を決定します。また、ローカル結合順序とアクセス方法の選択も含まれます。リライター モジュールは、よく知られているコストベースのクエリ リライトであるクエリ変換フェーズ中にもこれを呼び出します。

• このモジュールの複雑な変換ロジックの実行計画であるプランナーは、一連の分散クエリとデータ移動操作になります。SQL 拡張機能の RemoteTables と ResultTables が定義されており、データの操作と移動には SQL に似た構文とインターフェイスが使用されます。これは PDW によく似ています。

例えば：

​​​​​​​

==== Input SQL, customer distributed by custkey and orders by o_orderkeySELECT c_custkey, o_orderdateFROM orders, customerWHERE o_custkey = c_custkey AND o_totalprice < 1000;===> DQEP Example(1) CREATE RESULT TABLE r0 PARTITION BY (o_custkey) AS SELECT orders.o_orderdate as o_orderdate, orders.o_custkey as o_custkey FROM orders WHERE orders.o_totalprices < 1000;(2) SELECT customer.c_custkey as c_custkey, r0.o_orderdate as o_orderdate FROM REMOTE(r0(p)) JOIN customer WHERE r0.o_custkey = customer.c_custkey

MemSQL には独自の革新性があることがモジュール設計からもわかります。

コストベースのクエリ リライト

MemSQL オプティマイザーのリライターは、革新的に Enumerator コンポーネントを使用して、分散コストに基づいてクエリのリライトを実行します。MemSQL 自体は、単純な列削除変換などのヒューリスティックと、Group-By プッシュダウンなどのコストベースをサポートしています。サブクエリ マージなどの特殊なものもあります。ほとんどの場合、ヒューリスティックが使用されますが、複数のファクト テーブルを含む吹雪のような SQL など、いくつかの大規模なデータ テーブル ビューには JOIN が使用されます。マージ後、大規模なクエリが発生します。列挙子の数を計算します。

したがって、この場合、MemSQL はヒューリスティック検出を提供して、マージするかブッシュ結合方式を使用するかを決定します。インターリーブされた変換、外部結合から内部結合への変換、および述語プッシュダウン変換ルールもあります。

次に、コストベースの例に注目してみましょう。

CREATE TABLE T1 (a int, b int, shard key (b))CREATE TABLE T2 (a int, b int, shard key (a), unique key (a))==== 初始SQLQ1: SELECT sum(T1.b) AS s FROM T1, T2 WHERE T1.a = T2.a GROUP BY T1.a, T1.b==== 可改写的形式Q2: SELECT V.s from T2, (SELECT a, sum(b) as s FROM T1 GROUP BY T1.a, T1.b ) V WHERE V.a = T2.a;

PDWの場合、SQL書き換え時にもコストモデルをフルに活用できることが利点であり、PDWの変換にはシェルデータベースを使用するため、シングルノードのコストモデルとなります。

ふさふさした計画のヒューリスティック

多数のテーブルのすべての可能な形状の結合ツリー列挙のコストは非常に高くなります。MemSQL も分散形式を列挙する必要があることを考慮すると、検索空間には追加の次元が必要です。したがって、設計上の決定から、コスト ベースを実行するときは、結合順序付け。左から深い結合ツリーのみを列挙します。

ただし、HTAP の位置付けにより、MemSQL は一部のスター/スノーフレーク モデル データ クエリを含むいくつかの複雑な分析クエリに直面する可能性があり、このクエリはブッシュ結合に比較的強く依存しているため、MemSQL の設計上の決定は、書き換え中に、ヒューリスティック検出では、ブッシュ結合パターンを実行し、可能性ごとに書き換えとコスト計算を実行して、コストに基づいてさまざまなブッシュ候補プランの最適性を比較できます。

左の深さの列挙子がブッシュ状ツリーを列挙するには、ブッシュ状の一部を派生テーブルに書き換えて、列挙子が各クエリ ブロックを個別に最適化してから結合するようにする必要があります。左奥。

要約すると、MemSQL オプティマイザーは、分散コスト モデルを完全に考慮したコストベースのクエリ最適化変換を革新的に追加します。また、PDW 氏が生成するシリアル実行プランやメモとは異なり、それらを直接拡張します。分散 最適化されたメモリ分散と分散コストにより、より効果的な分散計画を生成できます。JOIN の列挙プロセスでは、ヒューリスティックな手法を使用して星と雪の形の形状を発見し、最適化の効率と時間を大幅に短縮します。

✪ 2.2.9  Orca オプティマイザー

Orca は、Pivatol によって開発されたビッグ データ モジュラー MPP クエリ オプティマイザーであり、現在 Pivotal Greenplum Database および Pivotal HAWQ で使用されています。Orca のアーキテクチャは非常にユニークで、次の点を考慮して設計されています。

• モジュール性を備えた Orca は、スケーラブルな抽象メタデータとシステム記述を使用し、従来のオプティマイザーのように特定のホスト システムに限定されなくなりました。代わりに、メタデータ プロバイダー SDK でサポートされているプラ​​グインを介して、他のデータ管理システムにすぐに移植できます。

• 拡張性。Orca フレームワークは、新しいオペレーター/コスト モデル/プロパティ/ルールを拡張し、多段階最適化の罠を回避できます。つまり、一部の最適化は事後処理されるため、拡張が困難になります。

• マルチコア対応の Orca は、効率的なマルチコア対応スケジューラーを実装しています。これは、複数のコアに最適化サブタスクを分散して、最適化プロセスを高速化します。つまり、並列最適化をサポートします。

• 検証可能性: Orca は、パフォーマンスと正確性を検証できるツールのセットを提供します。

• パフォーマンス: Orca は、多くの場合、クエリを 10 倍から 1000 倍高速化します。

Orca とデータベース システムがどのように相互作用するかを見てみましょう

あらゆるデータベース システムをサポートするために、Orca はドッキング用の DXL シリーズ インターフェイスを提供していることがわかりますが、逆に、Orca オプティマイザーにアクセスしたい場合は、Query2DXL、MD Provider、および DXL2Plan の 3 つのモジュールを実装する必要があります。

• Query2DXL は、解析ツリーを DXL に変換します (CTranslatorQueryToDXL::TranslateSelectQueryToDXL)。

• DXL2Plan は、DXL を実行可能なプランに変換します (CTranslatorDXLToPlStmt::GetPlannedStmtFromDXL)。

• MD プロバイダーはメタデータを DXL に変換します (CMDProviderRelcache::GetMDObj)。

Orca 自体は PG データベース システムとの接続が比較的簡単です。多くの企業も他のデータベース システムのベンチマークを試みています。また、Huawei が Orca を MySQL に統合する方法については、「Integrating the Orca Optimizer into MySQL」を参照してください。Orca 自体のアーキテクチャを見てみましょう。

最適化フレームワークの違い

ここでは詳細には触れませんが、主にメタデータ キャッシュなどの Orca の特別な違いについて説明します。Orca はデータベース システムから独立しており、メタデータは頻繁に変更されないため、ORCA は対応するキャッシュを内部的に維持します。モジュールは、メモリ管理、ステート マシン、スレッド通信、例外処理、ファイル IO などの基本コンポーネントを提供します。

最適化ステージの違い

OrcaはCacadesアーキテクチャを採用していますが、Exploration（論理等価式変換）、Statistics Derivation（統計情報導出）、Implementation（物理等価式変換）、Optimization（最適化対象物性による、コストベースの最適化のための CostLimit など)。このうち、Statistics Derivation は Exploration プロセスの後に統計情報の導出を行い、JOIN などの特定の演算子に対する統計的約束 (Promise) を導入します。見積もり誤差が大きいです。

「SELECT T1.a FROM T1, T2 WHERE T1.a = T2.b ORDER BY T1.a」の例では、T1 データは T1.a に従って各計算ノードに分散され、T2 データは各計算ノードに分散されます。 T2.a によると、最適化の全体プロセス 探索、統計導出、実装の MEMO が実行されたと仮定すると、次の図で分析できます。

Orca は MPP ベースのオプティマイザーであるため、データ集約を実行する必要があり、ステートメントには ORDER BY T1.a 出力要件が含まれているため、最適化目標は req #1: {Singleton, T1.a} となり、2 つの代替物理プランを生成します。 (c)/(d) を検討し、最終的にコストを考慮して最終的な最良の計画を決定します。

メタデータ交換

以下の図は、Orca がさまざまなバックエンド システムとメタデータを交換する方法を示しています。クエリの最適化中、Orca によってアクセスされるすべてのメタデータ オブジェクトはメモリ内キャッシュに固定され、最適化が完了するかエラーがスローされると固定が解除されます。メタデータ オブジェクトへのすべてのアクセスは、MD アクセサーを通じて行われます。MD アクセサーは、最適化セッションでどのオブジェクトがアクセスされているかを追跡し、不要になったオブジェクトが確実に解放されるようにします。

MD アクセサーは、要求されたメタデータ オブジェクトがまだキャッシュにない場合に、外部 MD プロバイダーからメタデータを透過的に抽出する役割も担います。異なる最適化セッションを提供する異なる MD アクセサーには、メタデータを取得するための異なる外部 MD プロバイダーが存在する場合があります。

並列最適化

ORCA はマルチスレッドの最適化をサポートし、最適化ジョブ スケジューラを提供します。各最適化パスの複数のステージは、Cacade のタスクと同様に、次のタイプを含む異なるジョブに分割されます。

• Exp(g): グループの同等の論理式をすべて生成します。

• Exp(gexpr): グループ内の gexpr の 1 つに対して同等の論理式を生成します。

• Imp(g): グループの同等の物理表現をすべて生成します。

• Imp(gexpr): グループ内の gexpr の 1 つに対して同等の物理式を生成します。

• Opt(g, req): 最適化対象リクエスト req に対して、グループに基づく最小推定コストの実行計画を出力します。

• Opt(gexpr, req): 最適化対象リクエスト req に対して、グループ内の gexpr に基づく最小推定コストの実行計画を出力します。

• Xform(gexpr, t): ルールを使用して、GROUP 内の式 gexpr に対して同等の変換を実行します。

ジョブがキューに入れられると、複数のスレッドがキューからジョブを消費します。ジョブ間の依存関係は維持され、依存関係を並列化することはできません。

検証およびテストツール

Orca の最も注目すべき点は、計画を検証および反復するためのツールを提供していることです。DB2 には、シミュレーションと呼ばれる関連統計もあります。

AMPERe は、ユーザーの DB 環境にログインせずに ORCA を再現およびデバッグするために使用されます。ORCA 内で例外が発生した場合、または計画が期待を満たしていない場合、関連するメタデータ、クエリ、最適化構成が自動的に XML に並べ替えられ、ファイルにダンプされます。XML は、後で DB に入力せずに直接再生できます。

さらに、AMPERe を使用して、特定のダンプ ファイルと予想される計画を指定するだけで、テスト フレームワークを確立することもできます。

TAQO、バグが修正されたり、新しい機能が追加されたときに、生成されたプランのパフォーマンスがフォールバックしないようにする方法。TAQO ​​は、ORCA のコスト モデルの精度をテストするために使用されます。たとえば、コスト値が高いプランは、理論上、実行時間が長くなります。

要約すると、Postgresql の神レベルのオプティマイザーとしての Orca は、ビッグ データ プラットフォームの下で C/C++ ベースの MPP データベースに強力なツールを提供し、Java の Calcite と同様に、大幅なパフォーマンスも向上させる運命にあります。シリーズ ビッグ データ プラットフォーム オプティマイザーは広く使用されています。最も重要なことは、エンジニアリングの実装が非常に完璧であることですが、オプティマイザーが比較的「最適な」計画を迅速に生成するように導くために、何らかのガイダンスをサポートする必要があるいくつかの欠点もあります。

✪ 2.2.10 方解石オプティマイザー

Apache Calcite のオプティマイザーは、数少ないオープン ソースの Volcano/Cascades クエリ オプティマイザー実装の 1 つです。最初は Hive のオプティマイザーから生まれ、後に Apache Hive、Apache Storm、Apache Flink、Druid、MapD などの Java システムに採用されました。プロジェクトが支持されており、クラウドネイティブのビッグ データ プラットフォームや大手メーカーの分散データベースも Calcite オプティマイザーで強化されています。Orca とは異なり、Apache Calcite システムは基本的に独立したクエリ実行エンジンであり、フェデレーション テクノロジーを使用して異なる異種データ ソースを接続し、プラグイン オプティマイザーを提供します。

ただし、ここでは Apache Calcite オプティマイザーの部分についてのみ言及します。Apache Calcite の元の Volcano Planner は、この論文の標準実装ではありませんでした。

2020 年 4 月、Alibaba Cloud MaxCompute (ODPS) チームは CALCITE-3916 を提案しました: カスケード スタイルのトップダウン駆動ルールの適用をサポートし、実際のトップダウン オプティマイザーを追加し、バージョン #1991 をリファクタリングして、VolcanoPlanner 内に同じ機能を実装しました。また、有効または無効にする TOPDOWN_OPT オプションを提供します。

この機能は、2020 年 7 月についに master ブランチに導入されました。実装は基本的に標準論文に従っているため、その中で挙げられている比較は元々リストされています。

したがって、オプティマイザーのプロセス全体を次のように想像するのは難しくありません。

Calcite のオプティマイザーを要約すると、新しく導入されたトップダウン オプティマイザーは、Columbia の論文の説明に近い真のトップダウン検索を実現し、下限枝刈りを実現して最適化時間を節約し、物理的特性も改善します。最も理解しやすく、人気があり、実用的なオプティマイザーになります。

3. まとめ

その後のデータベースの多くは、革新のためのユーザー シナリオの実際の状況と組み合わせて、巨人の肩に依存しているようです。したがって、データベースが将来どのようになるかは、データベース カーネルに長年携わってきた私たちにとって実際に考える価値があります。

クラウド コンピューティングは、データベースの 2 番目の革新のための土壌を与えました。PolarDB シリーズのクラウドネイティブ データベースは、実際に、初期のオープン ソース データベースのオプティマイザーを大幅に強化する方法と、HTAP アーキテクチャとターゲットをより適切にサポートする方法を模索してきました。ハイブリッド コンピューティング システム、ストレージ分離とコンピューティング プッシュダウンのクラウド ネイティブ データベース アーキテクチャ システムをより適切にサポートする方法、実行フィードバックと AI テクノロジを通じてデータベースの自律性を提供する方法など、すべてを検討する価値があります。

最後に、この記事は比較的長く、一部の論文の詳細と実装については十分に詳しく説明されていません。コミュニケーションをとり、改善にご協力ください。

参考文献

[01] 1970 年、大規模な共有データ バンクのデータのリレーショナル モデル

https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

[02] 1971 年、関係計算に基づいたデータベース部分言語

https://dl.acm.org/doi/pdf/10.1145/1734714.1734718

[03] 1976 年、Ingres の設計と実装

https://www.seas.upenn.edu/~zives/cis650/papers/INGRES.PDF

[04] 1976 年、クエリ処理のための分解戦略

https://people.eecs.berkeley.edu/~wong/wong_pubs/wong45.pdf

[05] 1976 年、システム R: データベース管理へのリレーショナル アプローチ

https://dl.acm.org/doi/10.1145/320455.320457

[06] 1979 年、リレーショナル データベース管理システムにおけるアクセス パスの選択

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.3735&rep=rep1&type=pdf

[07] 1979 年、メイン メモリ データベース管理システムにおけるクエリ処理 

http://15721.courses.cs.cmu.edu/spring2016/papers/p239-lehman.pdf

[08] 1982、SQL のようなネストされたクエリの最適化について

https://dl.acm.org/doi/pdf/10.1145/319732.319745

[09] 1986 年、EXODUS 拡張可能 DBMS のアーキテクチャ

https://pages.cs.wisc.edu/~dewitt/includes/oodbms/exodus.pdf

[10] 1987 年、EXODUS オプティマイザー ジェネレーター

https://dl.acm.org/doi/pdf/10.1145/38713.38734

[11] 1988 年、クエリ最適化の代替手段を表現するための文法的な関数規則

https://people.eecs.berkeley.edu/~brewer/cs262/23-lohman88.pdf

[12] 1992 年、Starburst における拡張可能なルールベースのクエリ リライト最適化

https://dl.acm.org/doi/pdf/10.1145/130283.130294

[13] 1993 年、Volcano Optimizer Generator - 拡張性と効率的な検索

https://pdfs.semanticscholar.org/a817/a3e74d1663d9eb35b4baf3161ab16f57df85.pdf

[14] 1994 年、Volcano - 拡張可能な並列クエリ評価システム

https://paperhub.s3.amazonaws.com/dace52a42c07f7f8348b08dc2b186061.pdf

[15] 1994 年、リレーショナル データベース システムへのマジック セットの実装

https://sigmodrecord.org/publications/sigmodRecord/9406/pdfs/191843.191860.pdf

[16] 1995 年、クエリ最適化のためのカスケード フレームワーク

https://pdfs.semanticscholar.org/360e/cdfc79850873162ee4185bed8f334da30031.pdf

[17] 1998 年、リレーショナル システムにおけるクエリ最適化の概要

https://web.stanford.edu/class/cs345d-01/rl/chaudhuri98.pdf

[18] 1998 年、コロンビア データベース クエリ オプティマイザーの効率化

https://15721.courses.cs.cmu.edu/spring2019/papers/22-optimizer1/xu-columbia-thesis1998.pdf

[19] 2001 年、トップダウン クエリ最適化における上限と下限の活用

http://web.cecs.pdx.edu/~len/IDEAS01.pdf

[20] 2006 年、Oracle におけるコストベースのクエリ変換

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.403.4568&rep=rep1&type=pdf

[21] 2009 年、Oracle の拡張サブクエリ オプティマイザー

http://www.vldb.org/pvldb/vol2/vldb09-423.pdf

[22] 2012、Microsoft SQL Server PDW でのクエリの最適化 

https://www.microsoft.com/en-us/research/publication/query-optimization-in-microsoft-sql-server-pdw/

[23] 2014 年、Orca: ビッグ データ用のモジュラー クエリ オプティマイザー アーキテクチャ

http://15721.courses.cs.cmu.edu/spring2016/papers/p337-soliman.pdf

[24] 2016、MemSQL クエリ オプティマイザー: 分散データベースにおけるリアルタイム分析のための最新のオプティマイザー

http://www.vldb.org/pvldb/vol9/p1401-chen.pdf

参考リンク

[01] 関係代数

https://en.wikipedia.org/wiki/Relational_algebra

[02] CMU 15721コース

https://15721.courses.cs.cmu.edu/spring2020

[03] オプティマイザーの技術論文の検討

https://www.zhihu.com/column/c_1364661018229141504

[04] System Rの歴史

https://people.eecs.berkeley.edu/~brewer/cs262/SystemR.pdf

[05] Calcite の新しいトップダウン オプティマイザー

https://ericfu.me/calcite-top-down-planner/

[06]  GPORCA オプティマイザーの Transform プロセスをわかりやすく説明する

[07] データベースカーネルのコストベースの最適化エンジン

https://www.codenong.com/cs109287432/

[08] 火山/カスケードオプティマイザー

https://www.slideshare.net/ssuser9ebf46/the-volcanocascades-optimizer