Diseñar su modelo de datos

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Diseñar un modelo de datos para grandes volúmenes de datos.
  
• Describir los tres tipos de inclinación de datos y cómo evitarlas.
  
• Ampliar un modelo de datos para incluir objetos externos.
  

Planificar su modelo de datos

Los datos son uno de los elementos clave de cualquier aplicación. Los usuarios crean datos continuamente. Todo el día. Cada día. Dema siados Datos. De repente su organización acumuló millones de registros, miles de usuarios y varios gigabytes de almacenamiento de datos.

Estos grandes volúmenes de datos (LDV) puede llevar a una lentitud del desempeño, incluyendo consultas más lentas, vistas de lista y búsqueda más lentas y actualización de sandbox más lenta. Puede evitar esta difícil situación si planifica acomodar LDV por anticipado, diseñando su modelo de datos para crear una adaptación desde un principio.

La clave en la inclinación de datos

Una clave para la gestión de grandes volúmenes de datos para un máximo desempeño es diseñar cuidadosamente la propiedad de registro para evitar inclinación de datos. La inclinación de datos se produce cuando más de 10.000 registros secundarios están asociados con el mismo registro principal en una organización.

Planifique su modelo de datos con suficientes cuentas para mantener el número de registros secundarios por debajo de este umbral y distribuya nuevos registros secundarios entre estas cuentas cuando se crean. Si no utiliza estas estrategias, existen tres tipos de inclinación de datos que se pueden producir y afectar el desempeño de forma negativa: inclinación de datos de cuenta, inclinación de propiedad e inclinación de búsqueda.

Inclinación de datos de cuenta

Algunos objetos de Salesforce, como cuentas y oportunidades, tienen relaciones de datos especiales que mantienen el acceso de registro principal y secundario bajo modelos de colaboración privados. Demasiados registros secundarios asociados con el mismo objeto principal en una de estas relaciones causa la inclinación de datos de cuenta. Supongamos que tiene una serie de contactos sin asignar y los coloca bajo una cuenta denominada “Sin asignar”. Ésto puede crear problemas con el desempeño de colaboración y bloqueo de registros.

Bloqueo de registros

Aquí le mostramos otro escenario: Está actualizando un gran número de contactos bajo la misma cuenta en múltiples subprocesos. Para cada actualización, el sistema bloquea tanto el contacto que se cambió como su cuenta principal para mantener la integridad en la base de datos. Aunque cada bloqueo se celebra por un periodo de tiempo muy corto, porque todas las actualizaciones están intentando bloquear la misma cuenta, existe un alto riesgo de que falle una actualización porque una actualización anterior aún está realizando el bloqueo en la cuenta.

Problemas de colaboración

Existe una dinámica similar cuando se trata de la colaboración. Dependiendo de cómo configuró la colaboración, cuando realiza algo que parece sencillo, como cambia el propietario de una cuenta, es posible que tenga que examinar cada uno de los registros secundarios de la cuenta y ajustar su colaboración también. Eso podría incluir volver a calcular la jerarquía de funciones y las reglas de colaboración. Además, si estamos hablando de cientos de miles de registros secundarios, eso podría suponer muchísimo tiempo.

Inclinación de propiedad

Cuando un gran número de registros con el mismo tipo de objeto es propiedad de un solo usuario, este desequilibrio causa la inclinación de propiedad. Como cada registro debe tener un propietario, parece que la solución natural es inclinar esos registros en un propietario genérico, como el anteriormente mencionado “Sin asignar”. Pero ésto puede causar problemas de desempeño debido a cálculos de colaboración requeridos para gestionar la visibilidad de esos registros.

Cuando el propietario inclinado existe en la jerarquía de funciones, las operaciones como eliminaciones o actualizaciones de propietario deben eliminar la colaboración del propietario antiguo y todos los usuarios principales en la jerarquía de funciones y desde todos los usuarios que obtuvieron acceso por reglas de colaboración. Es por eso que los cambios de propietario tienden a ser uno de los cambios transaccionales más costosos en el sistema.

En algunos casos, una inclinación de propiedad simplemente se puede evitar. En estos casos, es mejor asegurarse de que el propietario inclinado no tiene una función. De ese modo, lleva el usuario y sus registros fuera de la jerarquía de funciones y sus reglas de colaboración asociadas.

Inclinación de búsqueda

La inclinación de búsqueda sucede cuando un número de registros muy grande están asociados con un solo registro en le objeto de búsqueda (el objeto en el que está buscando). Como puede colocar campos de búsqueda en cualquier objeto en Salesforce, la inclinación de búsqueda puede crear problemas para cualquier objeto en su organización.

Si termina con inclinación de búsqueda y tiene una implementación personalizada altamente compleja, es posible que esté creando un problemas sin darse cuenta. Considerando cuidadosamente sus opciones para la gestión de inclinación de búsqueda, puede evitar problemas de bloqueo en campos de búsqueda para garantizar que se amplíe su arquitectura par cumplir con el crecimiento de su organización.

¿Qué hace tan negativa la inclinación de búsqueda? Los campos de búsqueda en Salesforce son fundamentalmente relaciones clave externas entre objetos. Cada vez que se inserta o se actualiza un registro, Salesforce debe bloquear los registros de destino seleccionados para cada campo de búsqueda. Esto garantiza que cuando se comprometen los datos con la base de datos, se mantiene su integridad.

Bajo circunstancias normales, las operaciones de guardado se ejecutan de forma tan rápida que no encuentra bloqueos. Pero cuando agrega código personalizado y LDV de forma simultánea en un proceso automatizado, es posible que encuentre excepciones que causan fallos cundo intenta insertar o actualizar registros.

Como no existen herramientas diseñadas específicamente para identificar inclinaciones de búsqueda, encontrar estos problemas arquitectónicos puede ser como encontrar una aguja en un pajar. Es importante recordar que la inclinación de búsqueda, bajo ciertos patrones de uso, podría no causar ningún problema en absoluto, por lo que es mejor buscar basándose en patrones que causarán problemas. Debería evaluar objetos con un gran número de registros y actividad de actualización e inserción simultánea.

Uso de objetos externos

Otras estrategia para LDV es el uso de objetos externos, lo que significa que no existe la necesidad de aportar datos a Salesforce. Con una estrategia de graduación de datos que difunde datos entre múltiples objetos y los incorpora on demand desde otro objeto o almacenamiento externo, evita tanto el almacenamiento de grandes cantidades de datos en su organización y los problemas de desempeño asociados con LDV.

Los objetos externos son similares a objetos personalizados, excepto que se asignan a datos almacenados fuera de su organización de Salesforce, permitiendo a sus usuarios y la plataforma Force.com buscar e interactuar con los datos externos.

Accediendo a datos de registro on demand, los objetos externos siempre reflejan el estado actual de los datos externos. No tiene que gestionar una copia de esos datos en Salesforce, por lo que no está perdiendo almacenamiento y recursos manteniendo datos en sincronización. Los objetos externos se utilizan mejor cuando tiene una gran cantidad de datos que no puede o no desea almacenar en su organización de Salesforce y solo necesita utilizar una pequeña cantidad de esos datos en cualquier momento.

Una fuente de datos externa especifica cómo acceder a un sistema externo. Salesforce Connect utiliza fuentes de datos externas para acceder a datos almacenados fuera de su organización de Salesforce. Files Connect utiliza fuentes de datos externas para acceder a sistemas de contenido externos. Las fuentes de datos externas tienen objetos externos asociados, que sus usuarios y plataforma Force.com utilizan para interactuar con el contenido y los datos externos.

Búsquedas de objetos externos

Los objetos externos admiten relaciones de búsqueda estándar, que utiliza los Id. de registro de Salesforce de 18 caracteres para asociar registros relacionados entre sí. Pero los datos almacenados fuera de su organización de Salesforce a menudo no contienen esos Id. de registro. Por lo que dos tipos de relaciones de búsqueda están disponibles para objetos externos: búsqueda externas y búsquedas indirectas.

Estas búsquedas externas y búsquedas indirectas comparan valores de un campo específico en el objeto principal con los valores del campo de relación en el objeto secundario. Cuando coinciden los valores, los registros se relacionan entre sí.

Utilice una relación de búsqueda externa cuando el principal es un objeto externo. Una relación de búsqueda externa vincula un objeto estándar, personalizado o externo secundario con un objeto externo principal. Los valores del campo estándar Id. externo del objeto externo principal se comparan con los valores del campo de relación de búsqueda externa. En el caso de un objeto externo secundario, los valores del campo de relación de búsqueda externa proceden del Nombre de columna externa especificado.

Utilice una relación de búsqueda indirecta cuando los datos externos no incluyen Id. de registro de Salesforce. Una relación de búsqueda indirecta vincula un objeto externo secundario con un objeto estándar o personalizado principal. Cuando crea un campo de relación de búsqueda indirecta en un objeto externo, especifica el campo de objeto principal y el campo de objeto secundario para compararlos, seleccionando un campos Id. externo único personalizado en el objeto principal para comparar con el campo de relación de búsqueda indirecta del secundario, cuyos valores están determinados por el Nombre de columna externa especificado.

A continuación le mostramos un desglose de los tipos de relaciones disponibles para objetos externos:

Ahora conoce cosas clave a tener en cuenta (y evitar) al diseñar su organización para grandes volúmenes de datos. Es posible que desee también implicar un arquitecto desde Servicios estratégicos de Salesforce para ayudarle a diseñar la mejor forma de gestionar la configuración inicial y el crecimiento con el tiempo. En la siguiente unidad, lanzamos búsquedas y consultas de LDV en el conjunto.

Recursos

• Desarrollador de Salesforce: Avoid Account Data Skew for Peak Performance
• Desarrollador de Salesforce: Managing Lookup Skew in Salesforce to Avoid Record Lock Exceptions
• Ayuda de Salesforce: Define External Objects
• PDF: Designing Record Access for Enterprise Scale
• Desarrollador de Salesforce: Visión general de los campos y objetos de Salesforce: Objetos externos