データレプリケーション wf-data-replication
原則
エンタープライズ（FFDA）デプロイメントのコンテキストでは、データレプリケーションにより、Campaign のローカルデータベース（PostgreSQL）とクラウドデータベース（Snowflake）の 2 つのデータベースが並行して動作し、リアルタイムで同期された状態が維持されます。
クラウドデータベース（Snowflake）は、100 万個のアドレスの更新など、大規模なデータバッチの処理に最適化されています。一方、Campaign のローカルデータベース（PostgreSQL）は、個別の操作や少量の操作（単一のシードアドレスの更新など）に適しています。同期はバックグラウンドで自動的かつ透過的に行われ、Campaign のローカルデータベース（PostgreSQL）のデータがクラウドデータベース（Snowflake）にリアルタイムで複製され、両方のデータベースの同期が維持されます。データ同期には、スキーマ、テーブルおよびデータが含まれます。
レプリケーションモード modes
データレプリケーションは、ユースケースに応じて様々なモードで実行できます。
- オンザフライレプリケーション は、リアルタイム複製が不可欠な場合に対応します。拡散の作成やシードアドレスの更新などのユースケースでは、特定のテクニカルスレッドに依存してデータを即座にレプリケートします。
- スケジュールされたレプリケーション は、即時の同期が不要な場合に使用されます。スケジュールされたレプリケーションでは、タイポロジルールなどのデータを同期するために、1 時間ごとに実行される特定のテクニカルワークフローが使用されます。
レプリケーションポリシー
レプリケーションポリシーは、Campaign のローカルデータベース（PostgreSQL）テーブルからレプリケートされるデータの量を定義します。これらのポリシーは、テーブルのサイズと特定のユースケースによって異なります。増分的に更新されるテーブルもあれば、全体がレプリケートされるテーブルもあります。レプリケーションポリシーには、主に次の 3 つのタイプがあります。
- XS：このポリシーは、比較的小さいサイズのテーブルに使用されます。テーブル全体が一度にレプリケートされます。増分レプリケーションでは、タイムスタンプポインタを使用して最近の変更のみをレプリケートすることで、同じデータが繰り返しレプリケートされるのを回避します。
- 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>
);
レプリケーションキュー
大量のレプリケーションリクエストが同時に行われると、結合操作中のテーブルレベルのロックにより、クラウドデータベース（Snowflake）でパフォーマンスの問題が発生する場合があります。この問題を軽減するために、一元化されたレプリケーションワークフローでは、リクエストをキューにグループ化します。
各キューは、テクニカルワークフローで処理され、特定のテーブルのレプリケーションを管理し、保留中のリクエストを単一の結合操作として実行します。これらのワークフローは、20 秒ごとにトリガーされ、新しいレプリケーションリクエストを処理します。
nms:delivery テーブルのキュー。nms:dlvExclusion テーブルのキュー。nms:dlvRemoteIdRel テーブルのキュー。nmsTrackingUrl キューを並行してレプリケート（ffdaReplicateQueueTrackingUrl_2）
nms:trackingUrl テーブルに並行してキューを作成し、2 つのワークフローを利用して、異なる優先度に基づいてリクエストを処理することで効率を向上させます。チュートリアル video
このビデオでは、Adobe Campaign v8 が使用するデータベース、データがレプリケートされる理由、レプリケートされるデータおよびレプリケーションプロセスの仕組みに関する主な概念について説明します。
Campaign v8 クライアントコンソールに関するその他のチュートリアルについては、こちらを参照してください。