ステートメントの実行

作成段階が完了すると、Virtual DataPort は、クエリや更新をいつでも受け付けられるようになります (SQL 92 標準で定義されているように、更新は「更新可能ビュー」でのみ実行可能)。外部アプリケーションによる Virtual Database 上でのステートメントの送信および実行方法の詳細については、「 Developer Guide 」で説明しています。ここでは、内部でのステートメントの実行プロセスの概要についてのみ説明します。

Virtual DataPort クエリインタープリターは、VQL クエリを受信すると最初に、関係するビューのクエリ機能でクエリへの応答を取得できるかどうかを確認します。クエリに応答できなければ、ユーザーに通知されます。応答可能であれば、プロセスが継続します。

次に、 Plan Generator がクエリの実行プラン候補を作成します。これらのプランは通常、結合の実行時に使用されるアルゴリズムやソースで選択される特定の検索メソッドといった点で異なっています。

オプティマイザー モジュールは、さまざまなパラメーターに従って各プランのコストを取得する処理を受け持っており、最良のプランが選択されます。このプロセスは、さまざまなタスクのうちでも、Virtual DataPort サーバーとソース間で処理を最適に分散し、groupby、選択条件、結合や和結合などの演算を可能な場合には委任する役割も持っています。そのため、ネットワーク上のデータ転送を最小限に抑えることができます。また、この段階では、結合演算子の最適な実装方法の選択、膨大な結果をディスクにスワップする方法の策定、 キャッシュ モジュールの使用管理などのタスクも実行します。詳細については、管理ガイドの「 クエリの最適化 」を参照してください。

最適なプランが選択されると、 実行エンジン はそれを実行に移します。プランの実行では、 基本リレーション のみに関して記述された一連のサブクエリが実行されることを想定しています。これらのサブクエリは、対応するソースの ラッパー により実行されます。Virtual DataPort が並列処理を最大限に活用でき、サブクエリ群が通常は並列に実行されることは、注目すべきことです。

最後に、実行エンジンは、各プランで指定されたとおりにソースから返された結果を組み合わせて、クエリへの最終的な応答を取得します。

重要なのは、システムは 非同期 に動作するということです。つまり、ソースの結果が処理可能になると、ソースがまだ応答を完全に返していなかったとしても、システムは結果を処理し始めます。これにより、最終結果の最初のタプルを取得するまでの時間が大幅に短縮されます。また、システムが 結果の一部のみ を処理できるのも重要なことです。つまり、いくつかのソースに一時的にアクセスできなくても、システムはクエリを処理することができ、クライアントアプリケーションにエラーを通知するとともに、残りのソースで取得可能な結果を返します。

また、前述のように、オプションでソースデータのすべてまたは一部をサーバーの キャッシュ にプリロードできることも忘れてはなりません。この場合、システムは受信したサブクエリをキャッシュに含まれるデータで解決できるかどうかを確認します。解決可能な場合、ソースに対してクエリを実行せずに、同じ応答をキャッシュから直接得られます。

Virtual DataPort では、SQL-92 の標準の定義に従ってビューを更新できる場合、ビューに対する更新ステートメント (INSERT/UPDATE/DELETE) を実行することもできます。詳細については、「 ビューに対する挿入、更新および削除 」のセクションを参照してください。