Apex 大数据处理(4)数据删除

学习目标

完成本单元后,您将能够:

  • 在处理大量数据时,使用Salesforce批量API数据删除机制会对性能产生积极影响。
  • 从组织中抽取大量数据时,使用PK分块来对抗性能低下的问题。
  • 了解在自定义对象下截断记录以加快删除的好处。

使用批量API删除和提取

谈到您的Salesforce组织,数据管理始终处于优先级列表的首位。这部分管理包括删除和提取数据。而且,就像加载大量数据一样,批量API在删除或提取LDV时非常有用。当有一个过程涉及删除一百万或更多的记录时,批量API的硬删除选项可以做到这一点。

软与硬删除

Salesforce数据删除机制可能会对大数据量的性能产生深远的影响。 Salesforce将回收站用于用户删除的数据。通过回收站将其标记为已删除且可见,而不是删除数据。这个过程被称为软删除。当数据被软删除时,仍然会影响数据库的性能,因为它仍然存在于组织中,并且删除的记录必须从任何查询中排除。

数据保留在回收站中15天,或直到回收站增长到特定的大小。一旦达到时间或大小限制,或者使用UI,API或Apex清空回收站时,数据将从数据库中物理删除。

批量API支持硬删除(物理删除)选项,该选项允许记录绕过回收站并立即变为可用于删除。使用批量API的硬删除功能是推荐的删除大量数据卷的策略,以尽快释放空间并防止无关的材料影响性能。请注意,硬删除选项在默认情况下处于禁用状态,必须由管理员启用。

分块数据

使用批量API抽取数据时,默认情况下,查询会被分割为100,000个记录块 – 您可以使用chunkSize头域来配置较小的块,也可以使用大于250,000的较大的块。较大的块大小使用较少批量API批处理,但可能无法执行。您可能需要尝试一下才能确定最佳块大小。

在数量极高的情况下(数以亿计的记录),通过对字段值进行过滤来定义这些块可能并不实际。返回的行数可能会高于Salesforce查询优化器的选择性阈值。结果可能是全表扫描和性能下降,甚至失败。那么你需要采用不同的策略。

使用PK块

所以如果属性过滤不能帮助你将数据分成足够小的块,你可以做什么?使用PK Chunking处理超大型数据集提取。 PK代表主键 – 对象的记录ID–始终索引。 PK分块根据查询记录的记录ID将非常大的表上的批量查询拆分成块。

查询具有超过1000万条记录的表时,或批量查询始终超时时启用PK分块。 PK Chunking是Salesforce Bulk API的一项支持功能,因此它可以将查询拆分为可管理的块。只需在批量API作业中输入几个参数,平台就会自动将查询分成不同的块,对每个块执行查询并返回数据。

您可以使用大多数标准对象的PK块。它支持客户,广告系列,CampaignMember,大小写,联系人,潜在客户,登录历史记录,机会,任务和用户以及所有自定义对象。要启用该功能,请在批量API查询的作业请求上指定标题Sforce-Enable-PKChunking。

要选择块大小,只需在标题中指定它。例如,此标题可以使用块大小为50,000的记录启用PK组块:Sforce-Enable-PKChunking:chunkSize = 50000。每个块都作为一个单独的批处理进行处理,并计入您的每日批处理限制,并且其结果必须单独下载。您可以在批量API查询中包含WHERE子句的同时使用PK块处理执行筛选。使用此方法,可能会有比chunkSize中指定的数量少的记录返回的记录。

注意

如果您查询的记录少于1000万,则可以通过将chunkSize设置为小于查询记录数的数字来练习PK分块。例如,Sforce-Enable-PKChunking:chunkSize = 1000。你会得到一个查询拆分成多个批次,并看到PK在行动。
查询成功分块时,原始批处理的状态显示为NOT_PROCESSED。如果分块失败,则原始批处理的状态显示为FAILED,但在分块尝试期间成功排队的所有分块批处理都将正常处理。当原始批次状态更改为NOT_PROCESSED时,监视后续批次。您可以在完成后从每个后续批次检索结果。那么你可以安全地关闭工作。

截断

如果要立即删除沙箱组织的自定义对象中的记录,可以尝试截断这些自定义对象。截断自定义对象是永久删除自定义对象中的所有记录的一种快速方法,同时保持对象及其元数据的完整性以供将来使用。

截断自定义对象将清除当前坐在自定义对象的回收站中的所有记录;自定义对象的历史;以及每个删除记录的相关事件,任务,注释和附件。

注意

截断自定义对象会导致截断对象及其记录的一些不可逆转的更改。他们不能回到原来的状态。

截断是有用的,例如,如果您创建了一个自定义对象并填充了测试记录。当您完成测试数据时,可以截断对象以清除测试记录,但保留该对象并将其投入生产。这比批量删除记录快得多,并且可能重新创建对象。

这是简单的设置过程:

  1. 首先,通过在快速查找框中输入User Interface,选择User Interface,然后选择权限,为您的组织启用截断。
  2. 接下来,转到自定义对象的对象管理设置。
  3. 单击对象名称以转到该对象的详细信息页面,然后 Truncate.
  4. 在“Confirm Custom Object Truncate”窗口中,查看警告,然后在空字段中输入要截断的对象的名称。
  5. 点击 Truncate.

截断之后必须使用擦除功能来释放存储空间。

截断自定义对象时,对象的所有记录都将永久删除,但对象的定义仍然存在。记录不再计入您的组织限制。相反,如果您删除自定义对象,对象将移动到回收站15天(如上所述)。之后,对象及其记录被永久删除。

不能截断由另一个对象通过查找字段引用的标准对象或自定义对象,或者在主 – 从关系的主方一侧引用的标准对象或自定义对象在报告快照中被引用,具有自定义索引或外部标识,或者激活了瘦子表。而且,当组织已经达到允许的自定义对象的限制时,不能截断自定义对象。

使用诸如截断之类的策略,以及PK分块和批量API的硬删除,可以帮助您防止大量数据卷毁你的组织。定期和根据需要采用这些方法是保持稳健性能的明智做法。

Apex 大数据处理(3)加载数据

学习目标

完成本单元后,您将能够:

  • 描述Salesforce中精益数据加载的好处。
  • 加载大量数据时,了解批量API优于SOAP API的优点。
  • 通过暂停数据验证和浓缩操作加快加载大型数据集的过程。

加载精益

无论我们正在谈论LDV迁移还是正在进行的大数据同步操作,将这些操作对业务关键型操作的影响降至最低是最佳做法。实现这一目标的一个明智的策略是加载精简 – 仅包括满足业务关键操作所需的数据和配置。

加载精益需要什么?

  • 在将用户移至Salesforce之前识别业务关键型操作。
  • 确定实现这些操作所需的最小数据集和配置。
  • 根据您确定的要求定义数据和配置策略。
  • 尽可能快地加载数据以减少同步的范围。

    在决定数据加载和配置策略时,请考虑这些设置选项,这些选项使您能够推迟非关键进程并加快LDV加载速度。

全组织共享默认值. 当您使用私人共享模式加载数据时,系统会在记录添加时计算共享。如果使用公共读/写共享模式加载,则可以将该处理推迟到切换之后。

复杂的对象关系. 您在对象上定义的查找次数越多,数据加载期间系统执行的检查就越多。但是,如果你能够在后期阶段建立这些关系,那么加载速度会更快。

共享规则. 如果在加载数据之前配置了基于所有权的共享规则,则如果记录的所有者属于定义要共享的数据的角色或组,则您插入的每条记录都需要共享计算。如果您在加载数据之前配置了基于条件的共享规则,则每个记录的字段与规则选择条件相匹配也需要共享计算。

工作流规则,验证规则和触发器. 这些功能强大的工具可以确保在日常操作中输入的数据是干净的,并在记录之间包含适当的关系但是,如果在海量数据加载期间启用它们,它们也可能会减慢处理速度。

但不是太瘦

他们说你不能太富有或太瘦。但是当涉及到数据加载时,你肯定可能太瘦了。虽然消除更快数据加载的障碍是明智之举,但要记住,在数据加载过程中,少量配置是必不可少的(或者至少是高度期望的),而且不应该混淆:

  • 与主 – 子细节的父记录. 如果父母不存在,您将无法加载子记录。
  • 记录所有者. 在大多数情况下,您的记录将由个人用户拥有,业主需要存在于系统中才能加载数据。
  • 角色层次结构. 如果记录的所有者不是角色层次结构的成员,则可能认为加载速度会更快。但几乎在所有情况下,性能都是一样的,如果您加载门户客户,速度会更快。所以推迟这个配置方面没有任何好处。

批量API与SOAP API数据加载

当您加载LDV时,您选择的API会有所不同。标准Force.com SOAP API针对一次更新一些记录的实时客户端应用程序进行了优化。 SOAP API要求开发人员和管理员实现复杂的流程,以小尺寸的块来上传数据,监视结果并重试失败的记录。这种方法对于小数据负载是可以接受的,但是对于大数据集却变得笨重和耗时。

另一方面,批量API旨在简化从数千到数百万条记录的数据处理过程。批量API基于REST原则,专门为简化和优化加载或删除大型数据集的过程而开发。

使用批量API进行LDV可以实现超快的处理速度,同时减少客户端编程语言,易于监控的作业状态,失败记录的自动重试,并行处理支持,Force.com的最小往返次数,最小化API调用,有限的丢弃连接,以及易于调整的批量大小。简而言之,这是插入,查询和删除记录的最快方法。

批量API的工作原理

当您使用批量API上传记录时,这些记录将流式传输到Force.com以创建新作业。随着数据卷入作业,它被存储在临时存储器中,然后被分割成用户定义的批次(最多10,000条记录)。即使您的数据仍然被发送到服务器,Force.com平台也会提交批处理进行处理。

批次可以根据您的需要并行或串行处理。批量API将功能从您的客户端应用程序移动到服务器。 API记录每个作业的状态,并尝试自动为您重新处理失败的记录。如果作业超时,批量API会自动将其重新放入队列中,并为您重新尝试。

每个批次都是独立处理的,一旦批次完成(成功与否),作业将更新结果。具有适当访问权限的任何人都可以通过Salesforce.com管理界面对作业进行监控和管理。

通过暂停事件来提高速度

当您需要快速加载LDV时,务必确保每个插入程序尽可能高效。通过正确的准备和后期处理,您可以在加载时禁用数据验证和增强操作,而不会影响您的数据完整性或业务规则。

Force.com平台包含强大的工具,可确保用户输入的数据清晰,并在记录之间包含适当的关系。验证规则确保数据用户输入的新记录和现有记录符合您业务指定的标准。通过工作流程规则,您可以自动执行现场更新,电子邮件警报,出站邮件以及与工作流程,审批和里程碑关联的任务。触发器允许您在记录插入操作数据和执行其他操作。

虽然这些工具允许您在正常操作期间保持数据完整性,但是如果在海量数据加载期间启用这些工具,还可能导致插入操作变慢。但是,如果关闭验证,工作流程和触发器,那么如何确保一旦完成加载,就可以获得准确的数据,并在对象之间建立正确的关系?这个工作有三个关键阶段 – 分析和准备数据,禁止加载事件和后期处理。

分析和准备数据

要在没有触发器,验证规则和工作流规则运行的情况下安全地加载,请检查您通常可以通过这些操作满足的业务需求,然后回答几个问题。

首先,您可以在数据加载之前通过数据清理来满足您的哪些要求,或者在对象之间存在关键依赖关系的情况下对负载操作进行排序?例如,如果通常使用验证规则来确保用户条目在有效范围内,则可以在加载之前查询数据集以查找和修复不符合规则的记录。

其次,您可以在数据加载之后通过后处理记录满足哪些要求?这里一个典型的用例集涉及到数据丰富 – 可能涉及添加对象之间的查找关系,将汇总字段汇总到父记录以及记录之间的其他数据关系。

禁用加载事件

一旦分析了所有数据验证和充实要求,并计划在数据加载之前或之后对其进行管理的操作,可以临时禁用规则和触发器以加快加载速度。只需编辑每个规则并将其设置为“无效”状态即可。您可以以相同的方式禁用验证,潜在客户和案例分配规则以及区域分配规则。

暂时禁用触发器有点复杂,需要做一些准备。首先,创建一个自定义设置和相应的复选框字段来控制何时触发一个触发器。然后在您的触发器代码中包含一个语句,就像本例中突出显示的那样。

一旦完成,禁用或启用触发器就像编辑复选框字段一样简单。

后期处理

当您完成加载数据时,是时候完成您推迟的数据丰富和配置任务,直到这一点:

  • 添加对象之间的查找关系,将汇总字段汇总到父记录以及使用批量Apex或批量API记录之间的其他数据关系。
  • 使用外键或其他数据增强Salesforce中的记录,以利用批量Apex或批量API与其他系统集成。
  • 重置您为触发器创建的自定义设置上的字段,以便在记录创建和更新时适当触发。
  • 重新打开验证,工作流程和分配规则,以便在用户输入和编辑记录时触发相应的操作。

所以你有它:通过加载精益,使用批量API和暂停事件,您可以确保您的数据加载是有效的,尽可能快,并保持其完整性。现在,我们已经加载了数据,移动到下一个单元,我们覆盖删除和提取。

Apex 大数据处理(2)查询

学习目标

完成本单元后,您将能够:

  • 在处理大量数据时使用查询而不降低性能。
  • 使用批量查询有效地查询大型数据集。
  • 描述使用瘦表来包含经常使用的字段的好处。

搜索架构

将大量数据存储在您的组织中可能会影响性能,而且肯定包含搜索。搜索是基于自由格式文本查询记录的功能。 Salesforce搜索体系结构基于其自己的数据存储库,该数据存储库已针对搜索该文本进行了优化。

对于要搜索的数据,必须先对其进行索引。 Force.com会自动索引大多数文本字段,以便您的用户可以构建跨对象搜索并快速查找包含感兴趣的字符串的记录。索引搜索是通过首先在索引中搜索适当的记录,然后根据访问权限,搜索限制和其他过滤器来缩小结果。

这创建了一个结果集,通常包含最相关的结果。在结果集达到预定大小后,剩余的记录被丢弃。然后使用结果集来查询数据库中的记录以检索用户看到的字段。而当大量数据被添加或更改时,整个过程可能需要很长时间。

使用查询

考虑这种情况:你有一个很好的瘦对象集。所有用于集成和自定义Visualforce页面的代码都已经编写好,并且可以与测试数据一起使用。随着客户开始使用该系统,一切都很顺利。但是当组织加载或积累大量数据时,性能开始严重下降。

解决方案:查询建立。这是设计一个可以处理LDV的组织的关键。设计选择性列表视图,报告和SOQL查询以及理解查询优化是非常重要的。

SOQL与SOSL查询

搜索可以通过SOQL或SOSL查询来访问。 SOQL是Force.com的数据库查询语言,类似于SQL。您可以使用SOQL来查询通常是多对一的子对父关系,并查询几乎总是一对多的父对子关系。

SOSL是Force.com的全文搜索语言。 SOSL可以标记一个字段中的多个术语,并可以建立一个搜索索引。如果你正在寻找一个你知道存在于一个字段中的特殊的术语,你可能会发现SOSL比SOQL更快。但是,对于每个Apex交易,SOSL查询的州长限制是2000; SOQL查询是5万。所以如果你需要检索超过2000条记录,SOQL是更好的选择。

Force.com查询优化器

由于Salesforce使用多租户架构,因此数据库系统的优化程序无法独立有效地优化Salesforce查询。因此,Salesforce平台包含自己的查询优化程序,该查询优化程序利用索引字段为给定查询创建最有效的执行计划,从而帮助数据库系统的优化程序为Salesforce查询生成有效的执行计划。

Force.com查询优化器维护一个关于每个索引中数据分布的统计表。它使用此表执行预查询以确定使用索引是否可以加快查询速度。它适用于自动生成的查询,以处理报表,列表视图以及SOQL查询和其他背负的查询。

批量Apex

一般来说,在Force.com平台上查询和处理大型数据集的最好方法就是批量异步执行。您可以使用Batch Apex查询和处理多达5000万条记录。

Batch Apex不能在所有使用情况下工作(例如,如果您需要同步使用,就像需要查询超过50,000条记录的Visualforce页面一样),但它是您的工具箱中的一个很好的工具。

批量查询

高效查询大型数据集的另一个策略是使用批量查询。批量查询最多可以检索15 GB的数据,分为15个1 GB的文件。

批量API查询支持query和queryAll操作。 queryAll操作返回由于合并或删除而被删除的记录。 queryAll操作也返回关于存档的任务和事件记录的信息。

将批处理添加到批量查​​询作业时,请求标头中的Content-Type必须为text / csv,application / xml或application / json,具体取决于作业创建时指定的内容类型。为批处理提供的实际SOQL语句是纯文本格式。

如何处理批量查询

处理批量查询时,Salesforce将尝试执行查询。如果查询未在标准的两分钟超时限制内执行,则作业将失败,并返回QUERY_TIMEOUT错误。如果发生这种情况,请重写更简单的查询并重新提交批处理。

如果查询成功,Salesforce将尝试检索结果。如果结果超过1 GB的文件大小限制,或者需要超过10分钟的时间才能检索,则完成的结果将被缓存,然后再进行一次尝试。尝试15次后,作业失败,返回超过15次的错误消息。如果发生这种情况,请考虑使用PK Chunking标头将查询结果拆分为更小的块。 (更多关于PK在后续单元中的组块。)如果尝试成功,结果将返回并存储七天。

使用瘦表

假设您已遵循编码最佳实践,并与Salesforce客户支持部门合作,在适当的地方放置自定义索引,但您仍然遇到性能问题。用户抱怨他们的报告和仪表板超时,而从Visualforce页面调用的SOQL表现得越来越慢。如果您迫切需要进一步提高性能,那么有一个特别的,功能强大的解决方案:瘦表。

瘦表是Force.com平台中的自定义表,它包含标准或自定义基本Salesforce对象的字段的子集。如果需要的话,Force.com可以有多个小表,并维护它们,并保持透明。

通过使用较小的行和较少的数据来扫描基本的Salesforce对象,skinny表允许Force.com在每次数据库读取时返回更多的行,从一个大对象读取时增加吞吐量,如下图所示:

Skinny Tables graphic.png

此外,紧缩表不包含软删除的行(即回收站中的记录为isDeleted = true),这往往会减少表的体积。基表上的自定义索引也会被复制,并且通常会因为底层数据库查询中发生的表连接减少而更好地执行。

下面是一个简单的表格如何加快查询的例子。而不是使用01/01/16到12/31/16这样的日期范围 – 这需要花费昂贵的重复计算来创建年度或年度至今的报告 – 您可以使用瘦表来包括年份字段和在年= 2016年过滤。

Force.com平台自动同步基础对象和瘦客户端表之间的行,所以数据始终保持最新。 Force.com平台在查询运行时确定何时使用瘦表是有意义的,因此您不必修改报告或开发任何Apex代码或API调用。

瘦表对于包含数百万条记录的表是最有用的。它们可以在自定义对象上创建,也可以在Account,Contact,Opportunity,Lead和Case对象上创建。他们可以提高报告,列表视图和SOQL的性能。

注意

要启用瘦客户端表,请联系Salesforce客户支持。

瘦表可以是一个方便的方法来解决性能问题。但是,与使用高效索引从基本Salesforce对象读取相比,它们可能无法适应所有用例,或者提高性能。他们带有你应该理解的副作用,因为他们可能会限制或负担你的业务流程。

在实现瘦表之前,需要考虑以下几点:

瘦的表是瘦的. 为了确保最佳性能,它们只包含满足特定业务用例所需的最小字段集合。如果以后决定向报表或SOQL查询添加字段,则必须联系Salesforce客户支持以重新创建表。

细小的表格不会被复制到沙箱组织中. 此限制可能不是您的问题,但要保持生产环境和沙箱环境的一致性,您必须跟踪更改并与Salesforce客户支持部门协作,以保持环境同步。

紧缩表是基础Force.com数据库中的自定义表. 它们没有在基础对象中找到的动态元数据灵活性。如果更改字段类型(例如,将数字字段更改为文本字段),那么瘦客户表变得无效,并且您必须联系Salesforce客户支持以创建新的瘦客户表。

现在您已经有几个工具可以加快涉及大数据量的搜索,请继续下一个单元以减少数据加载。

Apex 大数据处理(1)数据模型

学习目标

完成本单元后,您将能够:

  • 为大数据量设计一个数据模型。
  • 描述三种类型的数据倾斜以及如何避免它们。
  • 数据模型以包含外部对象。

规划你的数据模型

数据是任何应用程序的关键元素之一。用户不断创建数据。日积月累。突然间,您的组织已经累积了数百万条记录,数千个用户和数千兆字节的数据存储。

这些大数据量(LDV)可能导致性能下降,包括查询速度较慢,搜索和列表视图较慢以及沙箱刷新速度较慢。如果您计划先行调整LDV,则可以避免这种困境,从一开始就设计您的数据模型以构建可扩展性。

数据倾斜的独家新闻

管理大数据量以获得最佳性能的关键在于仔细设计记录所有权以避免数据倾斜。如果超过10,000个子记录与组织内的同一父记录相关联,则会发生数据倾斜。

使用足够的客户规划数据模型,以将每个父级的子级记录数保持在此阈值以下,并在创建这些客户时分配新的子级记录。如果您不使用这些策略,则会出现三种类型的数据倾斜,并会对性能产生负面影响:客户数据倾斜,所有人倾斜和查找倾斜。

客户数据偏差

某些Salesforce对象(如客户和机会)具有特殊的数据关系,可以在私有共享模型下维护父子记录访问。在这些关系之一中与同一父对象关联的子记录太多会导致客户数据倾斜。假设您有一堆未分配的联系人,并将其放在名为“未分配”的一个客户下。这可能会造成记录锁定和共享性能方面的问题。

记录锁定

以下是另一种情况:您正在多个线程中更新同一客户下的大量联系人。对于每次更新,系统都锁定要更改的联系人及其父客户,以保持数据库中的完整性。即使每个锁都保持很短的时间,因为所有的更新都试图锁定同一个客户,所以更新失败的风险很高,因为前一个锁仍然持有该客户的锁。

共享问题

谈到共享,也有类似的动态。根据您配置的共享方式,当您做一些看起来很简单的事情时,比如更改客户的所有者,您可能需要检查每个客户的子记录并调整其共享。这可能包括重新计算角色层次和共享规则。如果我们谈论成千上万的子记录,可能会吃掉很多时间。

所有权倾斜

当具有相同对象类型的大量记录属于单个用户时,这种不平衡会导致所有权倾斜。由于每个记录都需要拥有一个所有者,所以似乎自然的解决办法是将这些记录倾斜到一个通用所有者上,例如前面提到的“未分配”。但是这可能会导致性能问题,因为共享计算需要管理这些记录的可见性。

当角色层次结构中存在倾斜所有者时,像删除或所有者更新这样的操作必须从角色层次结构中的旧所有者和所有父用户以及共享规则访问的所有用户中移除共享。这就是为什么所有权变更往往是系统中成本最高的交易变更之一。

在某些情况下,所有权倾斜根本无法避免。在这些情况下,最好确保倾斜的所有者没有角色。这样,您就可以将用户及其记录从角色层次结构及其关联的共享规则中分离出来。

查找倾斜

当大量记录与查找对象(您正在搜索的对象)中的单个记录相关联时,会发生查找倾斜。因为您可以将查找字段放在Salesforce中的任何对象上,所以查找偏斜可能会为组织中的任何对象创建问题。

如果最终发现查询偏斜并且具有非常复杂的自定义实现,那么您可能会在没有意识到的情况下创建问题。通过仔细考虑管理查找倾斜的选项,您可以避免锁定查找字段的问题,以确保您的架构可以扩展以满足您的组织成长。

是什么让查找偏斜如此糟糕? Salesforce中的查找字段实质上是对象之间的外键关系。每次插入或更新记录时,Salesforce都必须锁定为每个查找字段选择的目标记录。这确保了当数据被提交到数据库时,其完整性得以保持。

在正常情况下,保存操作执行得如此之快以至于您不会遇到锁定。但是,当您在自动化进程中同时添加自定义代码和LDV时,您可能会遇到锁定异常,当您尝试插入或更新记录时会导致失败。

由于没有任何专门用于识别查找偏斜的工具,查找这些架构问题可能就像在大海捞针一样。请注意,在某些使用模式下,查找偏移可能根本不会导致任何问题,因此最好根据会导致问题的模式进行搜索。您应该评估具有大量记录的对象以及大量的并发插入和更新活动。

使用外部对象

LDV的另一个策略是使用外部对象 – 这意味着不需要将数据带入Salesforce。通过数据分层策略,将数据分散到多个对象中,并根据需要从另一个对象或外部存储中提取数据,避免在组织中存储大量数据,并避免与LDV相关的性能问题。

外部对象与自定义对象类似,只不过它们映射到存储在Salesforce组织外部的数据,使用户和Force.com平台可以搜索外部数据并与之交互。

通过按需访问记录数据,外部对象总是反映外部数据的当前状态。您不必在Salesforce中管理该数据的副本,因此您不会浪费存储和资源来保持数据同步。如果您有大量数据无法或不想存储在Salesforce组织中,则最好使用外部对象,并且您只需要在任何时候使用少量的数据。

外部数据源指定如何访问外部系统。 Salesforce Connect使用外部数据源来访问存储在Salesforce组织外部的数据。 Files Connect使用外部数据源访问第三方内容系统。外部数据源具有关联的外部对象,您的用户和Force.com平台用于与外部数据和内容进行交互。

外部对象查找

外部对象支持标准的查找关系,它使用18个字符的Salesforce记录标识将相关记录相互关联。但是,存储在Salesforce组织外部的数据通常不包含这些记录标识。因此,外部对象有两种特殊类型的查找关系:外部查找和间接查找。

这些外部查找和间接查找将父对象上的特定字段的值与子对象上的关系字段的值进行比较。当值匹配时,记录是相互关联的。

父级是外部对象时使用外部查找关系。外部查找关系将子标准,自定义或外部对象链接到父级外部对象。父外部对象上的标准外部标识字段的值与外部查找关系字段的值相匹配。对于子外部对象,外部查找关系字段的值来自指定的外部列名称。

外部数据不包括Salesforce记录标识时,请使用间接查找关系。间接查找关系将子外部对象链接到父标准或自定义对象。在外部对象上创建间接查找关系字段时,指定父对象字段和子对象字段以相互匹配,在父对象上选择一个自定义的唯一外部ID字段以匹配子对象的间接查找关系字段,其值由指定的外部列名决定。

以下是可用于外部对象的关系类型的细分:

关系 允许的子对象 允许的父对象 父字段匹配记录
Lookup 标准
自定义
外部
标准
自定义
18个字符的Salesforce记录标识
外部查询 标准
自定义
外部
外部 外部ID标准字段
间接查询 外部 标准
自定义
您选择具有外部ID和唯一属性的自定义字段

现在,当您为大数据量构建组织架构时,您应该牢记(避免)关键事项。 您可能还需要聘请Salesforce Strategic Services的架构师来帮助您设计管理初始配置和增长的最佳方法。 在下一个单元中,我们将LDV查询和搜索放入混合中。