本文档概述了设计Adobe Campaign数据模型时的主要建议。
要更好地了解Campaign内置表及其交互,请参阅 本节 部分。
已阅读 本文档 以开始使用Campaign模式。 了解如何配置扩展模式以扩展Adobe Campaign数据库的概念数据模型 本文档.
Adobe Campaign系统非常灵活,可以在初始实施之后扩展。 但是,尽管可能性是无限的,但做出明智的决策并奠定坚实的基础来开始设计数据模型至关重要。
本文档提供了常见用例和最佳实践,以了解如何正确构建Adobe Campaign工具。
Adobe Campaign是一款功能强大的跨渠道营销活动管理系统,可帮助您调整线上和线下策略以创建个性化的客户体验。
虽然大多数电子邮件服务提供商都通过以列表为中心的方法与客户通信,但Adobe Campaign依靠关系数据库来利用更广泛的客户及其属性视图。
下图显示了这种以客户为中心的方法。 此 收件人 灰色表格表示构建所有内容的主客户表格:
要访问每个表的说明,请转到 Admin > Configuration > Data schemas,从列表中选择资源并单击 Documentation 选项卡。
Adobe Campaign默认数据模型在中介绍 本文档.
Adobe Campaign Classic允许构建自定义客户表。 但是,在大多数情况下,建议利用标准 收件人表 已经预建了附加表和功能。
应将哪些数据发送到Adobe Campaign? 确定营销活动所需的数据至关重要。
Adobe Campaign既不是data warehouse,也不是报表工具。 因此,请不要尝试将所有可能的客户及其相关信息导入Adobe Campaign,也不要尝试导入仅用于构建报表的数据。
要决定是否需要在Adobe Campaign中使用某个属性,请问自己它是否属于以下类别之一:
如果不属于任何此类属性,则在Adobe Campaign中很可能不需要此属性。
要确保良好的体系结构和系统性能,请遵循以下最佳实践在Adobe Campaign中设置数据。
如果某个字段具有定位或个性化目的,则需要将其存储在表中。 换言之,如果字段未用于发送个性化电子邮件或未用作查询中的标准,则它占用磁盘空间而无用。
对于混合实例和内部部署实例,FDA(联合数据访问,允许访问外部数据的一项可选功能)涵盖了在营销活动过程中需要“实时”添加字段的需求。 如果您拥有联合数据访问(FDA),则无需导入所有内容。 有关此内容的更多信息,请参阅 关于联合数据访问.
除了 autopk 在大多数表中默认定义时,应考虑添加一些逻辑或业务密钥(帐号、客户机号等)。 以后可用于导入/协调或数据包。 有关此内容的更多信息,请参阅 标识符.
高效的密钥对于性能至关重要。 数值数据类型应始终作为表的键首选。
对于SQLServer数据库,如果需要性能,可以考虑使用“聚簇索引”。 由于Adobe不处理此问题,因此您需要在SQL中创建它。
使用方案中的“表空间”属性可以为表指定专用表空间。
安装向导允许您按类型(数据、临时和索引)存储对象。
专用表空间更适合分区、安全规则,并允许灵活流畅的管理、更好的优化和性能。
Adobe Campaign资源有三个标识符,可以添加额外的标识符。
下表介绍了这些标识符及其用途。
标识符 | 说明 | 最佳实践 |
---|---|---|
Id |
|
|
名称(或内部名称) |
|
|
标签 |
|
|
在Adobe Campaign中创建的每个表都需要主键。
大多数组织正在从外部系统导入记录。 虽然Recipient表的物理键是“id”属性,但还可以确定自定义键。
此自定义键是外部系统中馈送Adobe Campaign的实际记录主键。
当开箱即用表同时具有autopk和内部键时,内部键将被设置为物理数据库表中的唯一索引。
创建自定义表时,您有两个选项:
绝不能将Autopk用作工作流中的引用。
Adobe Campaign主键是为所有现成表格自动生成的id,对于自定义表格可以相同。 有关更多信息,请参阅此章节。
此值获取自所谓的 序列,是用于生成编号规则的数据库对象。
序列有两种类型:
该序列是一个32位的整数,具有可用值的有限最大数量:21.4亿。 在达到最大值后,为了回收ID,序列将返回到0。
如果旧数据未被清除,则结果将发生唯一键冲突,从而成为平台运行状况和使用情况的阻止因素。 Adobe Campaign将无法发送通信(当它影响投放日志表时),并且性能将受到严重影响。
因此,如果客户每年发送60亿封电子邮件,并且日志的保留期为180天,那么他们的id将在4个月内用完。 要防止此类挑战,请确保根据卷设置清除设置。 有关更多信息,请参阅此章节。
在Adobe Campaign中创建一个主键为autoPK的自定义表时,应将自定义专用序列系统地与该表关联。
默认情况下,自定义序列的值介于+1,000到+2.1BB之间。 从技术上讲,通过启用负ID可以获得完整的4BB范围。 应谨慎使用此属性,当从负数交叉到正数时,将丢失一个id:在生成的SQL查询中,Adobe Campaign通常会忽略记录0。
有关序列消耗的更多信息,请观看 此视频.
索引对于性能至关重要。 在架构中声明键时,Adobe将自动在键的字段上创建索引。 您还可以为不使用键的查询声明更多索引。
Adobe建议定义其他索引,因为这可以提高性能。
但是,请牢记以下事项:
管理索引可能会变得非常复杂,因此了解索引的工作方式非常重要。 为了说明这种复杂性,让我们举一个基本示例,例如通过筛选名字和姓氏来搜索收件人。 操作步骤:
转到列出数据库中所有收件人的文件夹。 有关此内容的更多信息,请参阅 管理用户档案.
右键单击 First name 字段。
选择 Filter on this field。
对重复此操作 Last name 字段。
屏幕上会添加两个相应的过滤器。
您现在可以对以下内容执行搜索过滤 First name 和 Last name 字段的过滤条件。
现在,为了加快对这些过滤器的搜索,您可以添加索引。 但应使用哪些索引?
此示例适用于使用PostgreSQL数据库的托管客户。
下表显示了在何种情况下根据第一列中显示的访问模式使用或不使用下述三个索引。
搜索条件 | 索引1(名字+姓氏) | 索引2(仅限名字) | 索引3(仅限姓氏) | 评论 |
---|---|---|---|---|
名字等于“强尼” | 已使用 | 已使用 | 未使用 | 由于名字在索引1上的第一个位置,因此无论如何都将使用:无需为姓氏添加条件。 |
名字等于“Johnny”,姓氏等于“Smith” | 已使用 | 未使用 | 未使用 | 由于这两个属性是在同一查询中搜索的,因此将只使用组合这两个属性的索引。 |
姓氏等于“Smith” | 未使用 | 未使用 | 已使用 | 索引中属性的顺序已考虑在内。 如果不匹配此顺序,则不能使用该索引。 |
名字以“Joh”开头 | 已使用 | 已使用 | 未使用 | “左侧搜索”将启用索引。 |
名字以“nny”结尾 | 未使用 | 未使用 | 未使用 | “Right search”将禁用索引并执行完全扫描。 某些特定的索引类型可以处理此用例,但默认情况下,它们在Adobe Campaign中不可用。 |
名字包含“John” | 未使用 | 未使用 | 未使用 | 这是“左”和“右”搜索的组合。 由于后者,它将禁用索引并执行完全扫描。 |
名字等于“john” | 未使用 | 未使用 | 未使用 | 索引区分大小写。 要使其不区分大小写,应创建一个特定索引,该索引包含一个SQL函数,如“upper(firstname)”。 您应该对其他数据转换执行相同的操作,例如“unaccent(firstname)”。 |
请注意大型表上的“自身”完整性。 删除具有“拥有”完整性的宽表的记录可以停止实例。 表格被锁定,删除操作逐一进行。 因此,最好在具有大卷的子表上使用“中立”完整性。
将链接声明为外部连接对性能不利。 零ID记录模拟外部连接功能。 如果链接使用autopk,则无需声明外部连接。
虽然可以在工作流中连接任何表,但Adobe建议直接在数据结构定义中定义资源之间的通用链接。
应根据表中的实际数据来定义链接。 错误定义可能会影响通过链接检索的数据,例如,意外地复制记录。
以与表名称一致的形式命名您的链接:链接名称应有助于了解远程表是什么。
请勿将带有“id”的链接命名为后缀。 例如,将其命名为“transaction”,而不是“transactionId”。
默认情况下,Adobe Campaign将使用外部表的主键创建一个链接。 为清楚起见,最好在链接定义中明确定义连接。
索引将被添加到链接中使用的属性。
“创建者”和“上次修改者”链接存在于许多表中。 如果业务未使用此信息,则可以使用链接上的属性noDbIndex禁用索引。
设计链接时,请确保在声明了1-1关系时目标记录是唯一的。 否则,当仅需要一条连接时,该连接可能会返回多条记录。 当“查询返回的行数超过预期值”时,这会导致在投放准备期间出现错误。 将链接名称设置为与目标架构相同的名称。
在(1)侧的架构中定义具有基数(1-N)的链接。 例如,应在事务模式中定义关系Recipient (1) - (N) Transaction。
请注意,默认情况下,链接的反向基数为(N)。 可以通过向链接定义添加属性revCardinality='single'来定义链接(1-1)。
如果用户应该看不到反向链接,可以使用链接定义revLink='来隐藏它无'. 一个很好的用例是定义从收件人到完成的最后一笔交易的链接。 您只需要查看从收件人到最后一个交易的链接,并且不需要从交易表中显示反向链接。
执行外部联接(1-0…1)的链接应谨慎使用,因为它会影响系统性能。
Adobe Campaign既不是data warehouse,也不是报表工具。 因此,要确保Adobe Campaign解决方案有良好的性能,应控制数据库增长。 要实现这一点,遵循以下一些最佳实践可能会有所帮助。
默认情况下,Adobe Campaign投放和跟踪日志的保留时间为180天。 将运行清理过程以删除任何早于该时间的日志。
要了解有关数据保留的更多信息,请参阅 Campaign隐私和安全准则.
了解有关Campaign数据库清理工作流的更多信息 在此部分中.
自定义表不会通过标准清理过程清除。 虽然这可能在第一天就不需要了,但请不要忘记为自定义表构建清除流程,因为这可能会导致性能挑战。
有几个解决方案可以最大程度地降低Adobe Campaign中对记录的需求:
您可以在架构中声明“deleteStatus”属性。 将记录标记为已删除,然后在清理任务中延迟删除会更有效。
为了确保随时获得更好的性能,请遵循以下最佳实践。
Adobe Campaign依赖于第三方数据库引擎。 根据提供商的不同,为较大的表优化性能可能需要特定的设计。
以下是使用大型表和复杂连接设计数据模型时应遵循的一些常见最佳实践。
表大小是记录数和每条记录列数的组合。 两者都会影响查询的性能。
在PostgreSQL上,行不应超过8 KB才能避免 TOAST 机制。 因此,应尽量减少列数和每行大小,以保持系统的最佳性能(内存和CPU)。
行数也会影响性能。 Adobe Campaign数据库并非用于存储未主动用于定位或个性化目的的历史数据 — 这是一个操作数据库。
要防止任何与高行数相关的性能问题,只需将必要的记录保留在数据库中。 任何其他记录都应导出到第三方data warehouse并从Adobe Campaign操作数据库中删除。
以下是有关表大小的一些最佳实践:
示例如下:
在此示例中: