# クエリレイテンシ予測 ## 定義 クエリレイテンシ予測(QPP: Query Performance Prediction)は、データベース管理システム(DBMS)における SQL クエリの実行時間を事前に推定する問題である。クラウド環境でのリソース管理、スケジューリング、SLO 遵守、クエリ最適化に直接活用される。 --- ## 問題の構造 QPP はクエリの実行レイテンシに影響する要因を大きく 2 種類に分類できる: | 要因 | 内容 | |------|------| | クエリ固有要因 | クエリの複雑さ、結合順序、アクセスパス、カーディナリティ推定精度 | | システムコンテキスト要因 | ハードウェア種別(CPU/メモリ/I/O)、仮想化・マルチテナント負荷、クラウドインスタンス種別 | 従来の多くの手法はクエリ固有要因のみをモデル化し、システムコンテキストが一定であると仮定する。しかしクラウド環境ではこの仮定が成立しないことが多い。 --- ## 主要アプローチ系譜 ### 古典的コストモデル(1980年代〜) DBMS 組み込みの手解析型コストモデル。CPU、I/O、メモリを演算子ごとに見積もる。クラウド環境では DBMS コスト推定値と実際のレイテンシが乖離することが多く、Microsoft SCOPE や AWS Redshift でその限界が報告されている。 ### 機械学習ベース QPP(2010年代〜) クエリプランを ML で直接学習するアプローチ。以下のサブカテゴリが存在する: - **演算子単位モデル(Per-operator model)**: クエリプランの各演算子にモデルを適用 - **クエリプランモデル**: クエリプラン木全体を GNN・CNN で処理 - Tree Convolutional Neural Network (TCNN) - Graph Convolutional Network (GCN) - QueryFormer(トランスフォーマーベース) - **特徴フラット化モデル**: クエリプランのキー特徴量を平坦な特徴ベクトルに変換 ### インスタンス特化モデル(Instance Optimized Model) 特定のデータベース・システム環境の組み合わせに特化して学習するモデル。高精度だが、**新規システムコンテキストへの汎化が困難**という根本的課題がある。AWS Redshift では百万件のクエリがあっても「グローバルに有用なものが学習されない」という問題が報告されている。 ### システムコンテキスト考慮型 QPP(2024〜) [[OSprey]] が代表例。クエリ特性とシステムコンテキストを分離して学習する**因数分解型アーキテクチャ**を採用。OS メトリクス時系列を入力とする事前学習済みトランスフォーマーでシステム状態を汎化的に表現し、DB 特化 GCN と統合する。 --- ## 評価指標 - **Q-Error(乗算誤差)**: max(y/ŷ, ŷ/y)。対称的で解釈しやすく、過小/過大推定を同等に扱う。多くの QPP 研究で採用 - **相対誤差**: |y - ŷ|/y。非対称のため過大推定を過剰に罰する傾向がある --- ## 横断的知見 ### OSprey(2024, [[MIT CSAIL]]) - [[@2024__arXiv__OS Pre-trained Transformer - Predicting Query Latencies across Changing System Contexts]] - **因数分解の効果**: クエリ特性モデル(DB 特化 GCN)とシステム状態モデル(OSprey)を独立に学習することで、単一環境での学習から複数環境への汎化が可能 - **実験規模**: 14 ワークロード × 10 AWS インスタンス × 3 繰り返し、150K+ PostgreSQL クエリプラン - **定量的改善**: 新規システムコンテキストで中央値・平均 Q-Error を最大 3× 改善。GCN (DB, Same Env) と同等の精度を新規環境で達成 - **OS メトリクスの重要性**: 92 種類の SAR メトリクスのうち、Block Device・ページング統計・I/O 圧力停止ログが IMDb ワークロードで特に重要 ### クラウド DBMS 産業実装の課題(AWS Redshift, Microsoft SCOPE) - 数百万クエリがあってもグローバルに有用なモデルが学習されない問題 - 新規インスタンスで数百クエリを見るまで予測できない問題 - 「what-if」質問(例: メモリを増やしたら?)への対応困難 --- ## 未解決の問い 1. **大規模商用クラウドへのスケールアップ**: OSprey は 10 インスタンス・小規模ワークロードの証明概念。Snowflake・Redshift 規模(日次数百万クエリ)での有効性は未検証 2. **分散 DBMS**: 複数ノードの OS ログをどう統合するか。ノード間の因果関係をどう表現するか 3. **ログ収集コスト削減**: 92 種類のメトリクスをどう軽量に収集・送信するか。どのメトリクスが本質的か 4. **事前学習データの質と量**: 何種類・何規模のハードウェアで事前学習すれば汎化が十分か 5. **マルチクラウド対応**: AWS・GCP・Azure でメトリクスの種類・名称が異なる環境での適用方法 6. **リアルタイム性**: システム状態が急変するケース(クエリ実行中の負荷スパイク)への対応 --- ## 関連概念 - [[データベース自律診断]] — QPP は異常な性能劣化の原因分析にも活用される - [[データベースノブチューニング]] — 予測精度がチューニング効果の評価にも関与 - [[近似クエリ処理]] — 実行時間削減アプローチとの補完関係 - [[データベース O&M]] — QPP は O&M の構成要素 --- ## 出典 - [[@2024__arXiv__OS Pre-trained Transformer - Predicting Query Latencies across Changing System Contexts]]（本 wiki での初出、OSprey システム）