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