CData Sync の Enhanced CDC と従来の CDC のパフォーマンス比較



CData Sync V24.3 で追加された「Enhanced CDC」機能は、レプリケーションのパフォーマンスを大幅に向上させます。その改善効果を定量的に把握するため、従来の「CDC 機能」との比較分析を行い、レプリケーション完了時間を測定しました。結果として、Enhanced CDC は従来の約9倍の速度で処理を完了することが確認されました。この記事では、実験環境の構成とレプリケーション手順について詳しくご紹介します。

Enhanced CDC とは

Enhanced CDC(拡張変更データキャプチャ)機能を使用すると、CData Sync のジョブでデータの変更をリアルタイムにキャプチャできます。リアルタイムでキャプチャされた変更データは、まず CData Sync のステージングエリアにファイルとして保存されます。変更をキャプチャする仕組みである CDC エンジンの詳細については、CData Sync ページのヘルプドキュメントをご覧ください。

従来の CDC についての詳しい解説はこちらの記事をご参照ください:変更データキャプチャ(CDC)とは?仕組みとメリットを解説

パフォーマンス向上の主な要因

まず前提として、従来の CDC と Enhanced CDC はどちらもトランザクションログをデータ変更の検出元として使用しています。

従来の CDC は、スケジュールされた間隔でデータソースにアクセスします。ジョブの実行時に、更新がターゲットテーブルのみに限定されていれば、効率的にその変更だけを取得できます。しかし、ターゲット以外のテーブルで多数の更新が発生している場合、従来の CDC はそれらの関係のない変更を読み飛ばす必要があります。下の図では、処理がオレンジ色の線の位置まで戻り、Table-B の変更をスキップしてから、Table-A の変更(図の右端)を取得する様子を示しています。

一方、Enhanced CDC はトランザクションログを継続的に監視し、読み取り位置(オレンジ色の線)を随時進めていきます。他のテーブルの変更があっても素早くスキップできるため、目的の変更データを見つけるまでの時間を大幅に短縮できます。

パフォーマンスのベンチマーク

パフォーマンスを評価するため、PostgreSQL をデータソース、SQL Server を同期先とする環境を構築しました。従来の CDC と Enhanced CDC のそれぞれについて、以下の手順を実行して比較しました。

  1. レプリケーション用の「テーブル A」を作成
  2. 「テーブル A」に 50 件のレコードを挿入
  3. 「テーブル A」の初回レプリケーションジョブを実行(50 件をレプリケート)
  4. 「テーブル B」を作成
  5. 「テーブル B」に 100 万件のレコードを挿入
  6. 「テーブル A」に 10,000 件のレコードを追加
  7. 手順 3 から 10 分後に「テーブル A」の差分レプリケーションジョブを実行

上の図に示すように、ターゲットではないテーブル(テーブル B)に大量の更新が適用されている状態で測定を行いました。

従来の CDC モードでの測定

最初に、従来の CDC 方式でテストを実施しました。まず、postgres_cdc_1 という名前で 20 カラムのテーブルを作成し、約 50 件のレコードを挿入しました。次に、ジョブを作成する前に、PostgreSQL でレプリケーションスロットを設定しました。

SELECT pg_create_logical_replication_slot('sync_slot1', 'test_decoding');

続いて、このレプリケーションスロットを指定して CDC ジョブを作成しました。

postgres_cdc_1 の初回ジョブを実行し、最初の 50 件のレコードを正常にレプリケートしました。

次に、ターゲットではない postgres_cdc_2 というテーブルを作成し、100 万件のレコードを挿入しました。

これにより、現在のジョブとは関係のないテーブルからの変更がバックログとして蓄積されました。その後、同期対象のテーブル postgres_cdc_1 に 10,000 件のレコードを追加しました。

これらの準備が完了した時点で、システムの状態は下図のようになり、変更追跡位置が大幅に遅れている状態となりました。

スケジュールされた時刻にジョブを実行したところ、10,000 件の新規レコードのレプリケーションが 54 秒で完了しました。

従来の CDC のパフォーマンス基準値を確立したので、次に Enhanced CDC のパフォーマンスを評価します。

Enhanced CDC モードでの測定

続いて、Enhanced CDC 機能を使用した場合のパフォーマンスを測定しました。同様の手順でテーブルを作成した後、従来の CDC 用に作成したレプリケーションスロットを削除し、Enhanced CDC 用に Publication と新しいレプリケーションスロットを作成しました。

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 万件のレコードを挿入し、その後レプリケーション対象テーブルに 10,000 件のレコードを追加しました。

10,000 件のレコード追加は以下のとおりです。

この時点で、システムは図の右端にあるテーブル A の変更を読み取る準備が整いました。

しかし、Enhanced CDC では変更データが即座に取得されるため、10,000 件の新規レコードはほぼ瞬時に連携されました。

この段階で、変更データはステージングエリア内にファイルとして保存され、スケジュールされた同期時刻を待っている状態です。参考までに、アーキテクチャにおけるステージングエリアの役割を下図に示します。ステージングエリアは、変更データをローカルにファイルとして保存するリポジトリの役割を果たします。

スケジュールされた時刻になると、ステージングエリアからターゲットシステムへのレプリケーションが実行されます。変更データはすでにキャプチャされているため、ジョブはわずか 6 秒で完了しました。

パフォーマンス比較結果:従来の CDC vs Enhanced CDC

テスト結果を以下の表にまとめました。

10,000 件の変更をレプリケート

モード 所要時間
従来の CDC 54 秒
Enhanced CDC 6 秒

変更データを取得するタイミングが根本的に異なるため、変更が最終的に同期先に反映されるまでの時間に大きな差が生じました。より多くのテーブルで更新が発生する実運用環境では、このパフォーマンス差はさらに顕著になると予想されます。なお、これらのテスト結果は複数回の実行においても一貫していました。

まとめ

このように、新しく導入された「Enhanced CDC」機能は、CDC レプリケーションのパフォーマンスを大幅に向上させます。CData Sync は 30 日間の無料トライアルを提供していますので、ぜひこのパフォーマンスの違いを実際にお試しください。

無料トライアル | CData Sync | ノーコードで始める ETL / ELT パイプライン