Data Skew: bloqueos y pérdida de rendimiento con GRU y los Minions

(Actualización 11/12/2018:  realizé una presentación en el evento, Barcelona Dreamforce Global Gathering 2018, donde expuse la problemática de Data Skew. Para la explicación, utilizé analogías con Gru y los Minions, y dado su buen recibimiento he creído necesario actualizar este artículo y el uso de las analogías que utilicé).

Sucede habitualmente que podemos tomar decisiones para gestionar nuestros datos, que disfrazadas de buenas ideas, pueden perjudicar el rendimiento e incorporan incidencias importantes. Estas han sido detectadas en muchas ORGs y reciben el nombre de Data Skew.

En este artículo, con la ayuda de GRU y los Minions, veremos estos 3 tipos de Data Skew:

1. Ownership Skew
2. Implicit Sharing Data Skew
3. Lookup Skew

Veremos qué son, por qué suceden y cómo podemos evitarlos.

Introducción

Para entender la problemática, debemos conocer el funcionamiento interno de la plataforma, y así entenderemos como usarla correctamente  adecuadamente, para que funcione según se diseñó.

Para entender Data Skew debemos recordar 3 básicos de la plataforma:

1. Comprobación del acceso a datos en tiempo mínimo
2. Actualización de datos siempre consistente
3. Implicit Sharing

Comprobación del acceso a datos en tiempo mínimo

Como todos sabemos, y a grandes rasgos, el acceso a los datos en Salesforce viene determinado por:

• Profiles: define el Object Level Access indicando si un usuario tiene acceso a un objeto, qué campos de ese objeto y las acciones CRED que puede llevar a cabo
• Sharing Model: nos permite definir a qué registros tienen acceso los usuarios no propietarios,  y ampliar el acceso mediante mecanismos como OWD, Role Hierarchy, Territory Hierarchy, Sharing Rules, Teams, Manual Sharing y mediante código APEX.

Para determinar si en cada operación de lectura/escritura/borrado el usuario tiene acceso a los registros, campos, etc., y hacerlo en los 300 mili segundos, que es el objetivo de la Salesforce, no es posible realizar los cálculos al vuelo. En su lugar, se realizan estos cálculos previamente y se almacena toda la información resultante en tablas internas, para que sólo sea necesaria consultarla.

Aunque no es objetivo de esta entrada, te animo a que consultes la documentación (enlaces al final del artículo) sobre:

1. Object Record Tables
2. Object Sharing Tables
3. Group Maintenance Tables

De esta manera, con pocas consultas sobre esas tablas, Salesforce obtiene los registros a los que tiene acceso el usuario, con qué nivel de acceso, y sus campos.

Estas tablas contienen todas las combinaciones posibles para todos los usuarios en jerarquías, grupos, etc., y de su mantenimiento y correcto funcionamiento, es en lo que se basa Salesforce para que no se produzcan accesos no permitidos a información, y por tanto son clave del éxito de Salesforce, y por lo que sabemos, con muy buen resultado.

Actualización de Datos siempre consistente

Cuando actualizamos datos en entidades relacionadas, y como sucede en la mayoría de gestores de bases de datos, al actualizar un registro de la entidad hijo, la plataforma realiza un bloqueo temporal del registro padre.

Este bloqueo se realiza para que los datos durante la inserción sean consistentes, y por ejemplo, no añadamos un Contact a una Account que alguien acaba de borrar. Este bloqueo es muy breve en el tiempo, pero ciertamente existe y es necesario también en Salesforce.

Este concepto se denomina Implicit Sharing en Salesforce.

Compartición Implícita (Implicit Sharing)

A parte de las capacidades de compartir que tenemos en la plataforma, Salesforce realiza una compartición interna cuando el objeto Account se relaciona con Opportunities, Cases y Contacts.

1. Cuando se establece una relación con Account como padre, la plataforma proporciona al usuario Owner de la Opp/Case/Contact, acceso de lectura sobre la Account para que pueda acceder a sus datos.
2. Con la misma relación anterior, el Owner de la Account obtiene acceso de lectura a todos los hijos de la relación, como por ejemplo para definir un campo RollUp

Introducidos los conceptos básicos del funcionamiento de Salesforce, veamos en qué situaciones anómalas nos podemos encontrar y sus causas.

Tipos de Data Skew

A continuación describo como son los síntomas y los motivos de estas situaciones.

1. Ownership Skew

Si tenemos centenares de miles de Minions como Contacts asociados a la única Account que es GRU, tenemos un claro ejemplo de Ownership Data Skew.

Data Skew Ownership

Las situaciones son las siguientes:

• • Cada inserción/actualización de un Minion, supone el bloqueo de la Account de GRU. En una operativa habitual, esto no supone ningún problema, dado que el bloqueo, dura una fracción de segundo, pero ante una carga/actualización masiva de Minions, las actualizaciones intentarán bloquear la misma Account y por tanto, estarán compitiendo por el bloqueo, hasta provocar errores de UNABLE_TO_LOCK_ROW, si se superan los 10» de margen.

• • La situación, se agrava, cuando GRU pertenece a una organización criminal y plasmamos esta organización mediante la Jerarquía de Roles. Si GRU, no es el jefe supremo de esta organización, tendrá un Rol intermedio (en el peor de los casos será un empleado de último nivel jerárquico).
    Cada vez que GRU, promocione o sea degradado en la organización, se realizará un movimiento en la Jerarquía, lo que provocará que la plataforma deba realizar un recálculo de acceso, para eliminar la autorización de sus jefes que ya no lo son, y proporcionar acceso a  los que pasan a serlo. Dado que GRU, tiene una cantidad elevada de registros de Minions asociados, el recálculo será costoso y duradero, dado que la plataforma bloqueará gran cantidad de registros para que no se produzcan modificaciones durante el proceso y se produzcan inconsistencias en los datos (por ejemplo borrado de un Minion). Cualquier otro proceso que intente actualizar los registros bloqueados recibirá un error de bloqueo: UNABLE_TO_LOCK_ROW si se superan los 10».

• Supongamos que en un caso infortunado, GRU pierde toda autoridad sobre los Minions y pasa a ser otra Account la propietaria de todos ellos (un cambio de Owner). En este caso, el recálculo es aún más costoso y duradero, dado que inicialmente hay que eliminar todas las herencias que hubiera provocado su posición en la jerarquía, y hay que calcular todas las nuevas comparticiones para el nuevo propietario.

Posibles Soluciones

Todas las soluciones a continuación, solo alivian parcialmente el problema, pero no lo eliminan. Para eliminar el Data Skew de forma completa deberemos eliminar el Skew de forma completa (muerto el perro muerta la rabia).

Si esto no es posible, podemos optar  por:

• • Intentar que los Minions se repartan entre varios jefes: GRU, Lucy, el profesor Nefario, etc. No solventa el problema, pero alivia la situación dado que se bloquearán más jefes en el mismo tiempo, disminuyendo el tiempo que un sólo jefe está bloqueado.

• • Que GRU no forme parte de una organización criminal y por tanto no tenga un Rol asociado. 

• • Si GRU debe pertenecer a una organización criminal, debe tener un Rol,  que esté lo más arriba en la jerarquía posible, disminuyendo así el tiempo de recálculo, dado que tendrá pocos superiores.

• Usar la funcionalidad de Granular Locking para evitar el recálculo después de la actualización de los datos.

Para los usuarios de Portal, sucede exactamente análogo, cuando una Account tiene muchos registros asociados, si se produce un cambio en el Owner de la Account, el proceso de recálculo será costoso e incluso duradero.

2.Implicit Sharing Data Skew

Para entender la segunda situación de Data Skew, debemos recordar el concepto de Implicit Sharing de Salesforce, introducido al principio de este artículo.

Implicit Sharing Data Skew

Cuando Lucy, compañera de GRU, va ganando su confianza, GRU considera necesario que ella también pueda gestionar a los Minions. Por eso, GRU comparte inicialmente 5000 Minions con Lucy, manteniéndose él como Owner.

Por el mecanismo de Implicit Sharing, Lucy, no sólo tiene acceso a 5000 Minions, sino que tiene acceso a la cuenta de GRU (es decir, como los Minions son Contacts, mediante Child Implicit Sharing, Salesforce le proporciona acceso de lectura a la Account de GRU).

Desafortunadamente, en uno de sus espectaculares robos, algunos Minions son capturados por los enemigos, y GRU pierde su propiedad.

En este momento se produce la siguiente problemática: ¿Debe seguir Lucy teniendo acceso a la Account de GRU dado que los registros hijos que daban acceso han cambiado de Owner? Para ello, la plataforma, deberá en el peor de los casos, revisar todos los registros de Contact a los que tiene visibilidad Lucy, para encontrar si algún otro aún le proporciona el acceso a la Account. Para realizar esta comprobación, la plataforma bloquea, todos los Contacts de Lucy y la Account de GRU, para evitar modificaciones de datos que pudieran adulterar el resultado.

Durante este proceso, no es posible por tanto realizar actualizaciones o inserciones de nuevos Minions con propietario GRU, dado que está siendo bloqueado por el proceso de búsqueda y recálculo.

3. Lookup Skew

El tercer caso de Skew Data, consiste en una idea, que inicialmente nos parece muy adecuada para gestionar nuestros datos, pero que realmente es un mala práctica.

Dado que los Minions comparten 5 cortes de pelo, el usuario de nuestra ORG quiere clasificarlos mediante corte de pelo. Para ello se decide, crear un nuevo Custom Object CortePelo__c, que contendrá el maestro de cortes de pelo, para que posteriormente podamos reportar, listar, etc., con total versatilidad.

Al objeto Contact, por tanto le creamos un campo Lookup hacia nuestro nuevo Custom Object. Y realizamos una modificación de datos, para otorgar a cada Minion su corte de pelo.

Acabamos de producir, el tercer tipo de Data Skew, denominado Lookup Data Skew.

Veamos que sucede en la inserción de un nuevo Minion:

• Al insertar un nuevo Minion, la plataforma bloqueará el registro correspondiente al tipo de pelo del Minion en el objeto CortePelo__c
• Este bloqueo temporal muy reducido no supone ningún problema durante una única actualización, pero supongamos que la inserción es masiva para actualizar alguna característica de todos los Minions

Existirá competencia para el bloqueo del registro del Custom Object, y dado que la inserción es masiva, se producirán errores de UNABLE_TO_LOCK_ROW nuevamente.

Posibles soluciones

La solución que alivia esta situación consiste en usar una Picklist en lugar de un Custom Object, con los registros de corte de pelo.

Conclusiones

Según cuantifica Salesforce estas situaciones se producen a partir de relaciones de 1:10.000, con lo que muchos de nuestros proyectos se pueden fácilmente ver afectados.

Lo más importante de estas situaciones, creo que es conocer como Salesforce gestiona 2 aspectos fundamentales:

1. La gestión de la visibilidad de los datos en sus estructuras internas
2. El proceso de actualización de registros mediante bloqueos

Es por ello, que si te interesa el tema, en la siguiente entrada podrás obtener una herramienta para la detección de Skew Data en tu ORG totalmente open source, con la que te enseño cómo hacerlo.

Espero que te sea de  ayuda.

Enlace interesantes

• Sharing Rows under de hood
• Designing Record Access for Enterprise Scale
• Reducing Lock Contention by Avoiding Account Data Skew
• Avoid Account Data Skew for Peak Performance
• Managing Lookup Skew in Salesforce to Avoid Record Lock Exceptions
• Architect Salesforce Record Ownership Skew for Peak Performance in Large Data Volume Environments
• Record Locking Cheat Sheet

Anuncio publicitario