問合せキャッシュの管理

Oracle Analytics Cloudでは、問合せ結果セットのローカル・キャッシュを問合せキャッシュに保持します。

トピック:

問合せキャッシュについて

問合せキャッシュにより、Oracle Analytics Cloudでは、バックエンド・データベースにアクセスすることなく後続の多くの問合せリクエストを処理でき、これによって問合せのパフォーマンスが向上します。ただし、バックエンドのデータ・ソースに更新があると、問合せキャッシュ・エントリが古くなる可能性があります。

キャッシュの利点

問合せを処理する最も速い方法は、大量の処理を回避し、事前計算された問合せ結果を使用することです。

問合せキャッシュを使用すると、Oracle Analytics Cloudにより事前計算された問合せの結果がローカル・キャッシュに格納されます。別の問合せでこれらの結果を使用する場合、その問合せのデータベース処理はすべて回避されます。これにより、問合せの平均レスポンス時間が大幅に向上します。

パフォーマンスの向上に加え、ローカル・キャッシュから問合せに返答することで、ネットワーク・リソースと、データベース・サーバーでの処理時間を節約できます。中間結果がOracle Analytics Cloudに返されないため、ネットワーク・リソースが節約されます。データベース上で問合せを実行しないため、データベース・サーバーは解放され、他の作業を実行できます。データベースでチャージ・バック・システムを使用する場合、実行する問合せが減ることで予算のコストも削減される可能性があります。

キャッシュを使用して問合せに返答することのもう1つの利点は、特に問合せ結果が複数のデータベースから取得される場合に、Oracle Analytics Cloudでの処理時間が節約されることです。問合せによっては、サーバーで多数の結合およびソート処理が行われる場合があります。問合せがすでに計算されている場合、この処理は回避され、サーバー・リソースが解放されて他のタスクに使用されます。

要約すると、問合せキャッシュは、問合せのパフォーマンスを劇的に向上させ、ネットワーク・トラフィック、データベース処理および処理のオーバーヘッドを削減できます。

キャッシュのコスト

問合せキャッシュには多くの明らかな利点がありますが、特定のコストもあります。

  • キャッシュされている結果が古い可能性

  • キャッシュを管理する管理コスト

キャッシュの管理によって、通常はメリットがコストをはるかに上回ります。

キャッシュに関連する管理タスク

管理タスクの中にはキャッシュに関連しているものがあります。物理表ごとにキャッシュ永続時間を適切に設定し、その表内のデータの更新頻度を認識しておく必要があります。

更新頻度が変わる場合は、変更が発生するタイミングを追跡し、必要に応じて手動でキャッシュをパージする必要があります。

キャッシュを最新の状態に維持

基礎となるデータベース内のデータが変更されたときにキャッシュ・エントリがパージされないと、問合せによって古い結果が返される可能性があります。

これを許容できるかどうかを評価する必要があります。キャッシュに、古いデータが含まれていても許容できる場合があります。古いデータをどの程度許容できるかを判断し、そのレベルを反映するようにルールを構成(して順守)する必要があります。

たとえば、アプリケーションで大規模なコングロマリットの企業データを分析し、その企業の様々な部門のサマリーを毎年実行しているとします。新しいデータは翌年のサマリーのみに影響するため、実質的には問合せに影響しません。この場合、キャッシュをパージするかどうかを天秤にかけ、キャッシュにエントリを残す方がよいと判断される可能性があります。

しかし、データベースが1日に3回更新され、当日のアクティビティに対して問合せを実行しているとします。この場合、頻繁にキャッシュをパージするか、キャッシュをまったく使用しないことを検討する必要があります。

もう1つのシナリオは、定期的に(たとえば、週に1回)データセットを一から再構築する場合です。この例では、データセットを再構築するプロセスの一部としてキャッシュ全体をパージして、キャッシュに古いデータがないようにします。

どのような状況にせよ、ユーザーに最新でない情報が返されることについてどの程度許容できるかを評価する必要があります。

ユーザー間でのキャッシュの共有

特定の接続プールで共有ログオンが有効な場合、ユーザー間でキャッシュを共有でき、ユーザーごとにシードする必要はありません。

共有ログオンが有効でなく、ユーザー固有のデータベース・ログインが使用される場合、各ユーザーは独自のキャッシュ・エントリを生成します。

問合せキャッシュの有効化または無効化

Oracle Analytics Cloudでは、問合せキャッシュはデフォルトで有効です。問合せキャッシュは、「詳細システム設定」ページで有効にしたり、無効にできます。

  1. 「コンソール」をクリックします。
  2. 「詳細システム設定」をクリックします。
  3. 「パフォーマンスと互換性」をクリックします。
  4. キャッシュ有効をオンまたはオフに設定します。
    • オン — データ問合せキャッシュは有効です。
    • オフ — キャッシュは無効です。
  5. 「適用」をクリックします。
    変更内容がシステム全体でリフレッシュされるまでしばらく待機します。

キャッシュのモニターおよび管理

基礎となるデータベースの変更を管理してキャッシュ・エントリをモニターするには、キャッシュ管理ストラテジを策定する必要があります。

キャッシュ・エントリを構成する基になる表のデータが変更されたときにキャッシュ・エントリを無効にするプロセス、および望ましくないキャッシュ・エントリをモニター、識別、および削除するプロセスが必要です。

この項では、次のトピックについて説明します:

キャッシュ管理ストラテジの選択

キャッシュ管理ストラテジの選択は、基礎となるデータベースのデータの変更度と、その変更度の原因となる変更の予測可能性に応じて異なります。

また、キャッシュを構成する問合せの数やタイプ、それらの問合せの扱われ方によっても異なります。この項では、キャッシュ管理に対する様々なアプローチの概要を示します。

システムのキャッシュの無効化

システム全体のキャッシュを無効にして、すべての新しいキャッシュ・エントリを停止し、新しい問合せによる既存のキャッシュの使用を停止できます。キャッシュを無効にした場合、キャッシュに格納されているエントリを失うことなく、後で有効にできます。

キャッシュを一時的に無効にすることは、古いキャッシュ・エントリがあることが疑われ、エントリまたはキャッシュ全体をパージする前に実際に古いかどうかを確認する場合に有用なストラテジです。キャッシュに格納されているデータがまだ有用であるとわかった場合、または問題のあるエントリを安全に削除した後は、キャッシュを安全に有効にできます。キャッシュを再度有効にする前に、必要に応じて、キャッシュ全体または特定のビジネス・モデルに関連付けられているキャッシュをパージします。

指定した物理表のキャッシュとキャッシュ永続時間

物理表ごとにキャッシュ可能属性を設定し、将来の問合せを処理するために、その表に対する問合せをキャッシュに追加するかどうかを指定できます。

表のキャッシュ機能を有効化すると、その表に関連する問合せがキャッシュに追加されます。デフォルトでは、すべての表がキャッシュ可能に設定されていますが、適切なキャッシュ永続時間設定を設定しない場合、一部の表はキャッシュに含めることに適していない可能性があります。たとえば、毎分更新される株式相場データを格納する表があるとします。その表のエントリを59秒ごとにパージすることを指定できます。

また、キャッシュ永続時間設定を使用して、その表のエントリを問合せキャッシュに保持する期間を指定できます。これは、頻繁に更新されるデータ・ソースに有用です。

  1. モデル管理ツールの物理レイヤーで、物理表をダブルクリックします。

    セマンティック・モデラーを使用する場合は、次を参照してください 物理表の全般プロパティとは

  2. 「物理表」プロパティ・ダイアログの「一般」タブで、次のいずれかの選択をします:

    • キャッシュを有効にするには、「キャッシュ可能」を選択します。

    • 表がキャッシュされないようにするには、「キャッシュ可能」を選択解除します。

  3. キャッシュの有効期限を設定するには、キャッシュ永続時間を指定し、単位(日数、時間、分または秒)を指定します。キャッシュ・エントリが自動的に期限切れにならないようにする場合、「キャッシュ有効期限なし」を選択します。

  4. 「OK」をクリックします。

セマンティック・モデルの変更による問合せキャッシュへの影響

セマンティック・モデラーまたはモデル管理ツールを使用してセマンティック・モデルを変更すると、変更によってキャッシュに格納されているエントリが影響を受ける可能性があります。たとえば、物理オブジェクトまたは動的セマンティック・モデル変数の定義を変更すると、そのオブジェクトまたは変数を参照するキャッシュ・エントリは有効でなくなる場合があります。これらの変更により、キャッシュをパージする必要が生じる可能性があります。注意すべき2つのシナリオがあります。それは、既存のセマンティック・モデルを変更する場合、および新しいセマンティック・モデルを作成(またはアップロード)する場合です。

セマンティック・モデルに対する変更

セマンティック・モデルを変更したり、別の.rpdファイルをアップロードすると、キャッシュ・エントリに影響を与える変更の場合、変更されたオブジェクトを参照するすべてのキャッシュ・エントリが自動的にパージされます。変更をアップロードすると、パージが行われます。たとえば、セマンティック・モデルから物理表を削除すると、その表を参照するすべてのキャッシュ・エントリは、チェックイン時にパージされます。論理レイヤーのセマンティック・モデルに行われた変更により、そのセマンティック・モデルのすべてのキャッシュ・エントリがパージされます。

グローバル・セマンティック・モデル変数への変更

グローバル・セマンティック・モデル変数の値は、問合せから返されたデータによってリフレッシュされます。グローバル・セマンティック・モデル変数を定義する場合は、初期化ブロックを作成するか、SQL問合せを含む既存の初期化ブロックを使用します。問合せを実行するスケジュールも構成し、定期的に変数の値をリフレッシュします。

グローバル・セマンティック・モデル変数の値が変更された場合、列でこの変数を使用するキャッシュ・エントリは古くなり、そのエントリのデータが再度必要になったときに新しいキャッシュ・エントリが生成されます。古いキャッシュ・エントリはすぐには削除されず、通常のキャッシュ・メカニズムによってクリーンアップされるまで残ります。

キャッシュを使用するためのストラテジ

問合せキャッシュの主な利点の1つは、問合せパフォーマンスの大幅な向上です。

問合せキャッシュは、問合せを実行してその結果をキャッシュすることで営業時間外にキャッシュをシードする場合に有用です。適切なシード・ストラテジでは、どのような場合にキャッシュ・ヒットが起こるかを理解している必要があります。

すべてのユーザーについてキャッシュをシードする場合、次の問合せでキャッシュをシードできます:

SELECT User, SRs

SELECT User, SRsを使用してキャッシュをシードした後、次の問合せはキャッシュ・ヒットです:

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)

この項では、次のトピックについて説明します:

キャッシュ・ヒットについて

キャッシュが有効化されている場合、各問合せが評価されてキャッシュ・ヒットとみなされるかどうかが判断されます。

キャッシュ・ヒットとは、Oracle Analytics Cloudがキャッシュを使用して問合せに返答できるため、データベースでの処理がまったく発生しないことを意味します。Oracle Analytics Cloudは、問合せキャッシュを使用して、同じレベル以上の集計レベルの問合せに返答します。

多くの要因でキャッシュがヒットするかどうかが判断されます。次の表で、これらの要因について説明します。

要因またはルール 説明

SELECTリストの列のサブセットが一致する必要があります

キャッシュ・ヒットとしてみなすには、新しい問合せのSELECTリストにあるすべての列が、キャッシュされた問合せに存在するか、または問合せの列から計算できる必要があります。

このルールは、キャッシュがヒットするための最小要件を示しますが、このルールを満たすことが、キャッシュヒットを保証するものではありません。この表にリストされているその他のルールも適用されます。

SELECTリストの列は、キャッシュされた問合せの列に対する式で構成できます

Oracle Analytics Cloudでは、キャッシュされた結果に対する式を計算して新しい問合せに返答できますが、キャッシュされた結果にすべての列が含まれている必要があります。たとえば、次の問合せでは:

SELECT product, month, averageprice FROM sales WHERE year = 2000

次の問合せでキャッシュがヒットします:

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

averagepriceは、dollarsおよびunitsalesから計算できるからです(averageprice = dollars/unitsales)。

WHERE句は、セマンティックが同じであるか、論理サブセットである必要があります

問合せがキャッシュ・ヒットとみなされるには、WHERE句の制約が、キャッシュされた結果と同等であるか、キャッシュされた結果のサブセットである必要があります。

サブセットが次のいずれかの基準を満たす場合、キャッシュされた問合せの論理サブセットであるWHERE句はキャッシュ・ヒットとみなされます:

  • INリストの値のサブセット。キャッシュされた問合せのINリストの要素より少ない要素を要求する問合せは、キャッシュ・ヒットとみなされます。たとえば、次の問合せをします。

    SELECT employeename, region
    FROM employee, geography
    WHERE region in ('EAST', 'WEST')

    次のキャッシュされた問合せに対するヒットとみなされます:

    SELECT employeename, region
    FROM employee, geography
    WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')
  • キャッシュされた結果より少ない(ただし、同一の)OR制約が含まれます。

  • リテラル比較の論理サブセットが含まれます。たとえば、次の述部では:

    WHERE revenue < 1000

    次の述部を使用する同様の問合せに対するキャッシュ・ヒットとみなされます:

    WHERE revenue < 5000
  • WHERE句がありません。WHERE句のない問合せがキャッシュされている場合、他のすべてのキャッシュ・ヒット・ルールを満たす問合せは、そのWHERE句に関係なく、キャッシュ・ヒットとみなされます。

また、WHERE句に使用される列は、射影リストに含まれている必要があります。たとえば、次の問合せをします。

SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')

REGIONが射影リストにないため、前述のリストのシード問合せのキャッシュ・ヒットになりません。

ディメンションのみの問合せは完全一致である必要があります

ディメンションのみの問合せの場合、つまり、ファクトまたはメジャーが問合せに含まれていない場合、キャッシュされた問合せの射影列の完全一致のみがキャッシュにヒットします。この動作により、1つのディメンション表に対して複数の論理ソースが存在する場合の偽陽性が回避されます。

特別な関数を含む問合せは完全一致である必要があります

時系列関数(AGOTODATEおよびPERIODROLLING)、制限およびオフセット関数(OFFSETおよびFETCH)、関係関数(ISANCESTORISLEAFISROOTおよびISSIBLING)、外部集計関数などの特別な関数を含み、通常メトリックをフィルタする他の問合せも、キャッシュされた問合せの射影列の完全一致である必要があります。このような場合、フィルタも完全一致である必要があります。フィルタ・メトリックについては、フィルタ・メトリックをWHERE句として書き換えることができる場合は、サブセット・キャッシュが利用される可能性があります。

論理表のセットが一致する必要があります

キャッシュ・ヒットとみなされるには、新しい問合せにはすべて、キャッシュ・エントリと同じセットの論理表が存在する必要があります。このルールによって、誤ったキャッシュ・ヒットが回避されます。たとえば、SELECT * FROM productは、SELECT * FROM product, salesに一致しません。

セキュリティ・セッション変数を含む、セッション変数値が一致する必要があります

論理SQLまたは物理SQL文がセッション変数を参照する場合、セッション変数値が一致する必要があります。そうでない場合、キャッシュはヒットしません。

また、セキュリティ・センシティブなセッション変数の値は、論理SQL文自体がセッション変数を参照していなくても、セマンティック・モデルに定義されているセキュリティ・セッション変数値と一致する必要があります。行レベルのデータベース・セキュリティを使用する場合の正しいキャッシュ結果の保証を参照してください。

同等の結合条件

キャッシュ・ヒットとみなされるには、結果として得られる新しい問合せリクエストの結合論理表が、キャッシュされた結果と同じ(またはそのサブセット)である必要があります。

DISTINCT属性が同じである必要があります

キャッシュされた問合せがDISTINCT処理(たとえば、SELECT DISTINCT...)で重複レコードを除去している場合、キャッシュされた列に対するリクエストにもDISTINCT処理が含まれている必要があります。同じ列に対するDISTINCT処理を含まないリクエストは、キャッシュ・ミスになります。

問合せに、互換性のある集計レベルが含まれている必要があります

集計レベルの情報を要求する問合せでは、より低い集計レベルのキャッシュされた結果を使用できます。たとえば、次の問合せは、サプライヤ、地域、および都市レベルで販売された数量を要求します:

SELECT supplier, region, city, qtysold
FROM suppliercity

次の問合せは、都市レベルで販売された数量を要求します:

SELECT city, qtysold
FROM suppliercity

2つ目の問合せは、1つ目の問合せのキャッシュ・ヒットとなります。

限られた追加集計

たとえば、列qtysoldを含む問合せがキャッシュされている場合、RANK(qtysold)のリクエストはキャッシュ・ミスになります。また、国レベルのqtysoldを要求する問合せは、国、地域レベルのqtysoldを要求する問合せからキャッシュ・ヒットを得られます。

ORDER BY句は、選択リストの列で構成されている必要があります

選択リストに含まれていない列で並べ替える問合せは、キャッシュ・ミスになります。

キャッシュ・ヒット動作の診断

キャッシュ・ヒットの動作をより適切に評価するには、次の例に示すようにENABLE_CACHE_DIAGNOSTICSセッション変数を4に設定します:

ENABLE_CACHE_DIAGNOSTICS=4

行レベルのデータベース・セキュリティを使用する場合の正しいキャッシュ結果の保証

仮想プライベート・データベース(VPD)などの行レベルのデータベース・セキュリティ・ストラテジを使用する場合、返されるデータの結果は、ユーザーの認可資格情報に依存します。

このため、Oracle Analytics Cloudは、データ・ソースが行レベルのデータベース・セキュリティを使用しているかどうか、どの変数がセキュリティに関連しているかを認識する必要があります。

セキュリティセンシティブなすべての変数が含まれ、一致するキャッシュ・エントリでのみキャッシュ・ヒットとなるようにするには、モデル管理ツールで次のようにデータベース・オブジェクトおよびセッション変数オブジェクトを正しく構成する必要があります:

  • データベース・オブジェクト。物理レイヤーにおいて、「データベース」ダイアログの「一般」タブで「仮想プライベート・データベース」を選択し、データ・ソースが行レベルのデータベース・セキュリティを使用していることを指定します。

    行レベルのデータベース・セキュリティと共有キャッシュを使用している場合、このオプションを選択して、セキュリティセンシティブな変数が一致しないキャッシュ・エントリが共有されないようにする必要があります

  • セッション変数オブジェクト。セキュリティに関連する変数については、行レベルのデータベース・セキュリティ・ストラテジを使用する場合、「セッション変数」ダイアログで「セキュリティ・センシティブ」を選択し、セキュリティ・センシティブとして識別します。このオプションにより、キャッシュ・エントリがセキュリティセンシティブ変数を含むとマークされ、以降のすべての問合せでセキュリティセンシティブ変数マッチングが有効になります。

一連の問合せの実行によるキャッシュへの移入

キャッシュ・ヒットの可能性を最大化するための1つのストラテジは、一連の問合せを実行してキャッシュにデータを移入することです。

キャッシュをシードするための一連の問合せを作成する際に使用する問合せのタイプに関するいくつかの推奨事項を次に示します。

  • 一般的なビルド済み問合せ。よく実行される問合せ(特に処理にコストがかかる問合せ)は、優れたキャッシュ・シード問合せです。結果がダッシュボードに埋め込まれる問合せは、一般的な問合せの良い例です。

  • 式のないSELECTリスト。SELECTリストの列の式を削除すると、キャッシュ・ヒットの可能性が広がります。式を含むキャッシュされた列は、同じ式を含む新しい問合せにのみ返答できますが、式を含まないキャッシュされた列は、任意の式を含むその列に対するリクエストに応じることができます。たとえば、次のようなキャッシュされたリクエストでは:

    SELECT QUANTITY, REVENUE...
    

    次のような新しい問合せに返答できます:

    SELECT QUANTITY/REVENUE... 
    

    しかし、その逆はありません。

  • WHERE句なし。キャッシュされた結果にWHERE句がない場合は、射影リスト内の列を含むWHERE句を使用する選択リストのキャッシュ・ヒット・ルールを満たす問合せに応じるために使用できます。

一般的に、キャッシュのシードに最も適した問合せは、データベース処理リソースを大量に消費し、再発行される可能性が高い問合せです。多数の行を返す単純な問合せでキャッシュをシードしないように注意してください。このような問合せ(たとえば、PRODUCTSが単一のデータベーステーブルに直接マップされる場合のSELECT * FROM PRODUCTS)に必要なデータベース処理は非常に少ないです。このコストはネットワークとディスクのオーバーヘッドで、これらはキャッシュによって軽減されない要因です。

Oracle Analytics Cloudがセマンティック・モデル変数をリフレッシュする場合、ビジネス・モデルを確認して、セマンティック・モデル変数を参照しているかどうかを判断します。している場合、Oracle Analytics Cloudは、それらのビジネス・モデルに対するすべてのキャッシュをパージします。セマンティック・モデルの変更による問合せキャッシュへの影響を参照してください。

エージェントを使用した問合せキャッシュのシード

Oracle Analytics Cloud問合せキャッシュをシードするようエージェントを構成できます。

キャッシュをシードすると、ユーザーが分析を実行したり、ダッシュボードに埋め込まれている分析を表示した場合のレスポンス時間が向上します。これは、このデータをリフレッシュするリクエストを実行するようエージェントをスケジュールすることで実現できます。

  1. Oracle Analytics Cloudで、クラシック・ホーム・ページを開き、「エージェント」(「作成」セクション)を選択します。
  2. 「一般」タブで、「実行者」オプションに「受信者」を選択します。パーソナライズされたキャッシュ・シードでは、各受信者のデータの可視性を使用して、各受信者のエージェント配信コンテンツをカスタマイズします。
  3. 「スケジュール」タブで、キャッシュをシードするタイミングを指定します。
  4. オプション: 「条件」を選択して、条件リクエストを作成または選択します。たとえば、ETLプロセスを実行するタイミングを決定するビジネス・モデルがあるとします。このビジネス・モデルに基づくレポートを、キャッシュ・シードを開始するための条件付きトリガーとして使用することができます。
  5. 「配信コンテンツ」タブで、キャッシュをシードするための個々のリクエストまたはダッシュボード・ページ全体を選択します。ダッシュボード・ページを選択すると、時間を節約できます。
  6. 「受信者」タブで、個々のユーザーまたはグループを受信者として選択します。
  7. 「送信先」タブで、すべてのユーザー宛先をクリアし、「Oracle Analytics Serverキャッシュ」を選択します。
  8. 右上隅の「保存」ボタンを選択してエージェントを保存します。

キャッシュをシードしているエージェントと他のエージェントとの唯一の違いは、前のキャッシュが自動的に消去され、ダッシュボードにアラートとして表示されないことです。

注:

キャッシュをシードしているエージェントは、完全一致の問合せのみをパージするため、失効データが引き続き存在する可能性があります。エージェント問合せはアドホック問合せまたはドリルに対処していないため、キャッシュ・ストラテジにキャッシュのパージが常に含まれるようにします。

モデル管理ツールを使用した、特定の表のキャッシュの自動パージ

キャッシュをパージすると、問合せキャッシュからエントリが削除され、コンテンツが最新の状態に保たれます。モデル管理ツールで各表に「キャッシュ永続時間」フィールドを設定すると、特定の表のキャッシュ・エントリを自動的にパージできます。

注:

セマンティック・モデラーを使用する場合は、「物理表の全般プロパティとは」を参照してください

これは、頻繁に更新されるデータ・ソースに有用です。たとえば、毎分更新される株式相場データを格納する表の場合、「キャッシュ永続時間」設定を使用して59秒ごとにその表のエントリをパージできます。指定した物理表のキャッシュとキャッシュ永続時間を参照してください。