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

大量数据部署对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. 让系统内存在的有效数据尽可能少

Salesforce 大量数据部署的最佳实践的更多相关文章

  1. Asp.NetCore程序发布到CentOs(含安装部署netcore)--最佳实践(二)

    Asp.NetCore程序发布到CentOs(含安装部署netcore)--最佳实践(一) 接上一篇 3. Nginx配置反向代理 3.1 cnetos 安装nginx 首先,我们需要在服务器上安装N ...

  2. Asp.NetCore程序发布到CentOs(含安装部署netcore)--最佳实践(一)

    环境 本地 win7 服务器:Virtual Box 上的Centos ssh工具: Xshell 文件传输: xftp 1.在本地创建asp.net core应用发布 1.1 使用Vs2017 新建 ...

  3. Asp.NetCore程序发布到CentOs(含安装部署netcore)--最佳实践

    原文:Asp.NetCore程序发布到CentOs(含安装部署netcore)--最佳实践 环境 本地 win7 服务器:Virtual Box 上的Centos ssh工具: Xshell 文件传输 ...

  4. 【翻译】ScyllaDB数据建模的最佳实践

    文章翻译自Scylla官方文档:https://www.scylladb.com/2019/08/20/best-practices-for-data-modeling/ 转载请注明出处:https: ...

  5. 掌握OpenStack部署的最佳实践 打破部署失败的魔咒

    部署OpenStack环境并不是一项简单的任务:根据SUSE最近的调查显示“曾经部署过OpenStack的企业当中有一半都失败了”.然而,随着最佳实践的出现,企业可以使用其避免在部署OpenStack ...

  6. Mongo实战之数据空洞的最佳实践

    问题背景: 某天,开发部的同事跑过来反映: mongodb数据文件太大,快把磁盘撑爆了!其中某个db占用最大(运营环境这个db的数据量其实很小) 分析: 开发环境有大量测试的增/删/改操作,而由于Mo ...

  7. Kafka数据迁移MaxCompute最佳实践

    摘要: 本文向您详细介绍如何使用DataWorks数据同步功能,将Kafka集群上的数据迁移到阿里云MaxCompute大数据计算服务. 前提条件 搭建Kafka集群 进行数据迁移前,您需要保证自己的 ...

  8. Springboot 配置文件、隐私数据脱敏的最佳实践(原理+源码)

    大家好!我是小富- 这几天公司在排查内部数据账号泄漏,原因是发现某些实习生小可爱居然连带着账号.密码将源码私传到GitHub上,导致核心数据外漏,孩子还是没挨过社会毒打,这种事的后果可大可小. 说起这 ...

  9. Salesforce 超大量数据导入优化策略

    本文参考自以下系列文章: 1 2 3 4 5 6 超大量数据导入优化策略 Salesforce和很多其他系统都可以很好的协作.在协作过程中,数据的导入导出便成为了一个关键的步骤. 当客户的业务量非常大 ...

随机推荐

  1. 一些能体现个人水平的SQL语句[总结篇]

    作为一名小小的开发人员,刚入门的时候觉得很难,过了一段时间之后,发现很简单,很快就可以搞定很bug了.然而这并不能说明你就已经很牛掰了,只能说,你不了解其他太多的东西.应该说,数据库有几个共同的命令, ...

  2. 多线程 start 和 run 方法到底有什么区别?

    昨天栈长介绍了<Java多线程可以分组,还能这样玩!>线程分组的妙用.今天,栈长会详细介绍 Java 中的多线程 start() 和 run() 两个方法,Java 老司机请跳过,新手或者 ...

  3. (webpack系列二)webpack打包优化探索

    虽然webpack的已经升级到了webpack4,而我们目前还在使用webpack3,但其中的优化点都大同小异,升级后同样适用. 性能优化初步原则 减小代码量 减小请求数 最大化利用浏览器缓存 这三条 ...

  4. 整理了一周的Python资料,包含各阶段所需网站、项目,收藏了慢慢来

    这周应该有不少学校已经开学了,那么同学们都该动起来了,把家里面的那些懒习惯给扔掉了可以. 不知怎么的,最近不少关注我的读者都开始私信我怎么学好python?零基础转行是不是合适,还有希望吗?今年30了 ...

  5. JSON库的使用研究(二)

    Java 中哪个 JSON 库的解析速度是最快的? 这个问题有意义吗?各个JSON库的性能差距不大?呵呵,差距大不大,自己往下看吧! 这个问题我们应该分为以下四个维度进行研究: 1.序列化 2.反序列 ...

  6. 百度翻译爬虫-Web版(自动生成sign)

    # 面向对象 # 百度翻译 -- 网页版(自动获取token,sign) import requests import js2py import json import re class WebFan ...

  7. python自动化工具之pywinauto(一个实例)结合pyuserinput

    以下是pywinauto使用指南.这个窗口句柄可以在Spy++中查看 (Microsoft Spy++(查看窗口句柄) 10.00.30319 官方最新绿色版) python自动化工具之pywinau ...

  8. SpringCloud学习6-如何创建一个服务消费者consumer

    上一节如何创建一个服务提供者provider已经启动了一个provider的server,提供用户信息查询接口.接下来,我们启动另一个provider,由于是同一台机器本地测试,我们换一个端口 --s ...

  9. 五分钟轻松了解Hbase面向列的存储

    说明:从严格的列式存储的定义来看,Hbase并不属于列式存储,有人称它为面向列的存储,请各位看官注意这一点. 行式存储 传统的数据库是关系型的,且是按行来存储的.如下图: 其中只有张三把一行数据填满了 ...

  10. 浅谈SpringAOP

    0. 写在最前面 之前实习天天在写业务,其中有一个业务是非常的复杂,涉及到了特别多的表.最后测下来,一个接口的时间,竟然要5s多. 当时想写一个AOP,来计算处理接口花费多长时间,也就是在业务逻辑的前 ...