salesforce零基础学习(九十九)Salesforce Data Skew(数据倾斜)

本篇参考:

https://developer.salesforce.com/blogs/engineering/2013/04/managing-lookup-skew-to-avoid-record-lock-exceptions.html

https://developer.salesforce.com/blogs/engineering/2012/04/avoid-account-data-skew-for-peak-performance.html
https://developer.salesforce.com/blogs/engineering/2012/06/architect-salesforce-record-ownership-skew-for-peak-performance-in-large-data-volume-environments.html

性能以及稳定性对于一个系统来说是至关重要的。 今天说的是数据Lookup倾斜我们在一个系统中,表和表的关系不可能是完全独立的存在,有关系就要创建其关联, lookup也好, MD也好。有些表作为主数据,数据量可能很庞大,Lookup数据倾斜简单的定义可以理解为,当一条记录有10K条同个表记录进行关联情况下,便会很影响性能,变成一个沉默的杀手,看不出来程序配置哪里有问题,但是可能出现崩溃或者性能堪忧的风险。

举几个例子更好的去理解一下:
符合 Lookup Data Skew
1. 一条顾客数据,绑定了超过10000的案件数据;
2. 一个自定义表,绑定了超过10000条他的子表的数据;
不符合 Lookup Data Skew
1. 一个user,拥有10000条记录。(之所以不属于原因是 要求同一个表,如果一个 user拥有10000条顾客或者案件记录则符合)

lookup skew通常可以分成三个类型:

  • Account Data Skew:某些Salesforce对象,如Account和 Opportunity,在 sharing model 是private情况下,维护父子数据访问会有一个特殊的数据关系,如果同一个 account记录拥有太多的Opportunity记录,则容易产生 account data skew从而导致性能的风险;
  • Ownership Skew:当一个user针对同一个表拥有超过10K的数据,在管理 role hierarchy 和 sharing rule场景下就很容易造成 ownership的倾斜
  • Lookup Skew:当具有lookup关系的两个表,一个父表的数据如果关联了超过10K的这个子表的数据,则造成了 lookup skew。

上面的内容都是概念性描述,那么在我们实际场景中是否出现过因为lookup skew导致的问题呢,这样才能让我们能更好的知道为什么 lookup skew如此堪忧?

最常见的场景:unable_to_lock_row。根据salesforce 数据DML的原理,当一个子表进行DML(这里通常使用 insert / update)时,需要先锁定父表,然后进行子表的DML操作,当子表的记录操作完成,会解锁父表记录,然后下一条记录来了,锁定它这条记录的父表,然后进行相同的后续操作。
如果一个父表绑定了太多的同一个子表的数据,则容易造成 unable_to_lock_row的情况,这种事情偶发存在,可能重新执行就通过。客户出现这个问题,提case,作为开发人员修改也是很痛苦的事情。

针对这种情况如何去处理呢?大概有几种处理方式(不一定齐全,可以参看上方文档)

1. 针对 Account Data Skew尽量做到多建几个子 account,通过 parent account形成关联关系以后,将数据进行分发,从而减少每条account绑定的数量;

2. 针对 ownership skew,尽量做到user不存在 role或者在 role hierarchy最上层,这样在 role hierarchy变更情况下,不用有share的性能风险。

总结:Data Skew在设计上是一个很重要的一环,它会影响你的 sharing 性能以及系统稳定性。篇中只是简单介绍了概念以及常用情况的处理方式,具体的细节还请参看上方的文档。篇中有问题欢迎指出,有不懂欢迎留言。

发表评论

评论已关闭。

相关文章