incremental loadingを使用する場合、フルテーブルスキャンを回避するために、カラムにインデックスを作成する必要があるかどうかを判断する必要があります。例えば、次のようなインデックスを作成できます:
CREATE INDEX embulk_incremental_loading_index ON TABLE (updated_at, id);場合によっては、incremental_columnsを未設定のままにして、integrationが自動的にAUTO_INCREMENT primary keyを見つけるようにすることが推奨されます。
incremental loadingが選択されていない場合、integrationは最後に更新された時期に関係なく、指定されたintegration objectタイプのすべてのレコードを取得します。このモードは、'replace'モードを使用してdestination tableにデータを書き込む場合に最適です。
一部のintegrationsでincremental loadingを使用する場合、次の動作が発生します:
incremental_columns: [updated_at, id]オプションが設定されている場合、クエリは次のようになります:
SELECT *FROM (...original query IS here...)ORDER BY updated_at, idbulk data loadingが正常に終了すると、次回の実行で使用できるようにlast_record: parameterをconfig-diffとして出力します。 次回の実行時、last_record:も設定されている場合、最後のレコードより大きいレコードをロードするための追加のWHERE句を生成します。例えば、last_record: ["2017-01-01T00:32:12.000000", 5291]が設定されている場合:
SELECT *FROM (...original query IS here...)WHERE updated_at > '2017-01-01T00:32:12.000000' OR (updated_at = '2017-01-01T00:32:12.000000' AND id > 5291) ORDER BY updated_at, idその後、次回の実行で更新されたlast_recordを使用できるようにlast_record:を更新します。
他のintegrationsの場合、次の動作が発生します:
SELECT ...FROM `target_table`WHERE ((`col1` > ?))bind variable(上記のクエリの?リテラル)には、前回実行時の最大値が含まれます。より大きい値が、対象カラム(col1)との差分として認識されます。