Full モード

ビューで Full キャッシュモードを使用している場合、そのビューのデータは常に、ソースからではなく、キャッシュデータベースから取得されます。

Partial キャッシュと比較した場合、このモードには、複数の (さらには複数のデータソースからの) ビューを使用する複雑な操作 (結合、和結合、グループ化など) をキャッシュデータベースに委任できるため、これらの操作のパフォーマンスが大幅に向上するという大きな利点があります。

このキャッシュモードでは、特別なクエリ (「キャッシュプリロードクエリ」) を実行して、ビューのキャッシュを充てんする必要があります。このクエリの結果がキャッシュに挿入され、このビューに対するクエリはそのデータに基づいて実行されます。

キャッシュプリロードクエリは、 CONTEXT 句でパラメーター 'cache_preload' = 'true' を指定している通常のクエリです。次に例を示します。

SELECT *
FROM internet_inc
CONTEXT (
      'cache_preload' = 'true'
    , 'cache_invalidate' = 'all_rows'
    , 'cache_wait_for_load' = 'true'
    , 'cache_return_query_results' = 'false')

キャッシュプリロードクエリは、以下の条件を満たす必要があります。

  1. ビューのすべてのフィールドを投影する必要があります (つまり SELECT * FROM ...)。

  2. 集計句または集計関数は使用できません。つまり、 GROUP BY または HAVING は禁止されています。選択条件 (WHERE 句) は使用できます。

  3. WHERE 句ではサブクエリを使用できません。

  4. Full キャッシュモードが有効なビューに対して実行する必要があります。その基盤となるビューまたはその派生ビューに対してではありません。

キャッシュプリロードクエリは、定期的に実行する必要があります。それには、Denodo Scheduler を使用することが推奨されます。なぜなら、Denodo Scheduler には、キャッシュをプリロードするビューと頻度を選択し、クエリで使用するパラメーターを選択できるウィザードが用意されているからです。

以降のセクションでは、「Full」キャッシュのビューのキャッシュをプリロードする 2 つの方法について説明します。

  1. 既存のデータを無効化してキャッシュをロードする。これは、キャッシュをプリロードする最も一般的な方法です。 以下 を参照してください。

  2. キャッシュを増分ロードする。「 キャッシュを増分ロードする 」を参照してください。

既存のデータを無効化してキャッシュをロードする

クエリの CONTEXT 句でパラメーター ('cache_preload' = 'true',  'cache_invalidate' = 'all_rows') を指定している場合、キャッシュエンジンはクエリ対象のビューのキャッシュデータをすべて無効とマークしてから、クエリの結果をキャッシュデータベースに保存します。

たとえば、次のクエリは、キャッシュされている customer ビューの行をすべて無効化してから、クエリの結果をキャッシュします。

SELECT *
FROM customer
CONTEXT (
  'cache_preload' = 'true'
, 'cache_invalidate' = 'all_rows'
, 'cache_wait_for_load' = 'true'
, 'cache_return_query_results' = 'false')

キャッシュを増分ロードする

シナリオによっては、ビューで Full キャッシュモードを使用している場合、そのビューのキャッシュをロードするには複数のクエリを実行しなければならないことがあります。なぜなら、たとえば 1 つのクエリでキャッシュをロードすると、ソースに過剰に負荷がかかる場合があるからです。このシナリオでは、パラメーター 'cache_invalidate' = 'all_rows' を使用するとビューのキャッシュがすべて無効化されるため、このパラメーターは使用できません。

Virtual DataPort には、 'cache_invalidate' = 'all_rows' の代わりとして以下の 2 つの方法が用意されています。

  1. パラメーター ('cache_preload' = 'true', 'cache_invalidate' = 'matching_rows') を追加する。つまり、キャッシュエンジンは、キャッシュされた行の中でクエリの WHERE 句に一致するものを無効化してから、クエリの結果をキャッシュします。これらのパラメーターをクエリに追加することは、ビューの [Execute] ダイアログからビューを実行して、[Store results in cache] と [Invalidate existing results] の各チェックボックスをチェックすることに相当します。

    たとえば、 order というテーブルがあり、そのキャッシュモードが Full である場合に、このビューのキャッシュデータを更新して今年の最新レコードをキャッシュする必要があるとします。ただし、昨年以前のキャッシュデータは無効化したくありません。なぜなら、それらは変更されていない上に、すべてのデータを再取得するのは時間がかかりすぎるからです。これを実現するには、次のクエリを使用します。このクエリは日付が今年である注文のみを返します。また、パラメーター 'cache_invalidate' = 'matching_rows' を指定しているので、キャッシュエンジンはクエリの条件に一致する行のみを無効化して、ソースから取得したデータをキャッシュします。

    SELECT *
    FROM order
    WHERE order_date >= TRUNC( CURRENT_DATE(), 'Y')
    CONTEXT (
    'cache_preload' = 'true'
    , 'cache_invalidate' = 'matching_rows'
    , 'cache_wait_for_load' = 'true'
    , 'cache_return_query_results' = 'false')
    
  2. クエリの CONTEXT 句にパラメーター ('cache_preload' = 'true') を追加する ('cache_invalidate' は追加しない)。現在のキャッシュデータを無効化することなく、クエリの結果をキャッシュデータベースに保存します。このパラメーターを使用して複数のクエリを実行することによって、キャッシュを増分ロードできます。

    このパラメーターを追加することは、ビューの [Execute] ダイアログからビューを実行して、[Store results in cache] チェックボックスをチェックし、[Invalidate existing results] チェックボックスのチェックをはずすことに相当します。これを実行する場合、キャッシュを増分ロードするために使用するクエリの結果が重複しないことを確認する必要があります。たとえば、次のクエリを実行したとします。

    SELECT *
    FROM phone_inc
    WHERE pinc_id > 0
    CONTEXT (
    'cache_preload' = 'true'
    , 'cache_wait_for_load' = 'true'
    , 'cache_return_query_results' = 'false')
    

    さらに次のクエリを実行します。

    SELECT *
    FROM phone_inc
    WHERE pinc_id > -1
    CONTEXT (
    'cache_preload' = 'true'
    , 'cache_wait_for_load' = 'true'
    , 'cache_return_query_results' = 'false')
    

キャッシュには、両方のクエリから返されたデータが保存されます。ここで SELECT * FROM phone_inc というクエリを実行した場合、結果は両方のクエリの和結合になり、その中には同じ行が 2 回含まれることになります。

実行時の Full キャッシュモード

Full キャッシュが有効なビューに対してクエリを実行すると、キャッシュプリロードクエリが実行されていなくても、データは常にキャッシュから取得されます。ビューのキャッシュがプリロードされていない場合、このビューに対するクエリでは 0 行が返されます。

パフォーマンスの観点から見ると、Full キャッシュモードを使用する主な利点は、Full キャッシュが有効な 2 つのビューを結合する場合にクエリがキャッシュに委任されることです。これにより実行時間が短縮される場合があります。Partial キャッシュモードを使用する場合、このような最適化は利用できません。

たとえば、異なるデータソースからデータを取得する 2 つのビューで Full キャッシュモードを有効にして、それらの間で結合を実行した場合、結合はサーバーで実行されるのではなく、キャッシュデータベースに委任されます。

重要

このキャッシュモードが有効な場合、キャッシュエンジンはキャッシュプリロードクエリを確認 しません 。たとえば、次のクエリでビューがロードされたとします。

SELECT *
FROM employee WHERE id = 1
CONTEXT ('cache_preload' = 'true', 'cache_invalidate' = 'all_rows')

その後、次のクエリを実行します。

SELECT *
FROM employee

この場合、データはキャッシュから取得されます。つまり、 id = 1 という条件に一致する行のみが取得されます。


クエリでパラメーター 'cache_preload' = 'true' が指定されている場合、キャッシュエンジンは以下の処理を実行します。

  1. このビューのキャッシュデータを保存する予定のテーブルが存在することを確認します。さらに、そのテーブルに適切なスキーマが存在することも確認します。このテーブルは、Full キャッシュモードまたは Partial キャッシュモードを有効にしたときに作成されます。

  2. クエリが行を返し始めると同時に、ビューのキャッシュテーブルに行を挿入し始め、状態を「処理中」にします。各キャッシュテーブルには、行のステータス (処理中、有効、または無効) を示す列が存在します。

  3. キャッシュテーブルにすべての行を挿入し終わると、キャッシュデータベースに対するトランザクションを開始します。このトランザクションで、キャッシュエンジンは、1 つまたは 2 つのクエリを次の順序で実行します。

    1. クエリでパラメーター 'cache_invalidate' が指定されている場合、UPDATE ステートメントを実行して行のステータスを「有効」から「無効」に変更します。

      クエリで 'cache_invalidate' = 'all_rows' が指定されている場合、すべての「有効」な行のステータスは「無効」に切り替わります。

      クエリで 'cache_invalidate' = 'matching_rows' が指定されている場合、クエリの WHERE 条件に一致する「有効」な行のステータスは「無効」に切り替わります。クエリに WHERE 句が存在しない場合、 matching_rowsall_rows と等価です。

    2. 「処理中」の行を「有効」に変更する UPDATE ステートメントを実行します。

  4. トランザクションをコミットします。この後にこのビューをヒットするクエリは、この新しいデータを取得します。

このプロセスにより、Full キャッシュモードを使用するビューをヒットしたクエリは、ビューのキャッシュのロード中に別のクエリがビューをヒットした場合でも、確実に有効なデータを返すようになります。

データをキャッシュテーブルに挿入している間にクエリがビューをヒットした場合、返されるデータは有効です。なぜなら、キャッシュエンジンは常にステータスが「有効」な行を返すからです。それまでに挿入された行のステータスは「処理中」であり、「有効」ではありません。

行のステータスが「処理中」から「有効」に切り替わる間にクエリがビューをヒットした場合、返されるデータは有効です。なぜなら、この UPDATE はトランザクション内で実行されるからです。したがって、このクエリは依然として「古い」行を返しますが、部分的に変更された行を返すことはありません。

cache_wait_for_loadfalse であるか、または存在しない場合、結果のすべての行がクライアントに返されると、たとえデータが完全にはキャッシュデータベースに挿入されていなくても、すぐにクライアントはクエリ完了通知を受け取ります。 cache_wait_for_loadtrue である場合は、上記のすべての手順が完了した後にクエリ完了通知を受け取ります。