ガードレールと制限 guardrails

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

スキーマサイズ - オーケストレーションされたキャンペーンの場合、個々のスキーマの合計サイズは100 GBを超えてはなりません。

毎日の更新ボリューム - パフォーマンスと安定性を維持するために、スキーマの毎日の更新は、合計レコード数の20%未満に制限する必要があります。

関係データモデル – 関係データは、取り込み、データモデリング、およびセグメント化のユースケースでサポートされる主要モデルです。

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

スキーマごとの属性 - スキーマごとの平均属性数は、管理性とパフォーマンスを維持するために、50列を超えてはなりません。

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

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

データキャプチャソースの変更 – すべての取り込みは、データキャプチャソースの変更を介して行う必要があります：

• ファイルベースのソース - _change_request_type フィールドは必須です。 サポートされている値は、u（アップサート）または d（削除）です。 これらの値は、大文字の U と D ではなく、小文字の u と d にする必要があります。

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

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

バッチ取り込み頻度 - Campaign オーケストレーションのバッチ取り込みは、15分ごとに1回に制限されます。

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

• データ量

• システムの同時実行性

• 操作の種類（例えば、挿入は更新よりも高速です）

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

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

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

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

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

複合プライマリキー - ファイルアップロードフローを使用した複合プライマリキーのサポートは、現時点では利用できません。

チャネルアクティビティ制限 - オーケストレーションされたキャンペーンは、最大10個のチャネルアクティビティ（メール、SMS、プッシュ、またはダイレクトメール）をサポートします。 チャネルアクティビティのみがこの制限にカウントされます。 ターゲティングおよびフロー制御アクティビティはカウントされません（例えば、「オーディエンスを作成」、「待機」、「分割」、「エンリッチメント」、「紐付け」、「分岐」、「終了」または「テスト」）。

保存または公開時に制限を超えると、操作は失敗します。 制限内に収まるように、チャネルアクティビティの数を減らしたり、複数のオーケストレーションされたキャンペーンをまたいでメッセージ配信を分割したりします。

キャンバスアクティビティ制限 - オーケストレーションされたキャンペーンキャンバスのアクティビティ数は500に制限されています。 この制限は、キャンバス上のすべてのアクティビティタイプに適用されます。 これは、公開時に適用されるチャネルアクティビティの制限とは別です。 メンテナンス性とパフォーマンスを確保するために、ワークフローを実際には100 アクティビティ未満に抑えます。

スカラー属性のみ - オーディエンス定義ではスカラー属性のみがサポートされます。マップと配列は使用できません。

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

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

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

読み取りオーディエンスがキャッシュされない – 読み取りオーディエンスはキャッシュされません。各キャンペーン実行では、基になるデータから完全なオーディエンス評価がトリガーされます。

オーディエンスの最適化 – 大規模または複雑なオーディエンス定義を使用してパフォーマンスを確保する場合は、最適化を強くお勧めします。

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

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