BIサーバーの問合せキャッシュについて
BIサーバーを構成して、問合せ結果セットのディスクベース・キャッシュをローカルに保持できます(問合せキャッシュ)。
問合せキャッシュを使用すると、BIサーバーがバックエンド・データソースにアクセスせずに、後続の問合せリクエストを多数処理できるため、問合せパフォーマンスが向上します。
バックエンド・データベースで更新が発生すると、問合せキャッシュのエントリが古くなることがあります。このため、次のいずれかの方法を使用して、問合せキャッシュから定期的にエントリを削除する必要があります。
-
手動。管理ツールの「管理」メニューで「キャッシュ」を選択して、キャッシュ・マネージャを開きます。キャッシュ・マネージャでは、パージするキャッシュ・エントリやパージする日時をきわめて柔軟に選択できますが、手動の作業が必要です。キャッシュ・マネージャの使用を参照してください。
-
自動。管理ツールでは、システムのキャッシュの無効化、特定の物理表のキャッシュ属性の設定、およびBIサーバーのイベント表を使用したキャッシュの自動パージが可能です。キャッシュのモニターおよび管理を参照してください。
-
プログラム。BIサーバーには、プログラムでキャッシュ・エントリをパージするためのODBC拡張関数があります。これらの関数により、イベント表の自動化に関して、キャッシュ・マネージャの選択とタイミングの柔軟性が高まります。独自のスクリプトを記述して、これらの関数を必要に応じて呼び出すことができます。ODBCプロシージャを使用したキャッシュのパージと保守を参照してください。
問合せキャッシングを制御するパラメータは、Fusion Middleware Controlと、「構成ファイル設定」に記載されているNQSConfig.INIファイルにあります。「エージェントを使用したOracle BIサーバー問合せキャッシュのシード」を参照してください。
このセクションには次のトピックが含まれます:
問合せキャッシュのアーキテクチャ
問合せキャッシュは、キャッシュ記憶領域、キャッシュ・メタデータおよび問合せコンパイルでのキャッシュ検出で構成されます。
BIサーバーのキャッシュ・メタデータへのアクセスのプロセスは非常に高速です。メタデータがキャッシュ・ヒットを示す場合は、大部分の問合せ処理がなくなり、ユーザーに結果が即時に返されます。新しい結果をキャッシュに追加するプロセスは、ユーザーに返される結果には関係しません。実行中の問合せに影響するのは、キャッシュされた結果を書き込むプロセスで使用されるリソースだけです。
問合せキャッシュ・エントリは、WindowsやLinuxの64ビット・アーキテクチャなどの様々なオペレーティング・システム間で移植可能です。互換性のないキャッシュ・エントリは、自動的に削除されます。
問合せキャッシュのエントリは、異なる更新のOracle Analytics Serverの間では移植できないことに注意してください。
キャッシングはサブリクエスト・レベルでデフォルトで発生し、SQL文によっては複数のキャッシュ・エントリが生じます。リアルタイムと過去のデータを組み合せた問合せの場合は特に、サブリクエストのキャッシングによって、パフォーマンスとキャッシュ・ヒット率が向上します。サブリクエスト・キャッシングを無効にするには、NQSConfig.INIファイルのパラメータDISABLE_SUBREQUEST_CACHINGをYESに設定します。「構成ファイル設定」を参照してください。
キャッシングの利点
問合せを最も速く処理する方法は、大部分の処理をスキップして、あらかじめ計算された答えを使用する方法です。
問合せキャッシングにより、Oracle BIサーバーは、あらかじめ計算された問合せの結果をローカル・キャッシュに保存します。別の問合せでその結果を使用できる場合、その問合せに対するすべてのデータベース処理がなくなります。これにより、平均問合せレスポンス時間が大幅に向上します。
パフォーマンスが向上すること、およびローカル・キャッシュから問合せに応えることができることにより、ネットワーク・リソースとデータベース・サーバーの処理時間も節約できます。中間結果がOracle BIサーバーに返されないため、ネットワーク・リソースが節約されます。データベース上で問合せを実行しない分、データベース・サーバーは別の処理を実行できます。データベースでチャージ・バック・システムを使用する場合、実行する問合せが減ることで予算のコストも削減される可能性があります。
キャッシュを使用して問合せに応えるもう1つの利点は、問合せ結果が複数のデータベースから取得される場合は特に、Oracle BIサーバーの処理時間が短縮されることです。問合せによっては、かなりの数の結合とソートの処理がサーバーで実行されます。問合せがあらかじめ計算されていればこの処理が回避され、サーバー・リソースを他の処理で使用することもできます。
要約すると、問合せキャッシュは、問合せのパフォーマンスを劇的に向上させ、ネットワーク・トラフィック、データベース処理および処理のオーバーヘッドを削減できます。
キャッシングに伴う代償
問合せキャッシングには明らかに多くの利点がありますが、次のような代償も伴います。
-
キャッシュ用のディスク領域
-
キャッシュを管理するためのコスト
-
キャッシュされた結果が古くなる可能性
-
サーバー・コンピュータ上のCPUとディスクI/O
キャッシュ管理では、通常、利点が代償をはるかに上回ります。
ディスク領域
問合せキャッシュには、専用のディスク領域が必要です。
領域の大きさは、問合せのボリューム、問合せ結果セットのサイズおよびキャッシュに割り当てるために選択するディスク領域の大きさに依存します。パフォーマンスを向上するためには、ディスクをキャッシング専用で使用し、必ずパフォーマンスと信頼性に優れたディスク・システムとなるようにします。
管理タスク
管理タスクには、キャッシングに関連するがものがあります。各物理表に対して、その表内のデータの更新間隔を理解した上で、キャッシュの保持時間を適切に設定する必要があります。
更新の頻度が状況によって異なる場合は、変更が発生するタイミングを追跡し、必要に応じてキャッシュを手動でパージする必要があります。
キャッシュのイベント・ポーリング表を作成し、データベースに対する変更が発生するときにポーリング表を更新するようにアプリケーションを変更することで、システムをイベント駆動型にすることもできます。
Oracle BIサーバーには、プログラムでキャッシュ・エントリをパージするためのODBC拡張関数もあります。独自のスクリプトを作成して、適切なタイミングでこれらの関数を呼び出すことができます。
最新の状態のキャッシュの維持
基礎となるデータベース内のデータが変更されたときにキャッシュ・エントリがパージされないと、問合せが返す結果が最新のものでなくなる可能性があります。
これが許容できるかどうかを評価する必要があります。キャッシュに多少古いデータが含まれていても、許容できる場合があります。許容できる古いデータのレベルを決定し、そのレベルを反映する一連のルールを構成(およびルールに準拠)する必要があります。
たとえば、アプリケーションで大規模なコングロマリットの企業データを分析し、その企業の様々な部門のサマリーを毎年実行しているとします。新しいデータは翌年のサマリーにのみ影響するため、実質的には問合せに影響しません。この場合、キャッシュをパージするかどうかを決定するときに、トレードオフを考慮した上で、キャッシュにエントリを残しておくようにすることもできます。
しかし、データベースが1日に3回更新され、本日のアクティビティについて問合せを実行している場合はどうでしょう。その場合は、より頻繁にキャッシュをパージするか、場合によってはキャッシュをまったく使用しないようにすることも検討する必要があります。
もう1つのシナリオは、定期的に(たとえば、週に1回)データセットを一から再構築する場合です。この例では、データセットを再構築するプロセスの一部としてキャッシュ全体をパージして、キャッシュに古いデータがないようにします。
どのような状況でも、ユーザーに返される最新でない情報として許容されるものは何であるかを評価する必要があります。
ユーザー間でのキャッシュの共有
特定の接続プールに対して共有ログオンが有効になっている場合は、ユーザー間でのキャッシュの共有が可能であり、ユーザーごとにキャッシュをシードする必要はありません。
共有ログオンが有効ではなく、ユーザー固有のデータベース・ログオンが使用されている場合は、各ユーザーが独自のキャッシュ・エントリを生成します。
接続プールの共有ログオンの有効化については、Oracle Analytics Serverメタデータ・リポジトリの管理を参照してください。
XMLデータソースのリフレッシュ間隔について
通常、XMLデータソースは頻繁にリアルタイムで更新されます。XMLデータソースのリフレッシュ間隔を設定することは、データベース表のキャッシュの永続性を設定するようなものです。
リフレッシュ間隔とは、キャッシュ内の結果を使用するのではなく、XMLデータソースに対する問合せが再び直接実行されるまでの時間間隔です。このリフレッシュ間隔は、「接続プール」ダイアログの「XML」タブで指定します。
間隔のデフォルト設定は「無限」で、これは、XMLデータソースが自動的にリフレッシュされないことを意味します。
リフレッシュ間隔を設定すると、Oracle BIサーバーXML Gatewayの接続がリフレッシュされる時間間隔が次のように決定されます。
-
http://またはhttps://で始まるURLの場合、ゲートウェイは、所定の時間間隔が過ぎるとリフレッシュされます。 -
ローカル・ドライブまたはネットワーク・ドライブ上のURLの場合、ゲートウェイは、所定の時間間隔が過ぎて、システムがURLの変更を検出したときにリフレッシュされます。
XMLデータソースの詳細は、Oracle Analytics Serverメタデータ・リポジトリの管理を参照してください。
グローバル・キャッシュについて
クラスタ環境では、グローバル・キャッシュと呼ばれる共有キャッシュにアクセスするようにプレゼンテーション・サービスを構成できます。
このグローバル・キャッシュは、共有ファイル・システムのストレージ・デバイスに配置されており、パージ・イベント、シード・イベント(多くの場合はエージェントによって生成されます)、およびシード・イベントと関連付けられた結果セットを保存します。シード・イベントとパージ・イベントは、論理イベント・キューとして、時間でソートされ、共有記憶域に保存されます。個々のプレゼンテーション・サービス・ノードは、論理イベント・キューに対してプッシュおよびプルを行います。各プレゼンテーション・サービスでは、通常の問合せ用に独自のローカル問合せキャッシュが引き続き保持されます。
次の図は、クラスタ環境内でのグローバル・キャッシュを示しています。グローバル・キャッシュを共有している3つのプレゼンテーション・サービス・ノードが示されています。グローバル・キャッシュには、論理イベント・キューに保持されているシード・イベントまたはパージ・イベントが保存されています。ノード2およびノード3から共有キャッシュに向かう矢印は、プレゼンテーション・サービス・ノード2がシード・イベントをキューにプッシュし、プレゼンテーション・サービス・ノード3がパージ・イベントをキューにプッシュしていることを示します。共有記憶域から各プレゼンテーション・サービス・ノードに向かう矢印は、各ノードが共通の場所からプルしていることを示します。これは定期的に発生し、参加しているプレゼンテーション・サービス・ノードが他のプレゼンテーション・サービスによって行われた論理イベント・キューへの更新を取得できます。
プレゼンテーション・サービス・ノードは、最初にキャッシング・システムでシーディング・イベントまたはパージ・イベントをローカルに処理します。次に、共有記憶域上のグローバル・キャッシュにイベントをプッシュします。プッシュ・イベント中に、アクティブなプレゼンテーション・サービス・ノードは共有記憶域上の論理イベント・キューをロックして、シード・イベントまたはパージ・イベントをプッシュします。シードとパージが競合する場合(たとえば、あるノードが問合せをシードし、別のノードが同じ問合せをパージしようとする場合)は、最後のイベントが適用されます。
共有記憶域上のグローバル・キャッシュ内の論理イベント・キューは、個々のプレゼンテーション・サービス・ノードからのシード・イベントとパージ・イベントで構成されます。キューは、イベントのタイムスタンプでソートされます。このため、クラスタに参加しているすべてのプレゼンテーション・サービス・ノードのクロックが同期している必要があります。
各プレゼンテーション・サービス・ノードは、グローバル・キャッシュを定期的にポーリングして新しいキャッシュ・エントリを検出します。このポーリングの頻度は構成可能です。共有記憶域にあるキューに入っている論理イベントのスナップショットが元のノードにプルされ、ローカル論理イベント・キューが構成されてから、処理されます。
ノート:
クラスタに参加しているすべてのプレゼンテーション・サービス・ノードに対するシード・キャッシュの移入またはパージのプロセスはリアルタイムでは実行されず、プロセスにかかる時間は、あらかじめ定義されたポーリング間隔、ネットワーク・バンド幅、CPU負荷などの複数の要因の影響を受けます。
問合せキャッシュの結果セットは大きくなりがちなため、ネットワーク・バンド幅に関する制約を受ける可能性があります。したがって、次の項目を慎重に選択する必要があります。
-
シード・キャッシュに適したキャッシュのセット
-
共有記憶域からシード・キャッシュを取得するOracle Analyticsノードの時間間隔(ネットワークの輻輳の回避が目的)
主要なグローバル・キャッシュ・パラメータは、Fusion Middleware Controlで構成します。その他のオプションのパラメータは、クラスタに参加している各プレゼンテーション・サービス・ノードのNQSConfig.INIファイルで構成します。グローバル・キャッシュ・パラメータを設定するためのFusion Middleware Controlの使用および追加のグローバル・キャッシュ・パラメータの手動での編集を参照してください。
シード・プロシージャまたはパージ・プロシージャは、特定のプレゼンテーション・サービス・ノードに対して発行されます。そのプレゼンテーション・サービスがBIクラスタ内のノードであり、グローバル・キャッシュ・パラメータがプレゼンテーション・サービス構成ファイルで定義されている場合、シード・イベントまたはパージ・イベントは、同じクラスタ環境に参加しているすべてのプレゼンテーション・サービス・ノードに伝播されます。