増分モード

増分モードは Full キャッシュモードのサブタイプです。このモードが有効な場合、このビューに対するクエリは「増分クエリ」になります。つまり、このビューに対するクエリでは、キャッシュから取得した結果とソースから取得した最新データがマージされます。このモードの主な利点は、前回のキャッシュ更新以降に追加された行と変更された行を取得するだけで、全面的に最新の結果が必ず得られることです。データソースから結果セット全体を取得する必要はありません。

このキャッシュモードには、[Push down query conditions to the data source] オプションがあります。このオプションを使用すると、このビューをヒットするクエリの WHERE 条件がソースに委任されます。これにより、それらのクエリのパフォーマンスが向上する可能性があります。ただし、その結果には、前回のキャッシュ更新以降に変更されたデータは含まれない可能性があります。たとえば、サポートケースのキャッシュデータが存在し、そのステータスを示す列があるとします。特定の行のキャッシュデータの値が open であり、実行されたクエリで status = 'open' のようなフィルターが指定されています。この時点でサポートケースがソース側で更新され、ステータスの値が closed に変更されました。このオプションが有効な場合、条件はソースに委任されるので、更新された行は返されるデータには含まれません。したがって、データはキャッシュから取得されて、古くなった情報が返されます。このオプションは、デフォルトで無効です。

このモードを使用できるようにするには、行が前回挿入または更新された日時を格納するフィールドがビューに必要です。たとえば、ビューに last_modified_date フィールドが存在する場合、 last_modified_date > '@LASTCACHEREFRESH' のような条件を入力します。

このクエリを実行すると、キャッシュをロードするクエリが最後に実行されて正常に完了した日時のタイムスタンプで @LASTCACHEREFRESH 変数が置き換えられます。

このモードは Full モードの変形なので、Partial モードとは異なり、ビューのキャッシュを明示的にロードする必要があります (つまり、キャッシュをロードする適切なパラメーターを指定したクエリを実行する必要があります)。Full モードの場合と同様に、これらのビューのキャッシュをプリロードするには、Denodo Scheduler を使用することが推奨されます。なぜなら、Denodo Scheduler にはキャッシュをプリロードするビューと頻度を選択できるウィザードが用意されているからです。

他のキャッシュモードと同様に、増分モードのビューにキャッシュインデックスを定義できます。キャッシュインデックスを使用すると、キャッシュからのデータ取得を高速化できます。詳細については、「 キャッシュインデックス 」を参照してください。

増分クエリをサポートするためのビューの要件

増分モードをサポートするには、ビューは以下の要件を満たす必要があります。

  1. このオプションは、基本ビューの場合にのみ使用可能です。

  2. 基本ビューにプライマリキーが必要です。

  3. 基本ビューに、行が追加または更新された日時を示す列が 1 つまたは複数必要です。

  4. Virtual DataPort は、各行が追加または更新された日時を示すフィールドに対する条件をソースにプッシュダウンできる 必要があります

    実行時に、クエリで増分モードの基本ビューを使用している場合、実行エンジンはクエリを、それらのフィールドに対する条件とともにデータソースに送信します。次に例を示します。

SELECT *
FROM customer
WHERE last_modified >
    '<latest date when the cache of the view was refreshed>'.

基本ビューでこのタイプの条件をソースにプッシュダウンできない場合、このキャッシュモードには意味がありません。そのため、多くの場合、キャッシュを使用しないか、それとも Full キャッシュを使用するかを選択する必要があります。その理由は、条件をソースにプッシュダウンできない場合、ソースは結果セット全体を返す必要があり、その後、サーバーでフィルターによって結果を除外します。クエリは適切な結果を返しますが、クエリが高速化することも、ソースから取得されるデータの量が減ることもないため、このオプションを使用する意味がありません。

  1. ソースでデータから行を削除することはできません。実行できるのは、行の追加または更新だけです。ソースで行が削除された場合、このビューのキャッシュを無効化して再度キャッシュしない限り、増分クエリは削除された行を返します。多くのシナリオがこの要件を満たしています。なぜなら、行は、実際に削除されるのではなく、削除済みまたは無効とマークされるからです。

実行時に増分クエリが動作する仕組み

増分キャッシュモードのビューに対してクエリを実行する場合、実行エンジンは、以下の 2 つのクエリを実行します。

  1. キャッシュデータベースに対するクエリ

  2. ソースに対する、WHERE 条件が含まれるクエリ。例: last_modified > '<latest date when the cache of the view was refreshed>'

この場合、実行エンジンは、結果を以下のように処理します。

  • ソースとキャッシュが同じ行を返した場合、ソースの行を返します。

  • ソースが行を返し、キャッシュは行を返さない場合、ソースの行を返します。これは、前回のキャッシュプリロードクエリが実行された後にこの行が挿入されたことを意味します。

  • キャッシュが行を返し、ソースは行を返さない場合、キャッシュの行を返します。これは、前回のキャッシュプリロードクエリが実行された後にこの行が更新されていないことを意味します。

    このような理由から、キャッシュデータを無効化して再ロードしない限り、増分モードの基本ビューに対するクエリは、ソースからすでに削除されている行を返します。Virtual DataPort は、クエリを実行しただけでは、前回のキャッシュ更新の後に更新されていない行と、すでに削除されている行を区別できません。

プライマリキーの値が同じ場合、キャッシュからの行とソースからの行は同じであるとみなされます。

増分クエリの使用例 1 (Salesforce)

顧客が開いたサポートケースに関する情報を Salesforce に保存していて、以下の 2 つの Salesforce 基本ビューを作成したとします。

  • sforce_support_case

  • sforce_case_comment

これら 2 つの結合ビューである support_case ビューを作成できます。

Incremental queries - example 1: support\_case view

増分クエリ - 例 1: support_case ビュー

このシナリオでは、派生ビュー support_case に対するクエリを高速化するために、以下のことを実行できます。

  1. 2 つの基本ビュー (派生ビューではありません) のキャッシュモードを、以下の条件を使用して [Full incremental] に設定します。

last_modified_date > '@LASTCACHEREFRESH'
  1. Denodo Scheduler で、サーバーの負荷が低い夜間 (午前 1 時など) に 2 つの基本ビューのキャッシュをプリロードする新しいジョブを定義します。

日中にクライアントアプリケーションが support_case ビューに対してクエリを実行すると、実行トレースは以下のようになります。

Incremental queries - example 1: execution trace of the view support\_case

増分クエリ - 例 1: support_case ビューの実行トレース

この実行トレースは、主結合のすべての分岐が別の結合の結果であることを示しています。これらの他の結合は、以下の 2 つから取得した行を結合した結果です。

  1. ソース (緑の枠): last_modified_date > '@LASTCACHEREFRESH' という条件で Salesforce に対してクエリを実行した結果

  2. キャッシュデータベース (青の枠): キャッシュデータベースに保存されているデータ

このクエリは、はるかに短い時間で完全に最新のデータを返します。

増分クエリの使用例 2 (Google Drive)

この例では、Google Drive アカウントに保存されているドキュメントに関する情報を取得します。そのために、URL https://www.googleapis.com/drive/v2/files に接続する JSON データソースを作成します。

このサービスでは、前回ドキュメントが変更された日時を示すパラメーター modifiedDate を使用して、URL に条件を追加できます。

例:

Incremental queries - example 2: data source configuration

増分クエリ - 例 2: データソースの構成

https://www.googleapis.com/drive/v2/files?maxResults=1000^ExecuteIfIsNotNull("&q=modifiedDate>='",@lastmodified,"'")

補間関数 ExecuteIfIsNotNull は、このデータソースの基本ビューに対してクエリが実行された場合に、補間変数 lastmodified が null ではないときにのみ、URL にパラメーター q=modifiedDate... を追加します。これにより、この変数をオプションにし、ソースからすべてのファイルを取得できるようにします。

このデータソースから基本ビューを作成する際、[Configure JSON Wrapper] ダイアログで [Tuple root] に「 /JSONFile/items 」を入力します。

Incremental queries - example 2: creating the base view

増分クエリ - 例 2: 基本ビューの作成

ビューを作成した後、補間変数 lastmodified に対応するフィールドは必須になっています。初期キャッシュロードを実行する際に値を指定しなくてすむように、これをオプションにする必要があります。フィールドをオプションに変更するには、基本ビューの VQL を取得して、CREATE OR REPLACE TABLE コマンドを変更します。これは現在、次のようになっています。

...
CONSTRAINTS (
         ADD lastmodified (=) OBL ONE
...

これを次のように変更します。

...
CONSTRAINTS (
         ADD lastmodified (=) OPT ONE
...

変更後、この CREATE OR REPLACE TABLE コマンドを VQL シェルから実行します。

次に、ビューのキャッシュを構成します。それには、以下の手順を実行します。

  1. [Options] をクリックします。

  2. キャッシュモードとして [Full] を選択し、[Incremental] チェックボックスをチェックします。

  3. [no condition] ([Incremental] チェックボックスの下) をクリックして、条件「 lastmodified = '@LASTCACHEREFRESH' 」を入力します。

Incremental queries - example 2: configure the cache mode incremental

増分クエリ - 例 2: 増分キャッシュモードの構成

この条件では等号演算子を使用していることに注意してください。これは、補間変数 @LASTCACHREFRESH の値を補間変数 lastmodified に代入するためです。このビューのキャッシュがプリロードされた後に、このビューに対してクエリを実行すると、実行エンジンが呼び出す URL は http://....&q=modifiedDate>=... のようになります。

つまり、 modifiedDate フィールドとの比較は >= 演算子によって実行されます。

  1. VQL シェルから、以下のコマンドを実行します。

増分クエリ - 例 2: 基本ビューのロケールマップの作成
CREATE OR REPLACE MAP i18n rfc_3339_utc (
    'country' = 'US'
    'datepattern' = 'yyyy-MM-dd''T''HH:mm:ss.SSS''Z'''
    'doubledecimalposition' = '2'
    'doubledecimalseparator' = ''
    'doublegroupseparator' = ''
    'language' = 'en'
    'timezone' = 'GMT'
);

このマップの datepattern 属性は、Google API で日付フィールドに使用されるパターンです。このパターンは、次の形式を表しています。

<year>-<month>-<day of the month>T<hour>:<minute>:<second>: <millisecond>'<time zone>'
  1. ビューの [Options] ダイアログに戻って [Search methods] をクリックし、[Default i18n] リストで rfc_3339_utc (前の手順で作成したロケールマップ) を選択します。

    実行時に、実行エンジンが URL をこのソースに送信する際、 @LASTCACHEREFRESH の値 (日付値) を取得して文字列に変換し、この値で URL の @lastmodified を置き換えます。日付値を文字列に変換する際、ビューのロケールマップの日付パターン (この場合は rfc_3339) を使用します。これは、Google Drive API が想定している日付値のパターンです。