USER MANUALS

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. 「キャッシュプリロードクエリ」が以下の条件を満たしているか確認します。

    1. データが単一の JDBC データソースから取得される。

    2. キャッシュエンジンが、このデータソースを使用するように構成されている。

    3. クエリ全体が同じデータベースに委任されている。

    4. このデータベースが INSERT INTO SELECT ステートメントをサポートしている。

    上記のすべての条件が満たされている場合、キャッシュエンジンは、 INSERT INTO ... SELECT ... ステートメントを実行し、クエリの結果を直接、データベース内でキャッシュエンジンが使用するスキーマの適切なテーブルに保存します。この場合、このデータはデータベースから Denodo に送信されたり、同じデータベースに返されたりすることはありません。また、Denodo がデータを処理する必要もありません。

    以下の点に留意してください。

    1. 行がキャッシュテーブルに挿入されている間、状態は「処理中」になります。各キャッシュテーブルには、行のステータス (処理中、有効、または無効) を示す列が存在します。

    2. この状態では、クライアントアプリケーション (Administration Tool、Design Studio など) は、キャッシュテーブルに挿入された行を受け取りません。Virtual DataPort もこれらの行を受け取らないからです。Virtual DataPort は、 INSERT INTO <cache table> SELECT... ステートメントを実行し、Denodo を介することなくキャッシュテーブルに直接データを保存します。挿入された行をクライアントアプリケーションで受け取る必要がある場合、クエリの CONTEXT 句にパラメータ 'cache_return_query_results' = 'true' を追加します。このパラメータを使用すると、この最適化が無効になるため、クエリの実行速度が低下します。

  3. 手順 2 の条件が 満たされない 場合、クエリが行を返し始めると同時に、キャッシュエンジンはビューのキャッシュテーブルに行を挿入し始め、状態を「処理中」にします。

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

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

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

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

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

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

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

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

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

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

Add feedback