機械翻訳について

問合せキャッシュの管理

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

トピック:

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

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

キャッシングの利点

問合せを最も速く処理する方法は、大部分の処理をスキップして、あらかじめ計算された答えを使用する方法です。

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

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

キャッシュを使用して問合せに回答する別の利点は、特に問合せ結果が複数のデータベースから取得される場合に、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がプロジェクション・リストにないため、前のリストのシード中の問合せに対してキャッシュ・ヒットになりません。

ディメンションのみの問合せが完全一致している

問合せがディメンションのみで、問合せにファクトやメジャーが含まれない場合、キャッシュされた問合せの投影列が完全一致する場合のみ、キャッシュはヒットします。 これにより、ディメンション表の論理ソースが複数ある場合の誤検出が回避されます。

特殊関数を使用する問合せが完全一致している

時系列関数(AGO、TODATEおよびPERIODROLLING)、極限関数およびオフセット関数(OFFSETおよびFETCH)、関係関数(ISANCESTOR、ISLEAF、ISROOTおよび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番目の問合せは、最初の問合せのキャッシュ・ヒットになります。

追加の集計の制限

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

ORDER BY句がSELECTリスト内の列で構成されている

SELECTリストに含まれていない列でソートする問合せは、キャッシュ・ミスになります。

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

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

ENABLE_CACHE_DIAGNOSTICS=4
行レベルのデータベース・セキュリティを使用している場合の適切なキャッシュ結果の確認

仮想プライベート・データベース(VPD)のような行レベルのデータベース・セキュリティ方針を使用している場合、返されるデータ結果は、ユーザーの認可資格証明で決まります。

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

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

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

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

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

キャッシュを移入するための一連の問合せの実行

キャッシュ・ヒットの可能性を最大限に高める1つの方法は、一連の問合せを実行してキャッシュを移入することです。

キャッシュをシードする一連の問合せを作成するときに使用する問合せの種類に関して、いくつかの推奨事項があります。

  • 共通の事前作成問合せ。 よく実行される問合せや、処理に多くのリソースが必要な問合せは特に、優れたキャッシュ・シード問合せです。 その結果がダッシュボードに埋め込まれる問合せは、共通問合せのよい例です。

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

    SELECT QUANTITY, REVENUE...

    これは、次のような新しい問合せに答えを返すことができます。

    SELECT QUANTITY/REVENUE...

    ただし、逆は成り立ちません。

  • WHERE句の不使用。 キャッシュされた結果にWHERE句がない場合、これを使用して、プロジェクション・リストの列が含まれるSELECTリストとWHERE句のキャッシュ・ヒット・ルールを満たす問合せに、答えを返すことができます。

一般に、キャッシュのシードに最適な問合せは、データベースの処理リソースを大量に使用し、再実行される可能性がある問合せです。 多くの行を返す単純な問合せでキャッシュをシードしないように注意してください。 このような問合せでは(たとえば、SELECT * FROM PRODUCTS。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秒ごとにその表のエントリをパージできます。 「指定した物理表のキャッシュおよびキャッシュ永続性のタイミング」を参照してください。