Parent-Child Data Skew

 Hi,

Let's learn about Parent-Child Data Skew.

A common configuration that can lead to poor performance is the association of a large number of child records (10,000 or more) with a single parent account. 

Eg: A customer can have tens or hundreds of thousands of contacts generated by marketing campaigns or purchased from mailing lists—without any association to formal business accounts. If contact is required to have an associated account, what should an administrator do? It might be convenient to park all those unallocated contacts under a single dummy account until their real business value and relationship can be determined.

While this option seems reasonable, this kind of parent-child data skew can cause serious performance problems in the maintenance of implicit sharing.

Problem #1: Losing Access to a Child Record Under a Skewed Account

Assume that we have 300,000 unallocated contacts all under the same account. A user with access to one of these contacts will also have a parent implicit share in the account sharing table that gives him or her access to that account. Now, what happens if that user loses access to the contact?

In order to determine whether to remove his or her sharing to the account, Salesforce needs to scan all of the other 299,999 contacts to ensure that the user doesn’t have access to them either. This practice can become expensive if Salesforce is processing a lot of visibility changes on these highly skewed accounts.

Problem #2: Losing Access to the Skewed Parent Account

Consider the opposite scenario: The user has access to all 300,000 contacts because of his or her access to their parent account. What happens when the user loses access to the account?

This situation is not as problematic because the user must lose access to all the child records. Salesforce can query that list very quickly, but if there are very many child records, it might still take substantial time to delete all the relevant rows from the sharing tables for all the child objects.

Configuring a severe data skew on an account can also cause issues when customers make large-scale changes in sharing or realign sales assignments in Territory Management.

Eg: If the account is part of the source group for a sharing rule, and the administrator recalculates sharing on accounts, the work required to adjust the child entity access for that one account can cause the recalculation to become a long-running transaction or, in extreme cases, to fail altogether. Similar problems can occur when a territory realignment process attempts to evaluate assignment rules for a skewed account.

Reference:

https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_object_relationships_parent_child_data_skew.htm?search_text=Skew