Optimizaciones para organizaciones de Salesforce con muchos datos (Parte 4)

Esta es una introducción y aquí tienes algunos puntos clave.

Puntos clave

• Foo
• Bar
• bum

¿De acuerdo?

Esta es la Parte 4 de 4 de nuestra serie sobre trucos y técnicas de optimización para organizaciones grandes de Salesforce. Puedes encontrar la Parte 3 aquí. 

Optimización de búsquedas

Este es un escenario común: el cliente quiere buscar en grandes volúmenes de datos de varios objetos usando valores de filtro, incluidos comodines. En este escenario, hay una página de la interfaz donde los usuarios pueden ingresar valores en campos y buscar con SOQL usando la combinación de esos campos.

Algo que debes notar aquí es que no se menciona SOSL. Puedes acelerar mucho tus consultas usando SOSL, porque se ejecutará en varios objetos al mismo tiempo. Si tuvieras que usar solo SOQL, necesitarías consultar los objetos varias veces para obtener el conjunto de resultados adecuado. La optimización es un desafío porque hay una cláusula WHERE con varios filtros y comodines.

Para optimizar esto, procura usar solo los campos esenciales y reducir la cantidad de campos en los que se puede buscar. Limita los campos simultáneos que se pueden usar en una sola búsqueda a los campos indexados comunes que mencionamos antes.

Puedes crear un solo objeto personalizado y desnormalizar los datos de varios objetos para evitar realizar múltiples consultas. También puedes determinar dinámicamente si usar SOQL o SOSL y realizar búsquedas según la cantidad de campos consultados y los tipos de valores ingresados. Por ejemplo, para SOQL se deben usar criterios de filtro muy específicos, mientras que con SOSL se pueden usar comodines.

Indexación de valores nulos

Supongamos que quieres permitir valores nulos en un campo y ejecutar consultas para buscarlos. Mencionamos que los índices de una sola columna para listas de selección y campos de clave externa excluyen las filas en las que la columna tiene un valor nulo, por lo que no se podría usar un índice para consultar esos valores.

La práctica recomendada sería ejecutar una consulta que omita inicialmente los valores nulos. Puedes usar una cadena de texto de marcador de posición en lugar de un valor nulo. Si no puedes hacerlo, posiblemente porque ya existen registros con valores nulos en el objeto, puedes crear un campo de fórmula que muestre texto para esos valores e indexar ese campo.

Por ejemplo, supongamos que el campo Status está indexado y contiene valores nulos. Ejecutar una consulta SOQL similar a la siguiente impide que se use el índice:

SELECT Name FROM Object WHERE Status__c = ''

En su lugar, puedes crear una fórmula llamada Status_Value:

Status_Value__c = IF(ISBLANK(Status__c), "blank", Status__c)

Este campo de fórmula se puede indexar y usar al consultar un valor nulo:

SELECT Name FROM Object WHERE Status_Value__c = 'blank'

También puedes hacerlo con varios campos:

SELECT Name FROM Object WHERE Status_Value__c = '' OR Email = ''

Listas relacionadas con grandes volúmenes de datos

Supongamos que tienes cerca de un millón de cuentas y decenas de millones de facturas, que residen en un objeto personalizado con una relación maestro-detalle con la cuenta. Cada registro de cuenta tarda mucho en mostrarse porque los registros de la lista relacionada requieren tiempo para renderizarse.

Hemos hablado de cómo puede producirse una distribución desigual de los datos, de por qué debemos distribuirlos entre varios objetos en lugar de uno solo y de por qué un registro no debe tener demasiados registros secundarios. Para reducir la demora, las cuentas con demasiados objetos secundarios se pueden dividir en varios registros de cuenta, lo que ayuda a minimizar la distribución desigual de los datos. También puedes activar la opción Habilitar carga separada de listas relacionadas para permitir que los detalles de la cuenta se carguen primero y que la consulta de la lista relacionada se ejecute por separado en segundo plano.

Eliminación y extracción con la API masiva

El API masiva admite una opción de eliminación definitiva (eliminación física), que permite que los registros omitan la Papelera de reciclaje y queden disponibles de inmediato para su eliminación. Usar la función de eliminación definitiva de la API masiva es una estrategia recomendada para eliminar grandes volúmenes de datos, liberar espacio y evitar que el contenido innecesario afecte el rendimiento. Ten en cuenta que esta opción está deshabilitada de forma predeterminada y que un administrador debe habilitarla.

De forma predeterminada, las consultas se dividen en bloques de 100k registros. Puedes usar el campo de encabezado chunkSize para configurar bloques más pequeños o más grandes, de hasta 250k, durante tus llamadas a la API masiva. Esto permitiría cargar más datos, pero el procesamiento tarda más. Si tu organización tiene pocos metadatos y un uso mínimo del acceso compartido, puedes beneficiarte de usar bloques grandes. Con volúmenes extremadamente altos —cientos de millones de registros—, definir estos bloques mediante filtros sobre valores de campos puede no ser práctico. La cantidad de filas devueltas puede superar el umbral de selectividad del optimizador de consultas de Salesforce. El resultado podría ser un escaneo completo de la tabla y un rendimiento lento, o incluso un error. En ese caso, necesitas emplear otra estrategia.

Puedes usar la división en bloques por PK cuando el filtrado por atributos no te ayude a dividir los datos en bloques más pequeños. PK significa clave primaria, que es el recordId de un objeto. El sistema siempre lo indexa de forma predeterminada. La división en bloques por PK divide las consultas masivas de tablas muy grandes en bloques basados en los recordIds de los registros consultados.

Habilita la división en bloques por PK al consultar tablas con más de 10 millones de registros o cuando una consulta masiva agote constantemente el tiempo de espera. La división en bloques por PK es una función compatible con la API masiva de Salesforce, por lo que se encarga de dividir las consultas en bloques manejables. Solo ingresa algunos parámetros en tu trabajo de la API masiva y la plataforma dividirá automáticamente la consulta en bloques separados, ejecutará una consulta para cada bloque y devolverá los datos.

Puedes usar la división en bloques por PK con la mayoría de los objetos estándar. Es compatible con Account, Campaign, CampaignMember, Case, Contact, Lead, LoginHistory, Opportunity, Task y User, así como con todos los objetos personalizados. Para habilitar esta función, especifica el encabezado Sforce-Enable-PKChunking en la solicitud del trabajo de tu consulta de la API masiva.

Para elegir un tamaño de bloque, simplemente especifícalo en el encabezado. Por ejemplo, este encabezado habilita la división en bloques por clave primaria (PK) con un tamaño de 50,000 registros: `Sforce-Enable-PKChunking: chunkSize=50000`. Cada bloque se procesa como un lote independiente que cuenta para tu límite diario de lotes, y sus resultados deben descargarse por separado. Puedes aplicar filtros al usar la división en bloques por PK incluyendo una cláusula WHERE en la consulta de la API masiva. Con este método, un bloque puede devolver menos registros que la cantidad especificada en chunkSize.

Rendimiento de la API

Imagina un escenario en el que una integración personalizada sincroniza datos de Salesforce con aplicaciones externas.

Este proceso implica consultar los datos de Salesforce en un objeto determinado, cargarlos en un sistema externo y volver a consultar Salesforce para obtener los ID de todos los datos, de modo que la integración pueda determinar qué registros se han procesado y eliminado.

Los objetos podrían contener varios millones de registros. La integración usaría un usuario de API específico que formara parte de la jerarquía de acceso compartido para limitar los registros recuperados. Las consultas podrían tardar minutos en completarse. En Salesforce, el acceso compartido es un mecanismo muy potente para hacer que ciertos registros sean visibles para determinados usuarios, y funciona muy bien para las interacciones con la interfaz. Sin embargo, cuando se usa como filtro de grandes volúmenes de datos en una consulta SOQL, el rendimiento puede verse afectado porque el acceso a los datos es más complejo y difícil de procesar, especialmente si intentas excluir registros en un escenario con grandes volúmenes de datos.

La solución es dar acceso a todos los datos a los usuarios que ejecutan el código y usar filtros selectivos para obtener los registros adecuados. Por ejemplo, usar un administrador como usuario de API habría proporcionado acceso a todos los datos y evitado que se considerara el acceso compartido en la consulta.

Una solución adicional es crear una extracción incremental para reducir el volumen de datos que se debe procesar.

Truncamiento

Truncamiento es una forma muy rápida de eliminar registros de los objetos personalizados de una organización de pruebas. El truncamiento elimina los registros, pero mantiene intactos los metadatos para su uso futuro.

Truncar objetos personalizados provoca algunos cambios irreversibles en el objeto truncado y sus registros. No se pueden restaurar a su estado original.

Si creaste un objeto personalizado y lo llenaste con registros de prueba, el truncamiento puede ser muy útil cuando termines de usar esos datos. Para probar realmente el rendimiento de la aplicación, se generan y utilizan datos simulados. En lugar de crear el objeto en producción, puedes truncarlo, eliminar los registros de prueba y desplegarlo en producción. Esto es mucho más rápido que eliminar registros por lotes.

Puedes habilitar el truncamiento entrando en la sección Interfaz de usuario de s=Setup y activando el permiso. Para habilitar el truncamiento de un objeto, ve a su página de detalles y haz clic en el siguiente Truncar botón. Después de revisar la advertencia de la operación, ingresa el nombre del objeto.

Cuando truncas un objeto personalizado, todos sus registros se eliminan permanentemente, pero su definición se conserva. Los registros dejan de contar para los límites de tu organización. En cambio, si eliminas un objeto personalizado, este se mueve a la Papelera de reciclaje durante 15 días (como se describió antes). Después, el objeto y sus registros se eliminan permanentemente.

Conclusión

Gracias por leer. ¡Esperamos que estos consejos te ayuden a mejorar el rendimiento y la velocidad de tus aplicaciones de Salesforce!