Salesforce 大量数据部署的最佳实践

本文参考自官方文档。原文链接

大量数据部署对Salesforce的影响

当用户需要在Salesforce中部署大量数据的时候，部署的过程往往会变慢。这时就需要架构师或开发者设计出更好的过程来提高大量数据的部署效率。

多租户架构和元数据

Salesforce使用元数据驱动机制来实现多租户架构。

不同于传统的关系数据库，Salesforce中对每个“租户”系统内部的数据结构并没有相对应的数据表。Salesforce中使用统一的数据结构来保存各个“租户”系统内部数据结构的定义，这就是元数据。

Salesforce自己拥有一套通用的数据表，将所有“租户”系统中的对象、字段、索引、数据、关系等作为元数据分别保存到相应的表中。

在某“租户”系统运行时，Salesforce会从这套通用数据表中取出该“租户”系统拥有的对象、字段等，动态编译成一个虚拟的数据库，其中只包含该“租户”系统中的数据和结构。

通过这样的机制，Salesforce可以高效的保存多租户的内容（只使用一套数据结构），让各个“租户”的内容保持相互独立，互不影响，易于修改（动态编译数据结构）。

搜索机制

Salesforce中所有可搜索的数据都必须拥有索引。

在一条数据被创建之后，系统会自动将其中可以被搜索的内容（比如各种字符串数据）进行归类索引。这个过程需要花费一定的时间，所以在记录被创建以后可能无法马上被搜索到。最长的等待时间可以达到15分钟。

在执行搜索时，Salesforce会首先对这些索引进行搜索，然后使用诸如用户权限、搜索数量限制等条件对于搜索结果进行过滤，创建一个结果集（result set）。结果集中保存的是最符合搜索条件的数据。最后Salesforce将结果集中对应的数据在数据库中进行查询，从而返回用户需要的字段等信息。

大量数据相关机制和最佳实践

Salesforce中针对大量数据处理设计了不同的机制来提高效率。

Force.com查询优化器（Force.com Query Optimizer）

查询优化器是Salesforce内置的工具，对于报表、列表视图、SOQL查询语句、搜索操作进行优化，计算出最优的搜索方式。

它会遵循以下几点进行优化：

1. 寻找最符合查询语句的索引。如果查询语句中拥有过滤条件，则过滤条件优先被考虑作为查询的索引。
2. 寻找最符合的数据表。
3. 对被查询的数据表进行排序，使得查询的开销尽可能小。
4. 引用外键定义来创建最有效的联合（JOIN）操作。
5. 更新数据库统计数据。

数据库统计数据（Database Statistics）

数据库统计数据是对于数据库中数据的统计。基于数据的种类、数量，查询操作可以选择出最有效率的进行方式。

SOQL 和 SOSL 对比

SOQL 是类似于 SQL 的查询语句，而 SOSL 是全文检索查询。

当我们确定被查询的文本存在于某个字段中，使用 SOSL 的速度要优于 SOQL。

与此同时，在一个 Apex 事务（Transaction）的执行中，SOSL 查询的记录上限是2000，而 SOQL 是50000。

批量查询方法

使用 Batch Apex 可以查询高达50,000,000条记录，但是它并不一定适合所有的情景。

使用 Bulk API 可以查询多达 15GB 的数据，它们会保存在15个 1GB 的文件中。

Bulk API 的查询超时时限是2分钟。如果成功进行了查询，但是在返回结果的过程中用时超过10分钟，或者数据文件大小超过了 1GB，那么 Salesforce 会将当前的结果缓存起来，然后重试。当失败15次以后，才会返回错误信息。

主键分块（PK Chunking）查询

主键分块查询是 Bulk API 提供的一个选项。

对于千万级的数据，普通的查询优化可能已经没法将查询结果限制在一定的数量范围。这时，使用主键分块会优化查询。

每条数据都有主键，也就是ID，在整个系统中是唯一的值，也是索引字段。

使用主键分块查询，系统会自动将数据依据主键的值分块，每块包含的数据量默认是10万条。用户可以设置每块的数据量，最大不超过25万条。在分块之后，系统会对每块进行分别查询，从而将本来很大的数据表分解成无数的小块，同时进行查询，提高了效率。

精简数据表（Skinny Tables）

Salesforce中将所有对象的标准字段和自定义字段分别存储于两张表中。在对这些对象进行查询操作的时候，就必须对这两张表进行联合（JOIN）操作。而联合操作会提高查询的开销。为了提高这些效率，Salesforce引入了精简数据表机制。

精简数据表是一个单独的表，其中存储着若干标准或自定义字段的值，但并不包括被“软删除”的那些。精简数据表相当于存储了已经进行了联合操作的字段和内容，从而可以更有效率地支持前台的查询。

精简数据表的一些特性：

• 一个精简数据表最多可以包含100个字段（列）。
• 每一个精简数据表都对应一个对象，所以其包含的字段必须属于此对象，不能有其他对象的字段。与此同时，也不能有公式（formula）字段和查找（look up）字段。
• 精简数据表会被拷贝到完整沙盒（Full sandbox）中，但不会被拷贝到其他类型的沙盒中。如果想要拷贝到其他类型的沙盒，必须通过Salesforce的客户支持帮助。
• 精简数据表必须要通过Salesforce的客户支持来启用。

索引字段

索引字段最多的被用于数据库的查询语句。Force.com的查询优化器对于标准和自定义的索引字段有着不同的规定。

• 对于标准索引字段，查询结果必须在前100万条记录中有少于30%的符合率，并且在余下最多100万条记录中有少于15%的符合率。否则该索引不会被查询语句所使用。
• 对于自定义索引字段，查询结果必须在所有记录中有少于10%的符合率，查询结果最多为333333条记录。否则该索引不会被查询语句所使用。

与此同时，Force.com的查询优化器对WHERE语句中的AND、OR条件有着单独的规定。

• 对于AND条件中使用的索引字段，其返回的查询结果必须少于总记录数的20%，并且不超过66666条。
• 所有在OR条件中使用的字段必须是索引字段。对于这些索引字段，其返回的查询结果必须少于总记录数的10%，并且不超过333333条。

SOQL和SOSL语句中的null值

在查询语句中，要尽量避免在WHERE条件中判断null值。

比如下面的查询语句（伪代码）：

SELECT Name FROM Account WHERE Account_ID__C = :acctid;


如果变量acctid为null，则整个Account表都会被搜索，严重降低了查询效率。

可以改写为：

if (acctid != null) {
SELECT Name FROM Account WHERE Account_ID__C = :acctid;
} else {
...
}


SOQL和SOSL语句中的公式字段

在查询语句中，要尽量避免在WHERE条件中以公式字段（Formula）作为过滤条件。

这么做的原因是公式字段的值总是在被引用的时候即时计算的，并且在不经过 Salesforce 客服的帮助下是不能做索引的。所以如果以公式字段作为过滤条件，查询的速度会非常慢。

查询的最佳实践原则

总结起来，进行数据查询的最佳实践原则有两条：

1. 为查询语句增加过滤条件，从而使查询过程涉及的数据尽可能少
2. 让系统内存在的有效数据尽可能少