CData Software Blog

クラウド連携のCData Software の技術ブログです。

PostgreSQLにある既存テーブルへSQLServerのデータを連携してみる:CData Sync

f:id:sennanvolar44:20200114155215p:plain こんにちは、エンジニアの宮本です。

CData Sync を使って「 DB のレコードを別の DB にレプリケートしたい」というお話を、問合せやイベント時などで受けることがあります。
CData Sync は SaaS データ以外にも、DB をデータソースとして扱うことができるため、DB → DB の連携が可能です。

また、CData Sync 最新機能では、レプリケート先テーブルへのマッピングGUI 上で設定することができるため、既存テーブルへ別なデータソースのデータを追加していくことができます。

今回は、既存テーブルへのマッピングを交えながら、SQLServerPostgreSQL への連携を行う方法をご紹介します。

構成

最初のポンチ絵のとおり、SQLServer から PostgreSQL の間に CData Sync が入り、データ連携を行うようになります。
やりたいことは、PostgreSQL に事前にテーブルを用意しておき、SQLServer から PostgreSQL へある特定のカラムのみを連携するジョブを実行します。
f:id:sennanvolar44:20200114162532p:plain

※CData Sync のインストールおよび基本的な操作は、以下の記事を参照いただければと思います。

www.cdatablog.jp

既存テーブルへのレプリケート

レプリケート前のテーブル内容確認

レプリケート前にデータソース、レプリケート先のテーブル定義とレコードを確認してみます。

PostgreSQL のテーブル

PostgreSQL には以下の内容でテーブル&レコードが存在しています。
テーブル名:Customer
f:id:sennanvolar44:20200114172713p:plain

レコード f:id:sennanvolar44:20200114172905p:plain

SQLServer のテーブル

テーブル名:Account
f:id:sennanvolar44:20200114173154p:plain

ID と NAME だけをレプリケートするジョブの作成

SQLServer の ID と NAME 項目のみを連携するジョブを作成してみます。
データソースにSQLServerDestinationPostgreSQL を設定した後、「テーブルを追加」からAccount テーブルを選択します。
f:id:sennanvolar44:20200114174805p:plain

次に自動生成された赤枠のクエリをクリックしてください。
f:id:sennanvolar44:20200114180636p:plain

ここでは、レプリケート先のテーブルを新規作成するか既存テーブルを使うかを選択することができますので、「既存のテーブルにマップ」を選択します。
f:id:sennanvolar44:20200114180857p:plain

既存テーブルとして Customer テーブルを使いますので、選択してOKボタンをクリックします。
f:id:sennanvolar44:20200114181050p:plain

次に「カラムマッピング」タブを選択し、マッピングを行っていきます。データソースと同期先カラムが表示されますが、既存テーブルのカラムとデータソースのカラム全てが含まれて表示されています。
f:id:sennanvolar44:20200114181951p:plain

今回必要なカラムは赤枠部分のみなので、不要カラムは連携しないよう設定します。真ん中の赤枠部分にカーソルを当てると、矢印が表示されている場合はバツ印が表示されますので、バツ印を選択し連携対象から外していきます。 f:id:sennanvolar44:20200114182049p:plain

不要な連携を解除すると以下のように Email だけの連携になってしまいます。 f:id:sennanvolar44:20200114182338p:plain
Id にも SQLServer のカラムを設定するために、カラム名に表示されている「Select...」をクリックし、対象のカラムを選択します。

f:id:sennanvolar44:20200114182746p:plain

これで実行したいクエリが作成できました。
f:id:sennanvolar44:20200114182842p:plain

ジョブ実行

早速実行していきます。チェックボックスにチェックを入れ「実行」ボタンをクリックします。
f:id:sennanvolar44:20200114225647p:plain

正常に完了したメッセージが表示され、5件が連携されたことがわかりました。
f:id:sennanvolar44:20200114225936p:plain

レコードを確認

SQLServer にあった5件のレコードが、PostgreSQL の Customer テーブルの Id と Email だけに連携されているか確認してみます。 f:id:sennanvolar44:20200114232209p:plain 指定した通りのレコードが連携されています。

レプリケート項目を1つ追加

SQLServer で保持している更新日付を連携してみます。設定は以下の赤枠のように対象のカラムを選択するだけです。
f:id:sennanvolar44:20200114233132p:plain

実行すると SQLServer のレコードを再度登録しなおすため、先ほどのジョブの結果に加えて、更新日付が追加された内容が連携されてきます。
f:id:sennanvolar44:20200114233445p:plain

想定通り、更新日付部分だけ連携されています。
f:id:sennanvolar44:20200114233906p:plain

SQLServer は差分更新の対象ではないため、ジョブ実行のたびに全件入れなおす仕様となっております。

データソース側のデータを修正した場合

次に SQLServer のデータを修正した場合、正しく反映されるか確認します。
といっても先ほどお伝えしましたが、ジョブ実行のたびに全件入れ直しているため、修正したレコードも連携されるようになります。

今回は1箇所だけ更新してみました。 f:id:sennanvolar44:20200114234522p:plain

では先ほど作成したジョブを再度実行し、PostgreSQL のテーブルを確認すると、変更したデータが正しく連携されていることが確認できました。
f:id:sennanvolar44:20200114234831p:plain

データソース側のデータを削除した場合

次は削除を確認してみます。まずは先ほど Email を更新したレコードを削除して、SQLServer の件数を4件にしてみます。 その後、ジョブを実行します。
f:id:sennanvolar44:20200115001542p:plain

ジョブを実行すると、4件のレコードが連携されました。
f:id:sennanvolar44:20200115001753p:plain

連携内容を確認するために PostgreSQL を確認してみると、SQLServer 側で削除されたレコードが残ったままでした。 f:id:sennanvolar44:20200115001940p:plain

これは以下のイメージを参考にしてください。レコード2~5は連携されてくるので、上書きされますが、データソース側で削除されたレコードは連携されなくなるので、DB に削除データがそのまま存在し続けてしまうことで起きています。
f:id:sennanvolar44:20200115003533p:plain

テーブルの削除

データソース側と完全に同期したい場合は、オプションで「テーブルを削除」もしくは「テーブルデータの削除」を設定してください。これを選択することによって、ジョブ実行前にレプリケート先のテーブルを削除し、ジョブ実行ごとにテーブルを作成していきます。そのため、レコード自体も最初から登録されていくので削除データは含まれないようになります。
f:id:sennanvolar44:20200115013647p:plain

CheckCache コマンド

カラムがデータソースとレプリケート先で一致する場合は、データを削除することができます。では、以下の SQLServer の Shipments というテーブルをそのまま連携します。
f:id:sennanvolar44:20200115005524p:plain

Shipments というテーブルで PostgreSQL に3件レプリケートされました。
f:id:sennanvolar44:20200115010336p:plain

PostgreSQL の内容 f:id:sennanvolar44:20200115010630p:plain

ここで SQLServer のレコードを1件削除し、2件にしてみました。 f:id:sennanvolar44:20200115010823p:plain

このまま、最初に実行した以下のジョブを実行してしまうと、先ほどと同じように削除データが存在したままになってしまいます。
f:id:sennanvolar44:20200115011100p:plain

そこで、最新の CData Sync では、CheckCache コマンドというものが使えるようになりました。CheckCache はデータソースとレプリケート先の両方を照会し、レプリケート先に過不足があった場合は、データソース側に合わせるような処理を行ってくれます。

構文は以下のようになります。 f:id:sennanvolar44:20200115012021p:plain

では以下のジョブを実行してみます。実行前の時点で SQLServer のレコードは2件、PostgreSQL は3件となります。 f:id:sennanvolar44:20200115012210p:plain

1件の処理を行ったと Status に表示されました。
f:id:sennanvolar44:20200115012413p:plain

PostgreSQL を確認すると確かに SQLServer で削除したレコードが、PostgreSQL でも削除されていることが確認できました。
f:id:sennanvolar44:20200115012924p:plain

最後に

新機能を交えながらの DB から DB への連携をご紹介しました。 CData Sync は30日間の評価版がありますので、SaaS → DB や DB → ファイルなど、色々な組み合わせでお試しください。