CData Sync 高速差分レプリケーションの仕組み

Oracle ACE Proの渡部です。この記事は、 JPOUG Advent Calendar 2024 の10日目の記事です。 CData Software Advent Calendar 2024 の10日目の記事でもあります。

弊社コーソルは、2024年11月から Change Data Capture技術を用いた論理レプリケーションに対応したデータ連携ツール CData Sync の販売を開始しました。

この記事では、CData Sync を検証する中で見つけた特徴と、その技術的な側面について書きたいと思います。そして、これと併せて、12月17日開催予定のオンラインセミナーについてもご紹介させていただきます。

CData Syncの特徴

多数のデータストア、SaaS間のデータレプリケーションに対応
- 同期元: 400種以上のデータストア、SaaSなどに対応
- 同期先: 30種程度のデータストアに対応
差分レプリケーションに対応
- CDC: Oracle, MSSQL, MySQL, PostgreSQL, MariaDB
- クエリベース (差分チェックカラムを用いた差分レプリケーション)
WebベースGUIで簡単設定
オンプレミス環境およびクラウド環境に対応
- インストール版(Java)
- AWS, Azure: Marketplace従量課金

なお、12月17日開催予定の共催セミナーでは、上記の特徴から、いくつかの点を掘り下げて話したいと思っています。

大量データの差分レプリケーションが高速！

12月17日開催予定の共催セミナーでは、数値的なモノも少し交えながら話そうと思っているのですが、CData Sync を検証して驚いたのは「大量データの差分レプリケーションが高速！」という点です。

これまでもいくつかの論理レプリケーション製品の性能を検証してきましたが、CData Sync の高速さはなかなか凄いです。

エンジニアとしては、驚いているだけではなく、その"高速さ"をもたらしているその技術的な側面を抑えておかないといけません。ということで、SQLトレースを取るなどして色々調べてみましたので、以降ではそれについて書きたいと思います。

なお、以降の説明では、Oracle → Oracle レプリケーション構成を題材とします。また、LogMinerを用いることを前提とします。

（一応の補足: CData Sync は Oracle → Oracle以外のレプリケーション構成にも対応しています。異機種RDBMS間のレプリケーション構成にも対応しています。）

初回ジョブ実行と2回目以降のジョブ実行

CData Sync のレプリケーションに関わる論理アーキテクチャは以下のとおりです。

タスクで、ソース表とターゲット表のレプリケーションを定義します。
ジョブには複数のタスクが含まれます。
ジョブは内蔵スケジューラでスケジュール実行（定期繰り返し実行）が可能です。

CDCタイプのジョブは、LogMinerなどの機能を用いて、ソースDBMSから変更内容を取得し、差分レプリケーションを実現します。

CDCタイプのジョブは、初回と2回目以降で処理内容が異なります。

初回は全件レプリケーション
2回目以降は、差分レプリケーション

初回ジョブ実行の仕組み

初回ジョブ実行におけるデータ処理の仕組みは比較的シンプルで以下のようになっています。

JDBCバッチ更新を用いて、複数行を一括でINSERTします。
別名の表にINSERTし、INSERTが完了したらリネームして、意図したターゲット表の名前にします。

これにより、全件レプリケーションを実現しています。

初回ジョブ実行におけるポイントは、JDBCバッチ更新を用いて複数行を一括でINSERTしている点なのですが、この機能は2回目以降ジョブ実行でも使用しているため、そこで説明します。

なお、スライドにも記載していますが、この記事で記載した内部処理は、コーソル渡部の調査に基づくものであり、CData Syncの仕様として公開されているものではありません。条件によって異なる振る舞いをする可能性があります。また、今後変更される可能性もありますので、ご注意ください。

2回目以降ジョブ実行の仕組み

2回目以降のジョブ実行におけるデータ処理の仕組みは以下のようになっています。

OracleのLogMiner機能を用いて、前回ジョブ以降にソース表に対して実行された変更処理を取得します。
JDBCバッチ更新を用いて、複数行を一括で一時表（グローバル一時表）にINSERTします。
一時表へのINSERTが完了したら、MERGE文を用いてターゲット表に対するUPSERT処理を実行します。MERGE文には /*+ APPEND */ヒントを付与して、ダイレクトパス処理を試みます。

これにより、差分レプリケーションを実現しています。

JDBCバッチ更新

JDBCバッチ更新は、同一DMLの複数回実行をまとめることができる機能です。複数回実行を1つにまとめることで、アプリケーション～DBサーバのネットワークラウンドトリップの回数を減らして、パフォーマンスの向上を図ることができます。

初回および2回目以降のジョブ実行では、JDBCバッチ更新を用いて複数行のINSERT処理を高速化しています。

該当処理のSQLトレース(tkprof加工済み)を以下に示します。

INSERT INTO "U1"."U1_T1__r_200468282" ("_cdatasync_deleted", "PK", "S") VALUES  (:1 , :2 , :3 )

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     43      1.05       1.10          0      13089     129402       42086
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       44      1.05       1.10          0      13089     129402       42086

: 

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  LOAD TABLE CONVENTIONAL  U1_T1__r_200468282 (cr=988 pr=0 pw=0 time=31886 us starts=1)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net more data from client               10343        0.00          0.09
  Disk file operations I/O                        1        0.00          0.00
  log file sync                                   1        0.02          0.02
  SQL*Net message to client                      43        0.00          0.00
  SQL*Net message from client                    43        0.43          3.58

以下が分かります。

行数(Execute -> rows = 42086) に比べて、実行回数(Execute -> count = 43) 少ないです。バッチ更新が行われていることが分かります。
実行計画のオペレーションが "LOAD TABLE CONVENTIONAL"です。バッチ更新を用いたINSERTが実行されていることが分かります。

一時表（グローバル一時表）

JDBCバッチ更新でデータがINSERTされるのは一時表（グローバル一時表）です。ターゲット表を直接更新するのではなく、まず一時表にデータがINSERTしてから、データをターゲット表に反映する動きとなります。

一時表はデータを一時的に保持するための特殊な表です。 REDOを生成しないので高速に処理できます。また、データの保持期間は一時的なのですが、通常の表と同じようなデータ処理が可能です。 CData Syncはこの利点を生かして、一時表 → 永続表のダイレクトパスロードを実行しています。

MERGE /+ APPEND / でUPSERT

一時表へのINSERTが完了したら、MERGE文を用いてターゲット表に対するUPSERT処理を実行します。MERGE文には /*+ APPEND */ヒントを付与して、ダイレクトパス処理を試みます。

UPSERT処理とは、

既存の行があれば、UPDATE
既存の行がなければ、INSERT

する処理の通称です。UPSERT処理により、いわゆる「差分更新」を実現できます。 OracleではMERGE文でUPSERT処理を実行できます。

また、MERGE文に /*+ APPEND */ヒントを付与しているため、可能な場合は、ダイレクトパス処理で実行されます。具体的には、既存の行がないと、INSERTがダイレクトパス処理で実行されます。

ご存じの方も多いかと思いますが、DMLにおいて、ダイレクトパス処理の高速化効果は"絶大"です。この記事で、具体的数値とともにその効果の大きさを書きたいところですが… 俗にいう"ベンチマーク条項(DeWitt条項)"があるため、具体的な数値を書くことを躊躇してしまいます（他社製品との性能比較を嫌う条項だと思うので、オラクルさんから怒られることはないとは思うのですが、一応・・・）。

ここでは、「ダイレクトパス処理と通常の処理（非ダイレクトパス処理）で10倍以上の差があった」という記載にとどめておきます。

12月17日開催予定のオンラインセミナーでは、もう少し具体的な数値をこっそり（というものでもないですが）お話ししたいと思っています。お時間に都合がつけば、是非ご参加くださいませ。

雑感 - CData Syncの思い切りの良さ

大量データの差分レプリケーションの高速さを実現している技術的な側面を理解したとき、私はいくつかの感想を抱きました。雑感気味でまとまりがないですが、書いておきます。

CData Syncは ETL/ELT寄りの製品であるのだから、データ処理をBulk的に実装するのは当たり前と言えば当たり前
その裏返しだが、CData Syncは「ソースDBのトランザクション実行をターゲットDBで再現する」ことは目標にしていない。
ダイレクトパス処理の実行中は、ターゲット表の排他ロックが取得される。よって、実行中に他の更新処理は待たされることに注意が必要。

私がこれまで触ってきた論理レプリケーション製品は、「ソースDBのトランザクション実行をターゲットDBで再現する」ことを目標にしている印象があります。この感覚からすると、CData Syncの思い切りの良さは新鮮でした。

[宣伝] 12月17日にオンラインセミナーを開催します！

12月17日にCData社様と共催でオンラインセミナーを開催します。本記事で触れた性能関係を含めたいくつかのCData Syncの長所についてお話ししますので、お時間に都合がつけば、是非ご参加くださいませ。

開催日時: 2024年12月17日(火) 14:00～15:00
場所 : Zoomによるオンラインウェビナー形式
URL : https://us02web.zoom.us/webinar/register/WN_v-XQ7jXlSnWhKtQHk6GMpw#/registration

セッション構成

ノーコードで始めるETL / ELT パイプラインCData Sync の特徴とSaaS・RDB 連携導入事例の紹介 - CData Software Japan 合同会社セールスマネージャー小島一剛
Oracle ACE Pro が語るCData Sync の特色と長所 - 株式会社コーソル技術統括 Oracle ACE Pro 渡部亮太
コーソルのCData Sync 関連サービスの紹介 - 株式会社コーソル技術統括 Oracle ACE Pro 渡部亮太