こんにちは、プロダクトマネージメント@for Apps の宮本です！
CData Sync V24.3 で追加された「拡張型CDC機能」は、レプリケーション全体のパフォーマンスを大幅に向上させます。そこで、実際にどれほど改善されたのかを確認するため、従来の「CDC機能」と比較し、レプリケーション時間にどれくらいの差があるのかを検証してみました。
結論からお伝えすると、従来の CDC に比べて 拡張型CDC はレプリケーション完了時間を 1/9 に短縮 できました。この記事では、検証の詳細やレプリケーション方式について解説していきますので、ぜひ最後までご覧ください。
拡張型CDC とは
拡張型CDC はデータソースとなるデータベースから変更データをリアルタイムにキャプチャできる機能です。リアルタイムにキャプチャしたデータは、一度CData Sync のステージエリアにファイルとして保存されます。
構成などは以下の記事で解説していますので良かったら参照して見てください。
「拡張型CDC 機能」が登場！CData Sync でリアルタイムデータストリーミングを実現（PostgreSQL 編）
ちなみに従来のCDC については以下をご参照ください。
Change Data Capture（CDC）とは？CDC の基本からCData Sync のCDC 機能まで詳しく解説
パフォーマンス向上したポイント
まず前提として、従来のCDC も拡張型CDCも、変更データの取得元はトランザクションログで変わりません。
従来のCDC 機能では、スケジュールされた時間になるとデータソースへアクセスします。このとき、実行中ジョブでの対象テーブルでしか更新がなければ、ただその変更データを取得するだけですが、他のテーブルで大量の更新がある場合、それらの変更分をスキップしなければなりません。
以下の図では、オレンジの線の位置まで戻り、Table-Bの変更データをスキップしてから、Table-A（図の右端）の変更データを取得する流れになります。
しかし、拡張型CDC ではトランザクションログを読み続け、読み込み位置（オレンジの線）をどんどん前に進めていきます。もし他テーブルの変更データがあっても常に読み飛ばしていくので、取得すべき変更データへたどり着くまでの時間が短くなります。
パフォーマンス比較
それではデータソースはPostgreSQL、同期先にSQL Server という構成でパフォーマンス比較を行ってみます。
比較方法は従来のCDC と拡張型CDC で片方ずつ以下を実施します。
- レプリケーション対象の「テーブルA」を作成
- 「テーブルA」に50件追加
- 「テーブルA」の初回ジョブ実施（レプリケーション件数：50件）
- 「テーブルB」作成
- 「テーブルB」に100万件追加
- 「テーブルA」に1万件追加
- ３番から10分後の時間に「テーブルA」の差分レプリケーション実施
上の図のように、対象ではないテーブル（テーブルB）に大量に更新を掛けた状態で計測します。
従来のCDC モードで計測
まずは従来のCDC からテストしていきます。
postgres_cdc_1 という20カラムで構成されたテーブルを事前に作成し、50件ほどレコードを登録しておきます。
次に、ジョブ作成の前にPostgreSQL でレプリケーションスロットを作成します。
SELECT pg_create_logical_replication_slot('sync_slot1', 'test_decoding');
レプリケーションスロットを指定して変更データキャプチャのジョブを作成します。
postgres_cdc_1 の初回ジョブを実行し、50件レプリケーションしました。
今度はレプリケーション対象ではない「postgres_cdc_2」というテーブルを作成し、100万件を追加します。
これで今回のジョブに関係ないテーブルの変更分が上積みされました。この状態で、連携対象の「postgres_cdc_1」に1万件追加します。
ここまでで準備が整いました。まさに状態としては以下のように変更位置が大分後ろにあります。
スケジュールの時刻になったところでジョブが実行され、1万件のレプリケーションが54秒 で完了しました。
これで既存のレプリケーションまでが確認できましたので、次は拡張型CDC の検証を行います。
拡張型CDC モードで計測
ではここから拡張型CDC を利用した場合のパフォーマンスを計測していきます。
先ほどと同じ手順でテーブルを作成します。その後、従来のCDC 機能で作成したレプリケーションスロットは使用しないので削除した後、拡張型CDC用のパブリケーションとレプリケーションスロットを作成します。
SELECT slot_name, active FROM pg_replication_slots;
SELECT pg_drop_replication_slot('sync_slot1');
CREATE PUBLICATION cdatasync_pub1 FOR TABLE cdata.postgres_enhanced_cdc_1;
SELECT pg_create_logical_replication_slot('sync_enhanced_slot1', 'pgoutput');
レプリケーション対象テーブルやレプリケーションスロットなどの用意が終わったところで、初回レプリケーションを実施します。
次の工程も同じように別なテーブルを作成して100万件追加後、レプリケーション対象テーブルに1万件追加します。
以下は1万件追加。
ここまでで、現在の状態は右端のTable-Aからの変更内容読み出しとなっています。
となってはいましたが、拡張型CDC では即変更データを取得していきますので、すぐに1万件の変更データが連携されてきていました。
この時点ではまだステージエリアに変更データがファイルで保存されている状態ですので、あとはスケジュールを待つだけになります。
なお、ステージエリアを構成図に加えると以下のようになります。ちなみにステージエリアとは、変更データをローカルにファイルで蓄積するエリアになります。
時間になり、ステージエリアから同期先へのレプリケーションが実行されましたが、既に変更データ分は取得済みなので6秒でジョブが完了しました。
従来のCDC と拡張型CDC でのパフォーマンス比較結果
今回の検証をまとめると以下の結果となりました。
変更データを取得するタイミングが全く異なるので、最終的は同期先への反映時間も大きく差が開きました。
実際には2テーブルの関係ではなく、もっと多くのテーブルが更新されていくと思いますので、その場合は更に差が開くものと思います。
なお、数回にわたり本検証を試しましたが、結果は変わらずでした。
おわりに
いかがでしたでしょうか。新しく追加された「拡張型CDC」機能を使うことで、パフォーマンスよく変更データキャプチャのレプリケーションが可能となっています。CData Sync は30日間の無償トライアルが可能ですので、ぜひお試しください！
無償トライアル | CData Sync | ノーコードで始めるETL / ELT パイプライ
関連コンテンツ
