アーカイブ / LLM / RAG
TPとAPで実行時間が違う理由を、過去の実行計画から説明する
Query Performance Explanation through Large Language Model for HTAP Systems
概要
- TPとAPの実行計画を対として数値化し、似た過去事例と専門家の説明を検索して速度差の理由を文章にする。
- 代表事例20件と試験用200件を使い、三人の専門家が生成文の91％を正確で有益と評価した。
- 導入には両エンジンの計画と実行結果、専門家の説明、速い側を示す学習用ラベルが必要になる。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Query Performance Explanation through Large Language Model for HTAP Systemsの仕組み
- 01TP・APの実行計画
- 02計画対を数値化
- 03過去事例を検索
- 04速度差を文章化
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
この研究は、同じ問い合わせを二つのデータベースエンジンで実行したとき、速度が違う理由を利用者へ説明する。HTAPは取引処理と分析処理を一つの仕組みで扱う方式で、対象のByteHTAPでは取引向けのTPと分析向けのAPを比べる。
実行計画は、データベースが表の読み取りや結合をどう進めるかを示す。EXPLAINで計画を見られても、専門知識がなければ速度差の原因は分かりにくい。説明を毎回専門家に頼る負担も課題となる。
手法
過去の問い合わせについて、双方の計画、どちらが速かったかという実行結果、専門家による理由を保存する。tree-CNNは木の形をした計画を読む小型モデルで、両計画を検索用の数値の並びに変える。元のモデルは、計画対から速いエンジンを予測するよう学習されている。
新しい問い合わせでも計画対を変換し、近い過去事例を探す。RAGは検索した情報を文章生成時に参照させる方法で、検索結果、今回のSQLと計画、実行結果などを言語モデルへ渡す。例えば三つの表を結ぶSQLでは、結合方法や索引の利用が速度差にどう関わるかを説明させる。根拠が足りなければ「None」を返す指示もある。
新規性
著者らの特徴的な工夫は、TPとAPの実行計画を対にして表し、過去に専門家が説明した性能差に近い事例を探す点にある。検索には、速いエンジンを予測するために学習した小型モデルの中間表現を使う。
説明する対象は、モデルがどちらのエンジンを選んだかという判断ではない。両方で実行した後に確認された速度差の理由を、検索した事例と今回の計画に沿って文章にする。
従来手法との違い
EXPLAINはデータベースの処理手順を示すが、専門家でない利用者には速度差の理由を読み取りにくい。専門家が問い合わせごとに説明する方法も、件数が増えると負担になると著者らは述べる。
関連研究のDBG-PTは同じ最適化器が作った計画を比較する。本研究は異なるエンジンの計画を扱う。ByteHTAPでは両エンジンの推定コストを直接比べられないため、その比較を避けるよう言語モデルへの指示に明記した。
実験結果
著者らはTPC-Hの表構成に沿う合成問い合わせから、専門家が説明した代表例20件を知識ベースに入れ、別の200件を試験に用いた。HTAPに詳しいデータベース専門家三人が生成文の正しさと情報量を評価し、91％を正確で有益と判定したと報告する。
検索事例が二～五件では評価は89～91％、一件では85％だった。参加者調査では、一つの結合問い合わせについて、計画だけを先に見た群の理解時間が平均8.2分、説明も最初から見た群が3.5分だった。参加人数は確認できた本文の範囲では不明である。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の分析基盤で、同じ集計SQLを取引向けと分析向けの両エンジンで実行した後、速度差の問い合わせに答える。入力はSQL、双方の実行計画と実行結果、直近の索引変更情報とし、担当者に理由の候補と参照事例を示す。
事前に、その基盤での計画、実行結果、専門家が記した理由を蓄積する。計画対を表すモデルの学習には速い側を示すラベルも必要だ。自社の計画形式に合わせて表現を調整し、生成文は担当者が確認する運用を想定する。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：社内の結合問い合わせに対象を絞り、TP・AP双方の実行計画と実行結果を集める。専門家が速度差の理由を記した過去事例と、速い側を示す学習用ラベルを用意する。計画の形式に合わせて数値化の方法を調整し、別の問い合わせを評価用に確保する。
担当者が計画だけを読む場合を基準に、生成文の理由の正確さと不足点を専門家が判定する。担当者の理解時間、誤った説明と「None」の件数も測る。索引変更後の問い合わせを含め、古い事例が説明に及ぼす影響を確認する。
限界と課題
著者らは、問い合わせ性能の説明を全面的に自動化するのは難しいと述べる。代表事例の自動選択と古くなった事例の除外は今後の課題としている。検索事例が一件の条件では、二～五件の条件より説明の評価が低かった。
編集上の検証事項は、自社の問い合わせに合う専門家の説明を集められるか、索引やデータ量の変更後も過去事例が妥当かである。参加者調査は一つの結合問い合わせを扱い、人数は確認できた本文の範囲では分からないため、理解時間の結果を広い業務に当てはめるには追加確認が要る。
出典
元のタイトル・要旨を確認する（英語）
Query Performance Explanation through Large Language Model for HTAP Systems
In hybrid transactional and analytical processing (HTAP) systems, users often struggle to understand why query plans from one engine (OLAP or OLTP) perform significantly slower than those from another. Although optimizers provide plan details via the EXPLAIN function, these explanations are frequently too technical for non-experts and offer limited insights into performance differences across engines. To address this, we propose a novel framework that leverages large language models (LLMs) to explain query performance in HTAP systems. Built on Retrieval-Augmented Generation (RAG), our framework constructs a knowledge base that stores historical query executions and expert-curated explanations. To enable efficient retrieval of relevant knowledge, query plans are embedded using a lightweight tree-CNN classifier. This augmentation allows the LLM to generate clear, context-aware explanations of performance differences between engines. Our approach demonstrates the potential of LLMs in hybrid engine systems, paving the way for further advancements in database optimization and user support.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01