データのレプリケーション wf-data-replication
原則
エンタープライズ（FFDA）デプロイメントのコンテキストでは、データレプリケーションによって、Campaign のローカルデータベース（PostgreSQL）とクラウドデータベース（Snowflake）の 2 つのデータベースが並行して動作し、リアルタイムで同期が維持されます。
クラウドデータベース（Snowflake）は、100 万アドレスの更新など、大きなデータバッチの処理に最適化されています。 一方、Campaign のローカルデータベース（PostgreSQL）は、単一のシードアドレスの更新など、個人の操作や少量の操作に適しています。 同期はバックグラウンドで自動的かつ透過的に行われ、Campaign のローカルデータベース（PostgreSQL）のデータがクラウドデータベース（Snowflake）でリアルタイムに複製され、両方のデータベースが同期されます。 データ同期には、スキーマ、テーブルおよびデータが含まれます。
レプリケーションモード modes
データレプリケーションは、使用例に応じて異なるモードで実行できます。
- その場でのレプリケーション は、リアルタイムの複製が不可欠な場合に対応します。 拡散の作成やシードアドレスの更新などのユースケースでデータをすぐにレプリケートするには、特定のテクニカルスレッドに依存します。
- スケジュールされたレプリケーション は、即時の同期が不要な場合に使用されます。 スケジュールされたレプリケーションでは、タイポロジルールなどのデータ同期のために 1 時間ごとに実行される特定の テクニカルワークフローを使用します。
レプリケーションポリシー
レプリケーションポリシーでは、Campaign のローカルデータベース（PostgreSQL）テーブルからレプリケートするデータの量を定義します。 これらのポリシーは、テーブルのサイズと特定のユースケースによって異なります。 増分更新が行われるテーブルもあれば、完全にレプリケートされるテーブルもあります。 レプリケーション・ポリシーには、主に次の 3 つのタイプがあります。
- XS：このポリシーは、比較的小さいサイズのテーブルに使用されます。 テーブル全体が 1 回のショットでレプリケートされます。 増分レプリケーションでは、タイムスタンプポインターを使用して最近の変更のみをレプリケートすることで、同じデータが繰り返しレプリケートされるのを回避します。
- SingleRow：このポリシーは、一度に 1 つの行のみをレプリケートします。 通常は、現在の Campaign オブジェクトと関連オブジェクトを含むオンザフライのレプリケーションに使用されます。
- SomeRows：このポリシーは、クエリ定義またはフィルターを使用して、限られたデータのサブセットをレプリケートするように設計されています。 これは、選択的レプリケーションが必要な大きなテーブルに使用されます。
レプリケーションワークフロー workflows
Campaign v8 は、スケジュールされたデータレプリケーションを管理する特定のテクニカルワークフローに依存しています。 これらのテクニカルワークフローは、Campaign エクスプローラーの 管理／本番環境／テクニカルワークフロー／フル FFDA レプリケーション ノードから利用できます。これらは変更できません。
テクニカルワークフローは、サーバーで定期的にスケジュールされたプロセスやジョブを実行します。 すべてのテクニカルワークフローのリストについて詳しくは、このページを参照してください。
データレプリケーションを確実にするテクニカルワークフローを次に示します。
必要に応じて、データの同期を手動で開始できます。これを行うには、「スケジューラー」アクティビティを右クリックし、「保留中のタスクを今すぐ実行」を選択します。
ビルトインの 参照テーブルをレプリケート テクニカルワークフローに加えて、次のいずれかの方法を使用して、ワークフローでデータレプリケーションを強制できます
-
次のコードを使用して特定の JavaScript コード アクティビティを追加する：
code language-none nms.replicationStrategy.StartReplicateStagingData("dem:sampleTable")
-
次のコマンドを使用して、特定の nlmodule アクティビティを追加する：
code language-none nlserver ffdaReplicateStaging -stagingSchema -instance:acc1
API
API を使用すると、Campaign ローカルデータベース（PostgreSQL）からクラウドデータベース（Snowflake）に、カスタムデータと標準データの両方をレプリケーションできます。 これらの API を使用すると、定義済みのワークフローを回避し、カスタムテーブルのレプリケーションなど、特定の要件に合わせてレプリケーションをカスタマイズできます。
例：
var dataSource = "nms:extAccount:ffda";
var xml = xtk.builder.CopyXxlData(
<params dataSource={dataSource} policy="xs">
<srcSchema name="cus:recipient"/>
</params>
);
レプリケーションキュー
大量のレプリケーション要求が同時に発生すると、MERGE 操作中にテーブルレベルのロックが原因で、クラウドデータベース（Snowflake）でパフォーマンスの問題が発生する場合があります。 これを軽減するために、一元化されたレプリケーションワークフローは、リクエストをキューにグループ化します。
各キューはテクニカルワークフローによって処理され、テクニカルワークフローは特定のテーブルのレプリケーションを管理し、保留中のリクエストを単一の MERGE 操作として実行します。 これらのワークフローは、新しいレプリケーション要求を処理するために 20 秒ごとにトリガーされます。
nms:delivery テーブルのキュー。nms:dlvExclusion テーブルのキュー。nms:dlvRemoteIdRel テーブルのキュー。nmsTrackingUrl キューを同時実行で複製 （ffdaReplicateQueueTrackingUrl_2）
nms:trackingUrl テーブル用に同時実行でキューを作成し、2 つのワークフローを利用して、異なる優先度に基づいてリクエストを処理することで効率を向上させます。チュートリアル video
このビデオでは、Adobe Campaign v8 が使用するデータベース、データがレプリケートされる理由、レプリケートされるデータとレプリケーションプロセスの仕組みについて、重要な概念を説明します。
Campaign v8 クライアントコンソールに関するその他のチュートリアルは こちらから利用できます。