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

by 宮本航太 | 2020年01月15日

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

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

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

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

構成

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

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

https://www.cdata.com/jp/blog/2019-12-02-160226

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

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

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

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 項目のみを連携するジョブを作成してみます。
データソースにSQLServer、Destination に PostgreSQL を設定した後、「テーブルを追加」から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 → ファイルなど、色々な組み合わせでお試しください。

関連コンテンツ

トライアル・お問い合わせ

30日間無償トライアルで、CData のリアルタイムデータ連携をフルにお試しいただけます。記事や製品についてのご質問があればお気軽にお問い合わせください。