Data Skew: bloqueos y pérdida de rendimiento – cuáles son y cómo evitarlos

…y llega un día en que nuestras cargas de datos masivas, cambios en la jerarquía de roles que hasta ahora habían ido bien, se ralentizan y aparecen mensajes de bloqueo de registros.

Tanto los administradores como los desarrolladores decimos que no hemos tocado nada, y siendo cierto, vemos que algo está pasando.

Resulta que nuestra ORG sufre de ciertos patrones de uso en sus datos, que disfrazado de buenas ideas, irán perjudicando el rendimiento e incorporando incidencias.

La fuente de estos problemas pueden ser:

  1. Ownership Skew
  2. Parent-Child Data Skew
  3. Implicit Sharing Data Skew
  4. Lookup Skew
  5. Indisponibilidad de bloqueo en cambios deJerarquías o Grupos

En esta primera entrada, explicaré qué son, por qué suceden,  cómo podemos evitarlos.

Si no los conoces, te recomiendo esta lectura, sirve para cualquier administrador, desarrollador, y consultor de negocio.

Introducción

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

Acceso a Datos asegurando la visibilidad y seguridad

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 no Owners y ampliar el acceso mediante mecanismos como OWD, Role Hierarchy, Territory Hierarchy, Sharing Rules, Teams, Manual Sharing y mediante código APEX para ampliarlo.

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

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 a qué registros tiene acceso el usuario, con qué nivel de acceso, y los campos accesibles.

Estas tablas contienen todas las combinaciones posibles para todos los usuarios en jerarquías, grupos, etc., y de su mantenimiento depende que no se produzcan fugas de información a usuarios que no debieran verla, por tanto son clave del éxito de Salesforce, y lo hace realmente bien.

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.

Compartición Implícita (Implicit Sharing) para Accounts

A parte de las capacidades de compartir que tenemos los usuarios de 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, y por ejemplo definir un campo RollUp
  3. Con la situación análoga, es decir, acceso a los hijos de lectura para el padre, y de lectura del padre para los Owners de los registros hijos en Portal, High Volume respectivamente

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

Síntomas de situaciones anómalas

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

1. Ownership Skew

Mala práctica

Sucede cunado tenemos más de 10.000 registros asociados al mismo Owner en el mismo objecto. Este owner puede ser un usuario, una queue, etc.

Esta situación puede ser muy habitual en Leads, Contacts, Account, o cualquier otro objecto, que dejamos a un owner ficticio, para tratar posteriormente o indicando que se obtuvo de tal o cual manera, etc.

Situaciones anómalas

  • Al mover este usuario en una jerarquía se bloquea el acceso a esos registros durante un largo tiempo.
  • Al intentar cambiar ese Owner por otro se vuelve a producir un bloqueo durante un largo tiempo.

Motivo

Como hemos visto anteriormente Salesforce debe identificar en sus tablas internas, todos los registros del Owner, todos los registros de los grupos a que pertenece al Owner, todos los registros de los usuarios que tiene el Owner por encima en las Jeraraquías, borrarlos y actualizarlos con los nuevos accesos.

Si el Owner tiene 10.000 registros o más, el número de actualizaciones en las tablas internas que debe realizarse puede elevarse a centenares de miles de registros, lo que comporta un tiempo de bloqueo y un tiempo de actualización.

Un caso especialmente acuciante, se produce si el owner pertenece a una jerarquía y lo movemos a partes baja de ella, dado que el recálculo necesario por Salesforce será extremadamente complejo.

2. Parent-Child Data Skew

Mala práctica

Sucede cuando en una relación entre objetos, existen registros padres que tienen una prole de registros hijos, que ni el sultán más prolífico de la historia, con más de 10.000 hijos.

Situación anómala

Al cargar una gran cantidad de registros hijos sobre el mismo padre, para cada inserción, la plataforma, bloqueará el registro padre, para que no se produzca inconsistencia de datos.

Durante la carga, por tanto, se estará bloqueando y solicitando continuos bloqueos del registro padre, lo que supondrá una ralentización de la carga y el bloqueo del registro para cualquier otra actividad que llevemos a cabo en la ORG.

Motivo

Comentado en la introducción, este mecanismo de bloqueo es común a los gestores de bases de datos y también para Salesforce.

3. Implicit Sharing Data Skew

Mala práctica

Análogamente al caso anterior, sucede cuando tenemos una Account con más de 10.000 registros hijos en Opporuntity, Case o Contact.

Situaciones anómalas

  • Cuando el Owner de un Contact que está teniendo acceso de lectura a su Account, mediante Implicit Sharing, deja de ser el Owner del Contact ó por ejemplo  eliminamos el contacto, observamos lentitud en la acción.
  • Complementariamente, cuando el Owner de una Account dejar de serlo, se produce una ralentización de las operaciones del sistema.

Motivo

  • En la primera situación, Salesforce debe patearse todos los registros restantes de Contact, que son hijos de la Account, para ver si puede mantener aún la visibilidad sobre la Account del Owner, o si por el contrario debe eliminar ese registro en las tablas internas. Dado que el volumen de hijos de la Account es muy elevado, la operación bloquea la operativa habitual.
  • La segunda situación es menos impactante, dado que la plataforma, “solo” debe borrar todos los registros que otorgaban acceso de lectura a todos los registros hijos. Aún así, esta operación de borrado, puede suponer un tiempo elevado si la Account padre tiene un número elevado de hijos Opportunity y/o Case y/o Contact.

4. Lookup Skew

Mala práctica

Esta práctica es realmente muy fácil de cometer. Básicamente sucede al tener campos Lookup con valores que están repetidos masivamente entre sus padres (Valores A/B/C).

Situación anómala

Mientras insertamos o actualizamos datos en un objeto, y otro usuario intenta actualizar un registro de alguno de los objetos que tienen Lookup con este objeto, se produce un error de Bloqueo. Inicialmente esto no debería suceder, dado que estamos insertando en 2 objetos distintos.

Motivo

Cuando insertamos o actualizamos un registro en un objeto X, Salesforce bloquea todos los registros de los objetos que tienen una relación Lookup con el objeto X.

Si realizamos cargas con grandes volúmenes, e intentamos cargar tanto el objeto X como cualquier objeto que tiene un Lookup con este objeto X, podemos encontrarnos con bloqueos.

Imagina esta situaciones para tus tipificaciones de cuentas, de Contacts, de Leads, etc., que todos tenemos.

5. Indisponibilidad de bloqueo por cambios en Jerarquías o Grupos

Mala práctica

Sucede cuando con la combinación de: jerarquías complejas, grandes volúmenes de datos con relaciones entre objetos y debemos modificar la jerarquía.

Situación anómala

Esta situación es compleja de analizar, me explico: lanzas una actualización de la jerarquía de roles o modificas un grupo, como desconoces el volumen de relación de padres-hijos (donde estás sufriendo de Skew Data), la operación tarda mucho más de lo esperado. Antes de finalizar el recálculo que requiere Salesforce, lanzas una carga de datos y se produce el error, indicando que no ha podido obtener el bloqueo para la inserción o modificación.

Motivo

Esto es debido a que el recálculo para realizar el cambio en la jerarquía o grupos, está tardando mucho más de lo que esperabas y se solapa con la carga de datos.

Para evitar que se produzcan inserciones inconsistentes, Salesforce bloquea las tablas internas de grupos hasta finalizar el cambio. Si los datos que tratamos de insertar, referencian a usuarios afectados por los cambios en la jerarquía o grupos, no se podrá obtener el bloqueo, y se interrumpe la carga.

Conclusiones

Lo más importante creo de estas situaciones es conocer como Salesforce gestiona 2 aspectos fundamentales: la gestión de la visibilidad de los datos en sus estructuras internas y el proceso de actualización de registros mediante bloqueos.

Desde un punto de vista técnico, nuestra responsabilidad es conocerlo, explicarlo  e intentar detectarlo lo antes posible, AUNQUE NO es fácil.

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

One response to “Data Skew: bloqueos y pérdida de rendimiento – cuáles son y cómo evitarlos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.