2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Database Link使用時のADBからBaseDBへアクセス時の性能比較

2
Posted at

はじめに

Oracleには、Autonomous AI Database(以下ADB)を、MySQLやPostgreSQL、SnowflakeやDatabricksといった外部データソースに対して、フェデレーティッドクエリを行うためのLive AI Hubとして活用するアーキテクチャがあります。

少し調べると、Sidecarといった過去の名称で書かれた検証記事などが見つかりました。

しかし、肝心のDatabase Linkの性能、具体的には検索にかかる時間やCPU時間、Select AIというNL2SQLの機能を使用した時の検索にかかる時間といった、導入検討や他のデータプラットフォームとの比較材料が見つかりませんでした。

ということで、今回は以下の2つの観点で検証して、性能を比較してみます。

1. Database Link使用時に表、ビュー、マテリアライズド・ビュー(以下MV)の3つに対して同じ内容のクエリを投げた時の差異

2. Select AIを使った時に、どれくらい実行時間が増えるのか

前提条件

  • OCI周り

    • ADBとBaseDBはOCI東京リージョンの別のVCN内に作成
    • Select AIで使用したLLMはOCI大阪リージョンのGemini 2.5 Pro
    • ADBのワークロード・タイプはATPで、バージョンは26ai、スペックは4 ECPU
    • BaseDBのエディションはEE-HPで、バージョンは19.32.0.0.0。シェイプはE5で、スペックは2 OCPU
  • DB周り

    • 決済関連の100,000件のサンプルデータを用意して、BaseDBに表を作成
    • ビューはADB内に作成
    • MVもADB内に作成

表、ビュー、MVに対して同じ内容のクエリを投げた時の性能比較

クエリは「通貨ごとの件数と金額合計」を問うもので、FROM句だけ必要に応じて変えています。

それぞれ10回ずつ同じクエリを投げて、V$SQLの累積値を10で割ったのが以下の数字になります。

方式 平均経過時間 平均CPU時間 平均バッファ取得
8.354 ms 0.180 ms 4.3
ビュー 8.338 ms 0.181 ms 4.5
MV 5.627 ms 5.181 ms 1,256.9

FROM句にMVを指定した場合は、同じようにテーブルやビューをFROM句に指定した時と比べて平均経過時間が30%以上短くなりました。

また、テーブルとビューをFROM句に指定した場合はほぼ差がありませんでした。

当然、MVはBaseDB側で検索、集計を行わずにADB側で処理が完結するので、最も短い時間で結果が返ってきます。

MV作成・リフレッシュ時のBaseDBの負荷

上述のように、MVを使った場合は最も高速で検索できることがわかりました。

しかし、MVの参照をADBだけで完結できる代わりに、MVの作成やリフレッシュ時にはBaseDB側のCPUや読み取り、ADBへの転送負荷が発生します。

今回の100,000件の取得・転送では目立った負荷は確認できませんでしたが、より膨大なデータ量を扱う本番環境では注意が必要そうです。

ちなみに、今回は2度BaseDBから100,000行のデータを取得・転送しましたが、その時のCPU時間と経過時間の合計が以下です。

  • CPU時間合計: 108,358 ms
  • 経過時間合計: 133.252 ms

1回ずつ確認するのを失念してしまいましたが、2で割ればおおよその1回当たりの時間が算出できるかと思います。

Select AIを使った時に、どれくらい実行時間が増えるのか

今度は、Select AIを使った場合とそうでない場合に、どれくらいの時間を要するのかを比較します。

同じビューに対してのクエリを対象に、比較します。
(MVでも比較すればよかった...)

方式 平均経過時間 平均CPU時間
直接SQL 30.485 ms 8.585 ms
SHOWSQL 11,930.784 ms 72.365 ms
RUNSQL 13,522.850 ms 70.987 ms

今回はプロンプトからSQLを生成するだけのSHOWSQLと、SQLを生成し、そのSQLを実行もするRUNSQLも比較しています。

RUNSQLSHOWSQLの差は1,592.066 msであり、RUNSQLには生成したSQLの実行や、結果の整形といった処理が含まれるので、その処理に要した時間がその差に繋がったと考えます。

直接SQLを投げた場合との差に関しては、SQLの生成とOCI Generative AIサービスとの通信や応答、待機時間だと考えられます。

これが大阪ではなく、シカゴリージョンを利用した場合などはもう少し通信等に時間を要することが考えられます。

ただ今回は安易にGeminiを利用しましたが、GeminiはGoogleのデータセンターにあるGeminiを使っているので、そこのコールに要する時間が含まれているはずです。なのでOCIの中でホストしているモデルを使えばもう少しここの時間を短縮できるかもしれません。

まとめ

表、ビュー、MVとSelect AIでそれぞれ性能比較を実行しました。

表、ビュー、MVの中ではMVが最も高速に結果が返ってくることがわかりました。

その一方で、MVの作成やリフレッシュ時の参照元のデータソースにかかる負荷は本番利用時には考慮が必要かもしれません。

そのため、リアルタイム性が求められるデータはビューまたは表を使い、変更が多くないデータにはMVを使うなどの使い分けが求められてくるかと思います。

また、Select AI使用時の結果が返ってくるまでの速度という観点では、AI Profileでソースを絞りつつ、利用するモデルと使用するリージョンに関しても考慮が必要そうです。

機会があれば、ADBからSnowflakeをターゲットにした同内容の検証をしてみたく、検証できた際には同じように検証記事を書ければと思います。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?