> [!abstract] 概要(abstract の日本語訳) > 学習ベースのデータベース最適化技術は近年、学術研究において広く研究されているが、商用データベースシステムには広く展開されていない。本研究では自律データベースフレームワークを構築し、提案した学習ベースのデータベース技術をオープンソースデータベースシステム openGauss に統合する。学習型オプティマイザ(学習型クエリ書き換え、学習型コスト/カーディナリティ推定、学習型結合順選択および物理演算子選択)と学習型データベースアドバイザ(自己監視、自己診断、自己設定、自己最適化)を構築する有効な学習ベースモデルを提案する。学習モデルの有効性を検証する効果的な検証モデルを考案する。学習モデルを容易に展開するための効果的な訓練データ管理プラットフォームとモデル管理プラットフォームを構築する。実世界のデータセットで技術を評価し、実験結果は技術の有効性を検証した。学習ベース技術の展開から得た知見も提供する。 ## 論文情報 - **タイトル**: openGauss: An Autonomous Database System - **著者・所属**: Guoliang Li, Xuanhe Zhou, Ji Sun, Xiang Yu, Yue Han, Lianyuan Jin, Wenbo Li (Tsinghua University); Tianqing Wang, Shifu Li (Huawei) - **媒体**: PVLDB Vol.14, No.12, pp.3028–3041, 2021 - **DOI**: 10.14778/3476311.3476380 - **コード**: https://gitee.com/opengauss/openGauss-AI ## 概要 openGauss は清華大学と Huawei が共同で開発した自律データベースシステムである。学習ベースの最適化・管理技術を実際のオープンソース DBMS に統合することを目的とし、5 つの主要コンポーネント—学習型オプティマイザ・学習型アドバイザ・モデル検証・訓練データ管理・モデルデータ管理—を実装する。実際の顧客(中国郵政貯蓄銀行、China Mobile 等)で稼働した実績を持つ。 **Figure 1: The openGauss Architecture** ![[_attachments/vldb21-opengauss/fig01-architecture.png]] (Figure 1. openGauss のアーキテクチャ。左側が Learned Optimizer（クエリ書き換え、コスト/カーディナリティ推定、プラン生成）、右側が Learned Advisor（自己監視・自己診断・自己設定・自己最適化）。下部に訓練データプラットフォームとモデル管理プラットフォームを持つ。) ## 問題設定 - **入力**: SQL クエリ、データベース実行メトリクス(CPU 使用率・QPS・キャッシュヒット率など 500+ 項目)、実行ログ - **出力**: 最適化されたクエリプラン、根本原因の診断結果、最適なノブ設定、推薦インデックス/マテリアライズドビュー - **前提条件**: openGauss(PostgreSQL 互換オープンソース DB)上で動作。TensorFlow・PyTorch を ML バックエンドとして使用 - **課題 4 つ**: (1) モデル選択(どの ML モデルを使うか)、(2) モデル検証(有効性評価)、(3) モデル管理(複数モデルの統一プラットフォーム)、(4) 訓練データ管理(高品質な訓練データの収集) ## 提案手法 ### (1) 学習型オプティマイザ **(i) 学習型クエリ書き換え(MCTS)** スロー SQL クエリを等価でより高速なクエリへ変換する問題に対し、モンテカルロ木探索(MCTS)を採用する。ポリシーツリーを構築し、UCB 値 $UCB_i = x_i + \alpha\sqrt{\frac{\ln(f)}{f_i}}$ に基づいて最も有望な書き換え順序を効率的に探索する。ディープ推定モデルが中間書き換えクエリのさらなる書き換えによる潜在的なコスト削減を予測し、マルチエージェント MCTS が並列に探索する。 **Figure 2: MCTS によるクエリ書き換え** ![[_attachments/vldb21-opengauss/fig02-mcts-query-rewrite.png]] (Figure 2. MCTS ベースのクエリ書き換えの例。冗長な集約 MAX(c_custkey) を除去しサブクエリを引き上げることで 600 倍以上の高速化を実現する。左が入力クエリ(実行時間数分)、右が出力クエリ(実行時間 1.941 秒)。) **(ii) 学習型コスト推定(Tree-LSTM)** 現代の DBMS(PostgreSQL 等)における従来のカーディナリティ推定は、複数列の相関を捉えられないため大きな誤差が生じる。openGauss は木構造 LSTM モデルを採用し、実行計画の木構造に自然に対応した形でコストとカーディナリティを同時に推定する。3 層構成(埋め込み層・表現層・推定層)で、述語埋め込みに MIN/MAX プーリングを用いて AND/OR 意味を表現する。 **Figure 3: Tree-LSTM ベースのコスト推定器** ![[_attachments/vldb21-opengauss/fig03-tree-lstm-cost-estimator.png]] (Figure 3. 木構造 LSTM のアーキテクチャ。葉ノードが列・テーブル・演算子の埋め込みを保持し、親ノードに向かって表現が集約される。表現プールで過去の推定結果をキャッシュする。) **(iii) 学習型プラン生成(DRL + Tree-LSTM)** プラン列挙(結合順選択・物理演算子選択)を MDP としてモデル化し、DQN + Tree-LSTM で最適プランを生成する。固定長表現の問題を解消し、スキーマ更新・マルチエイリアスにも対応する。コスト訓練(Tree-LSTM の初期化)とレイテンシ調整(少量の実測レイテンシでファインチューニング)の 2 段階で訓練する。 **Figure 4: DRL ベースのプラン生成器** ![[_attachments/vldb21-opengauss/fig04-drl-plan-generator.png]] (Figure 4. 深層強化学習を用いたプラン生成のフレームワーク。状態 $s_i$ はプランフォレストで、各ステップで結合対象テーブルペアと演算子を選択する。Tree-LSTM Q ネットワークがプランツリーの表現を評価する。) ### (2) 学習型アドバイザ **(i) 自己監視(Self-Monitoring)** 500+ データベースメトリクスを収集し、LSTM オートエンコーダ + アテンション層で異常を検知する。Extreme Value Theory で動的しきい値を決定する。再構成誤差がしきい値を超えるデータを異常として報告する。 **(ii) 自己診断(Self-Diagnosis)** - **システムレベル診断**: KS(Kolmogorov-Smirnov)検定でメトリクスデータを定量化し、LSTM 異常検知 + 修正 KNN アルゴリズムで根本原因を診断する。 - **SQL レベル診断**: 実行プランを Tree-LSTM で符号化し、リアルタイムシステムメトリクスと連結して softmax でスロー演算子(根本原因)を特定する。 **Figure 5/6: 異常検知・システムレベル診断** ![[_attachments/vldb21-opengauss/fig05-06-anomaly-detection-diagnosis.png]] (Figure 5. LSTM ベースの異常検知パイプライン。前処理→エンコーダ→デコーダ→再構成誤差→しきい値判定。Figure 6. システムレベル診断のオンライン処理。メトリクス入力→異常検知→根本原因診断(CPU 飽和、DB バックアップ等)を出力。) **(iii) 自己設定(Self-Configuration / ノブチューニング)** ハイブリッドチューニングモジュールを提案する。(1) ルールモード: 専門家経験に基づくノブ推薦(高速・約 4 秒)。(2) 訓練モード: RL モデルを訓練して後続の DRL モードに提供。(3) DRL モード: DDPG を使ったディープ強化学習による最高精度チューニング(約 8 分)。DB_Agent がデータベース特性を抽出し、Algorithm Side が最適なノブ値を出力する。 **Figure 8: DRL ベースのノブチューニング** ![[_attachments/vldb21-opengauss/fig08-knob-tuning.png]] (Figure 8. ワークロードサイドからのベンチマーク実行 → ローカルホスト環境 → SSH 経由で DB_Agent が openGauss のノブ値とメトリクスをやり取りする構成。) **(iv) 自己最適化(Self-Optimization)** - **マテリアライズドビュー推薦**: エンコーダ・リデューサモデルで MV の利益を推定し、DQN で最適な MV セットを選択する。 - **インデックス推薦**: 仮想インデックスでコストを推定し、DQN でインデックスセットを選択する。 **Figure 9/10: MV・インデックス推薦器** ![[_attachments/vldb21-opengauss/fig09-10-mv-index-recommender.png]] (Figure 9. エンコーダ・リデューサベースの MV 推薦器。Attention→Encoder→Reducer でクエリと MV の特性を抽出し、RL エージェントが予算制約下で最適 MV セットを選択。Figure 10. DRL ベースのインデックス推薦器。仮想インデックスによるコスト推定 → DQN による選択。) ### (3) モデル検証(Workload2Graph) 学習モデルを配備する前に有効性を予測する。クエリワークロードをグラフに変換(演算子をノード、クエリ間の相関関係をエッジ)し、グラフ埋め込みモデルで同時実行クエリのパフォーマンスを予測する。グラフ圧縮アルゴリズムで大規模グラフに対応する。 ### (4) 訓練データ管理 / (5) モデルデータ管理 - 訓練データ: DB メトリクス時系列・SQL クエリ実行統計・システムログを収集し、相関列を同一テーブルに整理 - ML プラットフォーム: 訓練・予測・モデル管理の統一インターフェースを TensorFlow/PyTorch 上に構築し、RPC でカーネルから呼び出す ## 新規性 - **先行研究との差異**: Peloton や SageDB は自律 DB の概念を提案したが実システムを構築していない。Oracle/DB2/Redshift の自律的機能はヒューリスティックコストベースが中心。openGauss は学習ベースの手法群を検証・管理プラットフォームと共にオープンソース DB に実際に統合した最初の包括的システム - **Tree-LSTM の新規貢献**: Marcus の plan-structured NN(NEO)が固定長表現を使うのに対し、openGauss の Tree-LSTM はスキーマ更新・マルチエイリアスに対応し、コスト・カーディナリティの同時推定を行う - **モデル検証**: 同時実行クエリのパフォーマンス予測には BAL(バッファアクセスレイテンシ)や単一クエリ DL では不十分であり、ワークロードグラフ埋め込みで初めて正確に予測できる ## 実験設定 - **データセット**: JOB(21 テーブル・3.7 GB・113 クエリ)、TPC-C(9 テーブル・1.30 GB・912,176 クエリ)、TPC-H(8 テーブル・1.47 GB・22 クエリ)、TPC-DS(25 テーブル・1.35 GB・99 クエリ) - **環境**: TensorFlow + PyTorch をバックエンドに使用。DB カーネル内にデータ収集モジュールを実装し、RPC 経由で訓練/推論 - **ベースライン**: PostgreSQL、MySQL、Oracle(コスト推定)、DBA 実績値(ノブチューニング・インデックス)、DBSherlock(システム診断)、VAE/GAN(異常検知) ## 実験結果 ### 学習型オプティマイザ | タスク | 指標 | openGauss | ベスト競合 | |--------|------|-----------|----------| | クエリ書き換え(TPC-H) | 実行時間削減率 | **49.7%以上** | PostgreSQL(0%) | | クエリ書き換え(JOB) | 実行時間削減率 | **36.8%以上** | – | | カーディナリティ推定(JOB) | 中央値誤差 | **10.1** | PostgreSQL 184, MySQL 104 | | コスト推定(JOB) | 平均誤差 | **7.06** | PostgreSQL 105, MySQL 173 | | プラン生成(JOB) | GMRL | **0.67** (DP=1.0) | DQ 1.23, ReJoin 1.14 | ### 学習型アドバイザ | タスク | 指標 | openGauss | ベスト競合 | |--------|------|-----------|----------| | ノブチューニング(TPC-H) | 実行時間 | **82.7 秒** | DBA 95.1 秒(13% 削減) | | ノブチューニング(TPC-C) | tpmC | **12,118** | DBA 7,023(72% 向上) | | 異常検知(TPC-C) | F1 | **0.785** | GAN 0.635, VAE 0.441 | | SQL 診断 | 適合率 | **0.913** | PostgreSQL 0.826 | | システム診断(TPC-C) | F1 | **0.869** | DBSherlock 0.549 | | インデックス推薦(TPC-H) | 実行時間 | **122.9 秒** | DBA 130.1 秒 | ### モデル検証 - 予測精度: BAL 比 **29.9 倍**低い誤差率、DL 比 **22.5 倍**低い誤差率 - 予測レイテンシ: BAL 比 最大 **1,227%** 高速 ### 産業利用 - ノブチューニング: 分析クエリで 27% のレイテンシ削減、高並列トランザクションで 120% スループット向上 - インデックス推薦: スループット 100% 向上 ## 考察 - ルールモードとDRL モードの組み合わせが鍵: ルールモードで探索空間を絞り、DRL モードで高精度を狙う設計が産業現場で有効 - Tree-LSTM は計画構造への自然な適合が優位性の源泉: 木構造の底から根へ再帰的に情報を集約することで、列間の相関を捉えられる - モデル検証は展開安全性に不可欠: グラフ埋め込みによる事前予測がなければ、学習モデルが性能を悪化させるリスクがある ## 強み / 弱点・課題 **強み** - 実際のオープンソース DBMS への統合実績があり、実顧客での有効性が確認されている - 5 コンポーネントが統一プラットフォームで相互連携する包括的設計 - MCTS・Tree-LSTM・DRL・GNN という異種 ML 手法を適材適所で組み合わせている **弱点・課題**(論文の§8 より) 1. **コールドスタート問題**: 学習モデルはオフライン学習に依存しており、新規データベースへの適応が困難 2. **スキーマ更新への対応**: 学習モデルがデータベースのスキーマ変更に追従する機構が不十分 3. **ML プラットフォームのコスト**: TensorFlow は即時フィードバックができず、軽量な in-database ML が必要 4. **"one size does not fit all"**: シナリオごとに適切な手法を自動選択する仕組みが未整備