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在每次数据库读取时返回更多的行，从一个大对象读取时增加吞吐量，如下图所示：

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

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

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

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

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

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

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

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