ガードレールと制限 guardrails

リレーショナルデータストアは、最大 200 個のテーブル（スキーマ）をサポートします。

調整されたキャンペーンの場合、個々のスキーマの合計サイズは 100 GB を超えないようにします。

パフォーマンスと安定性を維持するために、スキーマの 1 日あたりの更新を、合計レコード数の 20％未満に制限 ​する必要があります。

リレーショナルデータは、取り込み、データモデリング、セグメント化のユースケースでサポートされるプライマリモデルです。

ターゲティングに使用されるスキーマには、定義済みの ID 名前空間にマッピングされた、少なくとも 1 つのタイプString の ID フィールドを含める必要があります。

管理性とパフォーマンスを維持するために、スキーマあたりの属性の平均数 50 列を超えないようにしてください。

リレーショナルスキーマは、Adobe Experience Platform プロファイル に対して有効にできません。 Adobe Experience Platform プロファイル では、標準 XDM スキーマのみがサポートされます。 リレーショナルスキーマは、オーケストレートキャンペーンまたはアクションキャンペーンに対して有効にできます。 詳細情報

プロファイル + リレーショナルデータ取り込みが必要です。

すべての取り込みは、変更データキャプチャ ​ソースを通じて行う必要があります。

• ファイルベース の場合：_change_request_type フィールドは必須です。 サポートされている値は、U （アップサート）または D （削除）です。

• クラウドベース ​の場合：テーブルログを有効にする必要があります。

部分的なレコードの更新は許可されていません。各行は、完全なレコードとして指定する必要があります。

キャンペーンオーケストレーションのバッチ取り込みは 15 分ごとに 1 回 ​に制限されています。

リレーショナルストアでの取り込み待ち時間は、通常、次の条件に応じて 15 分から 2 時間 します。

• データ量

• システムの同時実行性

• 操作のタイプ（例：挿入は更新よりも高速です）

データセット間のデータフローの関係は 1～1 です。 つまり、特定の時間に 1 つのデータセットをフィードできるソースは 1 つだけです。 ソースを切り替えるには、既存のデータフローを削除し、新しいソースで新しいデータフローを作成する必要があります。

ファクトテーブルを含むすべてのスキーマには、適切なバージョン管理とトレーサビリティを確保するための​ バージョン記述子 ​を含める必要があります。

データの整合性とダウンストリーム操作をサポートするには、各テーブルに​ プライマリキー ​を定義する必要があります。

データセットの作成中に割り当てられた table_name は永続的であり、セグメント化およびパーソナライゼーション機能全体で使用されます。

現在のデータモデリングフレームワークでは、フィールドグループはサポートされていません。

オーディエンス定義では、スカラー属性のみがサポートされます。マッピングと配列は許可されません。

セグメント化アクティビティは主にリレーショナルデータに依存します。プロファイルデータを含めることができますが、大きなプロファイルデータセットを使用すると、パフォーマンスに影響を与える場合があります。

システム効率を維持するために、バッチオーディエンスとストリーミングオーディエンスの両方で使用できる​ プロファイル属性の数には制限が適用されます。

列挙 は完全にサポートされています。

オーディエンスを読み取りはキャッシュされず、キャンペーン実行ごとに基になるデータからの完全なオーディエンス評価がトリガーされます。

パフォーマンスを確保するために、大きなオーディエンス定義や複雑なオーディエンス定義を操作する際は、最適化を強くお勧めします。

保存したオーディエンスのアクティビティは静的で、キャンペーン実行時に使用可能なデータを反映します。

保存したオーディエンスアクティビティへの追加はサポートされていません。 変更を行う場合は、オーディエンスを完全に上書きする必要があります。