【要約】Database Link使用時のADBからBaseDBへアクセス時の性能比較 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
データプラットフォームの統合において、ADBをハブとして外部ソースへフェデレーテッドクエリを行う際の性能指標が不明確であった。設計者は以下の課題に直面していた。
- ・Database Link経由の検索時間やCPU使用率の定量的データが不足。
- ・Select AI（NL2SQL機能）導入時の実行時間増加幅が不明。
- ・導入検討や他プラットフォームとの比較材料が欠如。
// Approach
検証者は、OCI環境下でADBとBaseDBを接続し、異なるアクセス手法による性能差を実測した。検証は以下の構成で行われた。
- ・比較対象：表、ビュー、MVの3形態で同一クエリを実行。
- ・Select AI検証：直接SQL、SHOWSQL、RUNSQLの3パターンで比較。
- ・環境：ADB (ATP, 26ai, 4 ECPU) と BaseDB (EE-HP, 19.32, 2 OCPU) を使用。
- ・データ：決済関連の10万件サンプルを使用。
// Result
検証の結果、アクセス手法の違いにより、クエリ性能とリソース負荷に明確な差が出た。設計者は以下の知見を得た。
- ・MVは表・ビューと比較して平均経過時間が30%以上短縮。
- ・MVはADB側で処理が完結するため高速だが、作成・更新時にBaseDBへ負荷がかかる。
- ・Select AIは直接SQLに比べ、実行時間が秒単位（約12秒前後）へ大幅に増加。
- ・Select AIの遅延は、LLM生成および通信（Gemini 2.5 Pro）に起因する。
Senior Engineer Insight
> 本検証は、データ連携における「鮮度」と「速度」のトレードオフを浮き彫りにしている。実戦投入にあたっては以下の視点が重要だ。
- ・データの更新頻度に応じ、リアルタイム性はビュー、速度重視ならMVと使い分けること。
- ・MV採用時は、BaseDB側のリフレッシュ負荷がボトルネックにならないか考慮せよ。
- ・Select AIは利便性が高いが、秒単位のレイテンシはリアルタイム処理には不向きである。
- ・AI Profileによるソース制限や、リージョン選定による通信遅延の抑制が不可欠となる。