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