护栏和限制 guardrails

关系数据存储支持最多​ 个200个表 （架构）。

对于编排的营销活动，任何单个架构​ 的总大小不得超过100 GB。

为了保持性能和稳定性，对架构的每日更新应限制为小于其总记录数的20%。

关系数据是用于引入、数据建模和分段用例支持的主要模型。

用于定位的架构必须至少包含​ 一个类型为String ​的标识字段，该字段映射到定义的标识命名空间。

每个架构​ 的平均属性数不应超过50列 ​以保持可管理性和性能。

需要配置文件+关系数据摄取。

所有引入都必须通过​ 更改数据捕获 ​源进行：

• 对于​ 基于文件的：需要_change_request_type字段。 支持的值为U （更新插入）或D （删除）。

• 对于​ 基于云的：必须启用表日志记录。

不允许部分记录更新，每行都必须作为完整记录提供。

Campaign Orchestration的批次摄取限制为​ 每15分钟一次。

在关系存储中，摄取延迟通常在​ 15分钟到2小时之间，具体取决于：

• 数据量

• 系统并发

• 操作的类型，例如，插入操作比更新操作快

数据流与数据集的关系为1-1。 这意味着，在给定时间，只有一个源可以馈送一个数据集。 要切换源，必须删除现有数据流，并使用新源创建一个新数据流。

所有架构（包括事实表）都必须包含​ 版本描述符，以确保正确的版本控制和可跟踪性。

每个表都必须有一个已定义的​ 主键 ​以支持数据完整性和下游操作。

在数据集创建期间分配的table_name是永久性的，在整个分段和个性化功能中使用。

当前数据建模框架中不支持​ 字段组。

受众定义中仅支持​ 标量属性；不允许使用​ 映射和数组。

分段活动主要依赖关系数据。 虽然可以包含配置文件数据，但使用大型配置文件数据集可能会影响性能。

对可以在批处理受众和流式受众中使用的配置文件属性 ​的数量强制实施限制，以保持系统效率。

完全支持​ 枚举。

未缓存读取受众，每个活动执行都会从基础数据触发完整的受众评估。

使用大型或复杂的受众定义时，强烈建议进行​ 优化 ​以确保性能。

保存的受众活动是静态的，它们反映的是活动执行时可用的数据。

不支持附加到已保存的受众活动。 任何修改均需要完全覆盖受众。