Version 22.0.8483

• 初期レプリケーション
• 差分レプリケーション
  • 差分チェックカラム
  • 変更データキャプチャ
• 同期間隔（データの整合性）
• 削除キャプチャ
• データ型
  • 既知のデータ型
  • 推論されたデータ型
• 変換
• ヒストリーモード
  • 制限事項
  • ジョブのヒストリーモード有効化
  • ジョブ内のタスクのヒストリーモード有効化
  • ソーステーブルを変更した場合の影響
• API 接続
• In-Network インストール
• スキーマの変更
• お問い合わせ

CData Sync は、あらゆるデータソースをあらゆるデータベースやデータウェアハウスなどにレプリケートするパワフルな機能を提供します。このドキュメントでは、次の機能について簡単に説明します。

• 初期レプリケーション
• 差分レプリケーション
• 同期間隔（データの整合性）
• 削除キャプチャ（データとレコード）
• データ型
• データ変換
• API 接続
• ファイアウォールトラバーサル
• スキーマの変更

初期レプリケーション

初めてジョブを実行すると、Sync はソースの履歴データ全体を処理します。このデータには膨大な量の情報が含まれています。そのため、Sync はいくつかの戦略を用いて、効率、パフォーマンス、整合性を最大化します。またSync には、特定のデータセットに対して同期戦略を最適化するために使用できるユーザー制御のオプションも用意されています。

次のオプションを使用して、Sync が初期レプリケーションを処理する方法を制御できます。（これらのオプションは、ジョブを開いたときに表示されるジョブ設定 カテゴリのAdvanced タブで利用できます。

• レプリケート開始値：Sync はソースの最小日付（つまり、ソースの利用可能な最も古いレコード）から、データのレプリケーションを開始します。API によっては、エンティティの最小日付やint 値をリクエストする方法を提供していないものがあります。最小値を利用できない場合は、次の手順に従って手動で設定できます。

  1. ジョブ設定でテーブルタブをクリックします。次に、タブに表示されたテーブルをクリックして、［タスク設定］モーダルを開きます。

  2. モーダル内のAdvanced タブをクリックします。

  3. レプリケート開始値オプションを見つけます。yyyy-mm-dd またはyyyy-mm-dd hh:mm:ss のいずれかの形式で日付を追加し、手動で最小開始日 / int 値を設定します。

  開始日を指定しない場合、Sync はソースに対してクエリを実行し、1回のリクエストですべてのレコードを取得します。しかしながら、ソーステーブルが非常に大きい場合、この処理によって問題が発生する可能性があります。エラーが発生すると、Sync がクエリをデータの先頭から再実行するためです。

• レプリケート間隔：Sync が最小開始日を決定した後、アプリケーションはデータの終わりに達するまで、指定した間隔で残りのデータを移動します。以下のオプションを使用して間隔を定義します。ジョブ設定ページのAdvanced タブでも利用可能です。

  • レプリケート間隔：このオプションをレプリケート間隔の単位と組み合わせると、データ取得中にデータを分割する時間間隔を設定できます。Sync は、この間隔を使用して更新をバッチ処理し、障害が発生したりレプリケーションが中断された場合に、前回の実行が終了したところから実行を開始できるようにします。デフォルトでは、Sync は180日間隔を使用します。しかし、データ量やどの程度データ間に時間的な間隔を置きたいかによって間隔を調整できます。

  • レプリケート間隔の単位：レプリケート間隔**と組み合わせてこのオプションを使用すると、データ取得中にデータを分割する時間間隔を設定できます。使用できる値は、minutes、hours、days、weeks、months、years です。

差分レプリケーション

初期レプリケーション後、Sync は差分レプリケーションでデータを移動します。Sync は、毎回すべてのデータをクエリする代わりに、最後のジョブ実行時から追加、変更されたデータだけをクエリします。そして、そのデータをデータウェアハウスにマージします。この機能により作業負荷が大幅に軽減し、特に大きなデータセットを扱う場合に帯域幅の使用と同期の遅延が最小限に抑えられます。

多くのクラウドシステムはAPI を使用しており、それらのAPI からデータウェアハウスに完全なデータをプルすることは、多くの場合処理に時間がかかります。また、多くのAPI では1日単位でクオータが設定されており、毎日すべてのデータを取得したくてもできず、毎時や毎15分は不可能です。Sync はデータを差分ごとに移動させることで、遅いAPI や毎日のクオータに対処する際、非常に高い柔軟性を発揮します。

CData Sync は、主に2つの手法（差分チェックカラムと変更データキャプチャ）を使用して差分レプリケーションを取得します。これらの手法について、次のセクションで説明します。

差分チェックカラム

差分チェックカラムは、データを同期する際に新規または変更されたレコードを識別するためにSync が使用する、datetime またはinteger ベースのカラムです。ソースにレコードが追加または更新されるたびに、このカラムの値が増加します。Sync は抽出時にこのカラムを基準として使用し、新規または変更されたレコードのみが返されるようにします。その後、Sync はカラムの新しい最大値を保存し、次のレプリケーションで使用できるようにします。

差分チェックカラムを使用して行われるレプリケーションは、2種類の異なるデータ型を使用して実行できます。

• DateTime 差分チェックカラム：レコードが最後に更新された日時を表すLast Modified またはDate Updated カラム。
• 整数ベースの差分チェックカラム：レコードが追加または更新されるたびに増分する自動インクリメントId または行のバージョンタイプ。

変更データキャプチャ

一部のソースでは変更データキャプチャ（CDC）をサポートしており、ソースはログファイルを使用して、データベースに変更を加えるイベント（挿入、更新、または削除）をログに記録します。Sync は、ソーステーブルに変更をクエリするのではなくログファイルを読み込んで変更イベントを確認します。次に、アプリケーションはレプリケーションのためのそれらの変更を抽出し、次回のレプリケーション用に現在のログを保存します。

以下のソースはCDC 機能に対応しています。

• SQL Server は、Change Tracking またはChange Data Capture のいずれかを使用します。

• Oracle は、Oracle Flashback を使用します。

• PostgreSQL は、Logical Replication を使用します。

• MySQL は、バイナリログを使用します。

同期間隔（データの整合性）

データ統合戦略の一環として、元となるソースと同期先の間で、データの整合性を確保することが重要です。データパイプラインでエラーが発生した場合、またはジョブが中断された場合、データパイプラインプロセスを停止したところから再開する必要があります。この動作により、更新間やエラー発生時にデータが失われないことが保証されます。データ読み込みのための複雑なスクリプトやプロセスを設定することなく、Sync が自動的にそのアクションを処理します。

Sync は同期間隔に従ってデータを処理します。つまり、データをすべて一度に移動するのではなく、データを扱いやすい間隔（またはデータの「チャンク」）に分割して、一度に1間隔ずつ処理します。この機能によって性能が大幅に向上し、エラーの際にもデータの整合性が保たれます。Sync はソーステーブルと同期先テーブルを一致させます。エラーが起きた場合には、Sync は現在の間隔のデータをすべて捨ててその時点から処理を再開できます。

例えば、大規模な同期ジョブの完了間近にエラーが起きたとしましょう。Sync は最初からジョブ全体を開始するのではなく、最後に処理が完了した間隔から再開するので、時間とリソースを節約できます。

Note：API によっては、一定期間内にアクセスできる回数を制限するアクセス制限を設けているものがあります。これらの制限により、エラーが発生することがあります。このようなエラーが発生した場合、Sync は不完全な同期レコードを破棄し、次にスケジュールされたジョブでその時点から再開します。間隔の大きさを設定し、各間隔で取得するデータ量を決定し、エラーが発生した場合に移動する必要があるデータ量を制限することができます。

削除キャプチャ

CData Sync は削除されたレコードを自動でキャプチャして、同期先データの精度を保ちます。Sync はAPI 呼び出しや変更の追跡機能を使用して、削除されたレコードのリストをソースから取得します。

ソースがSync に対して削除されたデータの検出を許可している場合は、高度なジョブオプションで説明するように、削除の挙動オプションを使用してSync による削除の処理方法を制御できます。

• Hard Delete（デフォルトパラメータ）：ソースで削除が検出されると、Sync は同期先のテーブルからそのレコードを削除します。

• Soft Delete：Sync は同期先テーブルに_cdata_deleted カラムを追加します。ソースで削除が検出されると、Sync は同期先の値をtrue に設定します。

• Skip Delete：Sync はソースで削除されたレコードを無視します。

Note： ソーステーブルの情報に記載されているとおり、API によっては削除されたレコードの検出をSync に許可しません。このようなケースでは、削除の挙動は無視されます。

データ型

CData Sync は多くのデータ型を認識し、データ型が厳密に定義できない場合には、データに基づいてデータ型を推論します。Sync は次のデータ型を認識します。

• Boolean
• Date
• Time
• TimeStamp
• Decimal
• Float
• Double
• SmallInt
• Integer
• Long
• Binary
• Varchar
• GUID

既知のデータ型

多くのsources— について、そのほとんどがリレーショナルデータベースで、いくつかはAPI（SQL Server、Oracle など）— ですが、Sync は自動的にスキーマ用のデータ型を検出します。ソースのカラムのデータ型が既知の場合、Sync は自動で一致するデータ型を同期先に作成します。

推論されたデータ型

データ型が指定されていない場合、Sync はカラムのデータ型を決定するためにデータの最初の数行を解析して、データ型を推論できます。

Sync が不明なカラムサイズの文字列型を検出した場合、カラムのデフォルトサイズは2000となります。SQL Server のようなリレーショナルデータベースでは、Sync はこの型用にvarchar(2000) フィールドを作成します。

データ型が厳密に定義されていないフィールドの場合、Sync は最初の行を読み取り、各カラムの最小のデータ型を自動的に選択します。その後、アプリケーションは次の行を読み取り、データが選択したデータ型で格納できるかを確認します。データが収まらない場合、Sync はデータ型のサイズを増やします。Sync は、これを行スキャンの深度（RowScanDepth - 50または100行）まで実行します。これが終了すると、Sync はデータ型を持っています。

例えば、CSV のようなソースでは、Sync はRowScan を使用してファイルの最初の数行を読み取り、動的に各カラムのデータ型を決定します。

変換

データパイプラインにおいて変換は、レポーティングやデータ分析を容易にするためにデータを加工、整形、集計する方法の1つです。Sync はデータパイプラインを作成する際にデータ変換を処理する2つの一般的な手法をサポートしています。

• ETL： ETL（extract（抽出）、transform（変換）、load（ロード））処理は数十年にわたってアナリティクスの伝統的な手法となっています。ETL は、歴史的に市場を席巻してきたリレーショナルデータベースでの使用を想定して考案されました。ETL では、レプリケーション処理の前に変換を行う必要があります。データはデータソースから抽出され、ステージングエリアに格納されます。データは整形、修飾、変換されてデータウェアハウスにロードされます。ETL についての詳細は、In-Flight ETL を参照してください。

• ELT： （extract（抽出）、load（ロード）、transform（変換））処理は、変換などのデータの変更がレプリケーション処理後に行われるデータ抽出の手法です。現代のクラウドデータウェアハウスは膨大なストレージとスケーラビリティを備えているため、データすべてを移動して、その後修正を加えることができます。

  ELT 変換はデータの同期先で実行されるSQL スクリプトです。変換はデータウェアハウスの処理能力を使って、アナリティクスとレポーティング面でのニーズに基づき素早くデータを集計、結合、整形します。データを変換とマッピングで整理することで、パイプラインの移動に合わせてデータを最も役立つ形式で取得できます。ジョブ同様、変換はセミコロン（;）で区切られた複数のクエリをサポートし、スケジュールに従って実行し、変換の完了後にE メール通知が送信されます。ELT についての詳細は、Post-Job ELT を参照してください。

ETL とELT の主な違いは、手順を実行する順序です。

ヒストリーモード

CData Sync のヒストリーモードは、データソース内の履歴データを分析するための方法を提供します。このオプション（アプリケーションのヒストリーモードを有効化）を使用すると、データ行（レコード）の変更履歴を追跡し、データが時間の経過とともにどのように変化するかを確認できます。ヒストリーモードは、差分チェックカラム によるレプリケーションをサポートするすべてのコネクタで利用可能です。

ヒストリーモードはテーブル単位で機能します。そのため、どのテーブルを分析するかを決定し、それらのテーブルに対してのみオプションを有効にできます。

標準（個別設定）モードでは、Sync は既存の行をマージして更新しますが、ヒストリーモードでは、更新された行をデータベースのテーブルに追加します。

ヒストリーモードを有効化すると、

• Sync は、ソースデータベーステーブルの各データレコードに対するデータ変更の完全な履歴を保持します。

• Sync は、それらの変更バージョンを同期先データベーステーブルの対応するテーブルに記録します。

この機能を実現するために、Sync にはソーステーブルに3つの新しいカラムが含まれています。これらのカラムは次のテーブルで定義されています。

カラム名	カラム型	説明
_cdatasync_active	Boolean	レコードがアクティブかどうかを指定します。
_cdatasync_start	Datetime	データレコードがアクティブになった時点の差分チェックカラムのdatetime 値を指定します。この値は、データ更新ごとに増加するタイムスタンプに基づいて、ソーステーブルでレコードが作成または修正された日時を示します。
_cdatasync_end	Datetime	データレコードが非アクティブになった時点の差分チェックカラムのdatetime 値を指定します。このカラムのNull 値は、レコードがアクティブであることを示します。

制限事項

ヒストリーモードでは次の制約が適用されます。

• ソーステーブルは差分チェックカラムをサポートしている必要があります。

• 差分チェックカラムがタイムスタンプであること。

• 差分チェックカラムが疑似カラムではないこと。（疑似カラムはレスポンスに値を持たず、条件としてのみ使用されます。）

• 同期先テーブルは存在できません。（Advanced タブのDrop Table オプションを使用して、ヒストリーモードをアクティブにしてテーブルを再作成します。）

また、ヒストリーモードは次の同期先でのみサポートされています。

• SQL Server

• MySQL

• PostgreSQL

• Oracle DB

• Snowflake

• Databricks

• Redshift

Note：同期先は、今後追加される予定です。

ジョブのヒストリーモード有効化

Sync のジョブに対してヒストリーモードを有効にするには、

1. ジョブタブに移動します。

2. 選択したいテーブルを含むジョブをクリックします。

3. ジョブ設定にスクロールして、テーブルを追加をクリックします。［テーブルを追加］モーダルが開いたら、テーブルを選択します。

4. Add Selected Tables をクリックして選択したテーブルを追加し、ジョブ設定ページに戻ります。

5. Advanced タブをクリックして高度な設定を開きます。

6. レプリケートオプションにスクロールしてヒストリーモードを有効化を選択します。

7. ジョブ設定ページの右上にある変更を保存をクリックして、選択したテーブルのヒストリーモードを保存し、有効にします。

ジョブ内のタスクのヒストリーモード有効化

以下に示すように、タスク設定のAdvanced タブから、タスクのヒストリーモードを有効にすることもできます。

タスクの高度な設定では、ヒストリーモードには3つのオプションがあります。

• ジョブから継承：このオプションを指定すると、タスクはジョブからヒストリーモードを継承します。

• True：このオプションは、タスクのヒストリーモードを有効にします。

• False：このオプションはタスクのヒストリーモードを無効にします。

テーブルが差分チェックカラムをサポートしていない場合も、タスク設定でヒストリーモードが無効になります。

ソーステーブルを変更した場合の影響

行を挿入、更新、削除してソーステーブルを変更すると、次の表で説明するように、同期先はさまざまな形で影響を受けます。

ソースの変更	同期先の影響
挿入された行	同期先テーブルに行が追加されます。_cdatasync_active はTrue に設定され、_cdatasync_start は差分チェックカラムの値に設定されます。
更新された行	同期先の現在の行が更新されます。_cdatasync_active はFalse に設定され、_cdatasync_end は差分チェックカラムの値に設定されます。 同期先テーブルに新しい行が挿入されます。_cdatasync_active はTrue に設定され、_cdatasync_start は差分チェックカラムの値に設定されます。
削除された行	同期先の現在の行が更新されます。_cdatasync_active はFalse に設定されます。

API 接続

Sync にはビルトインのREST（representational state transfer） API が含まれており、アプリケーションの柔軟な管理を実現します。管理コンソールのUI で実現できることはすべて、RESTful API コールで実現できます。

REST API は以下のもので構成されています。

• ジョブ管理API は、ジョブを作成、更新、および実行できます。

• 接続管理API は、接続をリスト、作成、編集、削除、およびテストできます。

• ユーザー管理API は、ユーザーを編集しすべてのユーザーをリストできます。

API 接続についての詳細は、REST-API も参照してください。

In-Network インストール

Sync はどこでも実行できるため、クラウド上にあるシステムと社内ネットワーク上にあるシステムを持つユーザーにとって最適なアプリケーションです。Sync をインストールしてネットワーク内で実行できるため、インターネットや開いたファイアウォール経由でポートが公開されたり、VPN 接続を作成したりすることを回避できます。

また、Sync アプリケーションをどこでも実行できることで、遅延を大幅に削減することができます。ソースや同期先の近くでSync を実行できるため、ETL やELT ジョブのパフォーマンスが向上します。

スキーマの変更

データは常に変化していますが、Sync はそれらの変化を常に正確に表すことを保証します。毎実行時、Sync はソースのスキーマと同期先のスキーマを比較して差分を検出します。Sync が2つのスキーマ間で構造の違いを検出した場合、アプリケーションは同期先のスキーマを変更し、以下で説明するようにソースのデータを格納できるようにします。

• ソーステーブルに同期先テーブルに存在しないカラムが含まれている場合、Sync はカラムを追加することで同期先テーブルを変更します。

• ソーステーブルのデータ型のサイズが増える場合、Sync はカラムのサイズを更新することで同期先テーブルを変更します。Sync は、文字列カラムのカラムサイズを増やしたり（例：varchar(255) -> varchar(2000)）、非文字列カラムのバイトサイズを増やす（例：smallint -> integer）、といった変更を行います。

Notes：

• Sync は、カラムがソーステーブルから削除されている場合でも、同期先テーブルからはカラムを削除しません。

• Sync は、ソースでデータ型のサイズが更新された場合でも（varchar(2000) -> varchar(255)）、同期先カラムのサイズは小さくしません。

お問い合わせ

ご質問ご意見がございましたら、こちら までご連絡ください。