Arquitectura de consultas y recuperación

También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Français (Canada) · Deutsch (Schweiz)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Imagen generada con IA

Guía de estudio del capítulo 8 del curso Data Architect. Lee primero los cinco módulos; esta página te ayuda a comprobar qué se te ha quedado.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

Este capítulo es la mitad de consultas y búsqueda de la sección Large Data Volume Considerations del examen (el 20 % del examen). Las tres comprobaciones y los umbrales son donde más tiempo dedicaría: son las ideas que a la gente le cuestan más, y conviene saber calcular los umbrales sobre el papel. Las cifras de la plataforma cambian, así que comprueba las actuales antes de confiar en ellas.

Para el examen

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

Dentro del motor (módulo 1)

Sé que Salesforce es multiinquilino y está basado en metadatos: muchas organizaciones comparten una plataforma, separadas por el ID de la organización, y añadir un campo añade metadatos, no una columna de base de datos. (Un edificio, muchos inquilinos, Sin tablas nuevas, solo metadatos)
Sé que los campos estándar y personalizados se guardan por separado, así que una consulta que usa ambos hace una unión, y que las skinny tables la evitan. (La unión que nunca escribiste)
Sé que los campos personalizados no pueden usar un índice nativo de base de datos, así que Salesforce copia los valores indexados en tablas de índices. Los nombres de las tablas internas no son materia de examen. (Por qué no encaja un índice normal)

Índices (módulo 2)

Sé explicar un recorrido de la tabla y un índice (la biblioteca y el catálogo de fichas), y que un índice es una copia: hace más rápido encontrar y más lento cada guardado. (La tecnología avanzada: los catálogos de fichas, Cada copia hay que mantenerla al día)
Sé que SOQL pregunta por estructura y SOSL pregunta por palabras. (Dos maneras de preguntar)
Conozco los campos indexados estándar: RecordTypeId, Division, CreatedDate, Systemmodstamp (LastModifiedDate), Name, Email en contactos y prospectos, los campos de búsqueda y de principal-detalle, y el ID de registro. (Índices estándar)
Sé que un índice personalizado se obtiene del servicio de atención al cliente de Salesforce o mediante Metadata API, y que marcar un campo personalizado como External ID (Numeración automática, Correo electrónico, Número o Texto) o como Único lo indexa. (Índices personalizados)
Sé qué campos no pueden tener un índice personalizado: las áreas de texto largas y enriquecidas, las listas de selección múltiple, el texto cifrado, la divisa en una organización multidivisa y las fórmulas no deterministas. Una fórmula solo se puede indexar si es determinista: sin TODAY() ni NOW(), y sin valores de otro objeto. (Qué campos se pueden indexar)

Cuándo usa Salesforce un índice (módulo 3)

Conozco las tres comprobaciones, el nitro: el campo está indexado; pregunto de forma selectiva; y coinciden pocos registros. (El impulso del nitro, Las tres: el impulso)
Sé qué significa preguntar de forma selectiva. Selectivo: igual a, empieza por (LIKE 'abc%'), una lista IN corta, un rango de una fecha o un número. No selectivo: contiene y termina en (un % inicial), los operadores negativos (!=, NOT LIKE, NOT IN) y las comparaciones con un valor vacío. (Preguntar al índice de la manera correcta)
Sé calcular los umbrales: índice estándar, el 30 % del primer millón de registros más el 15 % del resto, con un tope de 1 millón; índice personalizado, el 10 % más el 5 %, con un tope de 333.333. Un índice estándar con 2 millones de registros permite 450.000; un índice personalizado con 1 millón permite 100.000. (Los umbrales)
Sé que un filtro puede dejar de ser selectivo sin que cambie la consulta: los casos se cierran, el historial se acumula. (La trampa de los casos cerrados)
Planifico con un crecimiento del 30 % anual, y no lo confundo con la reserva del 30 % bajo los límites del regulador de Well-Architected. (Añade un 30 % de crecimiento)

Cómo ejecuta Salesforce una consulta (módulo 4)

La búsqueda (módulo 5)

Sé cuándo usar SOSL en lugar de un montón de OR en SOQL. (La consulta empieza por la estructura; la búsqueda, por un término)
Sé que la búsqueda encuentra primero los tokens en su propio índice y luego recupera los registros, y que el índice es asíncrono: unos 15 minutos o más para el texto nuevo, y horas después de una carga masiva. (Cómo funciona la búsqueda: primero los tokens, luego la recuperación, La frescura forma parte del diseño)
Conozco los límites de SOSL: como máximo 2.000 registros buscados, y después se aplican los permisos; 250 para un solo objeto salvo que añadas WHERE u ORDER BY; hasta 2.000 divididos entre el número de objetos (y no más de 250 cada uno) cuando buscas en varios; 20 consultas SOSL por transacción de Apex. (Buscar bien)
Sé explicar la saturación de la búsqueda: el corte en 2.000 llega antes que el uso compartido, así que registros que un usuario no puede ver ocupan plazas, y un registro que sí puede ver puede quedar fuera. (La saturación de la búsqueda, paso a paso)
Conozco las palancas: los grupos de búsqueda (NAME, EMAIL, PHONE), RETURNING, los términos específicos frente a los comodines, y los comodines solo en el medio o al final. (Buscar bien)
Sé cómo reducir la saturación: decidir en qué objetos busca cada perfil, sacar del índice los campos ruidosos, archivar el historial y comprobarlo como el usuario. (Reducir la saturación de la búsqueda: un plan de acción)

Más allá del examen

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

Diseña contra el comportamiento que documenta Salesforce, no contra una disposición de tablas. Salesforce ya reconstruyó el motor por debajo una vez.
Un índice es una copia. Cada uno hace más rápido encontrar y más lento guardar.
“No te preocupes, ese campo está indexado” nunca es el final de la conversación. Haz las tres preguntas y luego las cuentas.
Una consulta puede estropearse sin cambiar.
Mide antes de optimizar, y prueba con los ceros que de verdad vas a tener.
Indexa cuando es una solución limpia y general; rediseña en lugar de indexar un caso aislado.
Los metadatos deben decir la verdad. No marques un campo como External ID solo por el índice.
A veces la mejor optimización de consultas es una población activa más pequeña.
Busca para descubrir; consulta para operar. La búsqueda no es un modelo de datos.
Unos datos pueden merecer existir sin merecer aparecer en la búsqueda.
La búsqueda se ejecuta como alguien. Compruébalo como el usuario, no como administrador.

Palabras que conviene conocer

Término	En una línea
Multiinquilino	Las organizaciones de muchas empresas comparten una plataforma, separadas por el ID de la organización
Basado en metadatos	Los objetos y campos se describen como datos, no se construyen como tablas de base de datos
Recorrido de la tabla (table scan)	Tocar todos los registros para encontrar los que quieres
Índice	Una copia de los valores de un campo, con la ubicación de cada registro, para encontrarlos rápido
Tabla de índice	Donde Salesforce copia los valores indexados de los campos personalizados
Optimizador de consultas	La parte de la plataforma que elige el camino más barato para cada consulta, informe y vista de lista
Selectivo	Preguntado de una manera que un índice puede usar, y con pocos registros coincidentes
Umbral de selectividad	El máximo de registros con que puede coincidir un filtro indexado para que se siga usando
Consulta (query)	Encontrar qué registros coinciden
Recuperación (fetch)	Traer de vuelta los campos de los registros encontrados
Unión (join)	Pasar de una tabla u objeto a otro
Query Plan	Una herramienta que muestra los caminos posibles del optimizador y su coste relativo
Índice personalizado	Un índice en un campo personalizado, del servicio de atención al cliente, de Metadata API o de un External ID
Índice de dos columnas	Un solo índice sobre dos campos que se usan juntos
Skinny table	Una copia de campos seleccionados de un objeto, mantenida por Salesforce, para lecturas rápidas sin la unión
División	Una partición de los datos de una organización grande que reduce los registros que devuelven las consultas
Estadísticas de la base de datos	Los recuentos que usa el optimizador para elegir un plan, recopilados cada noche
SOQL	El lenguaje de consulta de Salesforce para preguntas estructuradas
SOSL	El lenguaje de búsqueda de Salesforce para encontrar palabras en varios objetos
Saturación de la búsqueda (search crowding)	Coincidencias que el usuario no quiere, o no puede ver, que llenan las 2.000 plazas antes que el registro que necesita

Ponte a prueba

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. Un objeto tiene 10 millones de registros. Un filtro sobre un campo con índice personalizado devuelve 400.000. ¿Usará el índice el optimizador?

Probablemente no. El umbral del índice personalizado es el 10 % del primer millón más el 5 % del resto, con un tope de 333.333; con 10 millones se aplica el tope, y 400.000 lo supera. Compruébalo con el Query Plan. Vuelve a leer Los umbrales.

2. Un objeto tiene 2 millones de registros. Un filtro por Name, un índice estándar, devuelve 500.000. ¿Es selectivo?

No. Un índice estándar permite el 30 % del primer millón (300.000) más el 15 % del siguiente millón (150.000): 450.000. Con 500.000 el filtro supera el umbral, y el optimizador buscará en otra parte o recorrerá la tabla. Vuelve a leer A medida que crece el objeto.

3. Una vista de lista sobre 8 millones de casos filtra por Status distinto de Closed. Status tiene un índice personalizado. ¿Por qué va lenta?

Un operador negativo no pregunta de forma selectiva, así que el índice no puede ayudar, y el optimizador se ejecuta para las vistas de lista igual que para el código. Pregunta en positivo, por los estados abiertos, y comprueba que los casos abiertos sigan por debajo del umbral. Vuelve a leer Preguntar al índice de la manera correcta y ¿Cuándo trabaja el bibliotecario? Todo el tiempo.

4. Una consulta sobre IsClosed = true era rápida al principio y es lenta tres años después. No cambió nada del código. ¿Por qué?

Los datos envejecieron: los casos se cierran, así que un filtro que antes coincidía con una pequeña parte ahora coincide con casi todo. La selectividad depende de la distribución, que cambia con el tiempo. Vuelve a leer La trampa de los casos cerrados.

5. Alguien pide un índice para un informe que se ejecuta una vez al año. ¿Qué preguntas?

Por qué va lento, y si un índice permanente compensa su coste para un caso aislado. Mide primero la distribución y lee el Query Plan; plantéate reescribir la consulta, rediseñar o archivar el historial para que la población activa sea más pequeña. Vuelve a leer Antes de pedir un índice.

6. Una consulta importante necesita las partidas recientes de un socio minorista, pero el socio está en la orden de trabajo padre, y hay 14,5 millones de partidas. ¿Opciones?

Rediseñar: copia el socio en la partida cuando se crea (e indéxalo si el filtro lo necesita), para que la consulta filtre directamente el hijo. Sopesa el beneficio frente a los datos duplicados y su mantenimiento; aquí el socio nunca cambia, lo que ayuda. Vuelve a leer Cuando va lento: indexar, reescribir, rediseñar o archivar.

7. "Pidamos al soporte un índice skinny table en Account." ¿Qué falla en esa frase?

Una skinny table no es un índice. Es una copia de campos seleccionados de un objeto, que evita la unión entre los campos estándar y personalizados y hace más ligera la recuperación. Solo se usa automáticamente cuando una consulta, un informe o una vista de lista pide únicamente sus campos. Vuelve a leer Skinny tables.

8. Anoche el equipo cargó 2 millones de registros mediante Bulk API. Esta mañana algunas consultas van lentas y los registros nuevos no se encuentran en la búsqueda. ¿Está roto?

Probablemente no. Las estadísticas del optimizador se recopilan cada noche, así que puede que todavía no reflejen una carga muy grande; y el índice de búsqueda es asíncrono, así que una carga masiva puede tardar horas en poder buscarse. Planifica las cargas teniendo en cuenta ambas cosas. Vuelve a leer Las estadísticas de la base de datos: el cuaderno del bibliotecario y La frescura forma parte del diseño.

9. Un usuario escribe cualquier texto y espera encontrar al cliente por nombre, correo electrónico, teléfono o notas. El desarrollador construye una consulta SOQL con diez cláusulas LIKE unidas por OR. ¿Mejor?

Es un problema de búsqueda: usa SOSL, que está hecho para buscar palabras en varios campos y objetos. Una cadena larga de OR además necesita que cada filtro sea selectivo e indexado por sí solo, y un LIKE de tipo contiene nunca lo es. Vuelve a leer La consulta empieza por la estructura; la búsqueda, por un término.

10. Una agente de atención busca el apellido de un cliente y obtiene 1.900 resultados, pero no el caso que necesita, que puede abrir desde una vista de lista. ¿Por qué?

Saturación de la búsqueda. El apellido coincidió con más de 2.000 registros, y la búsqueda se queda con los primeros 2.000 antes de comprobar lo que ella puede ver: 100 de ellos no los puede ver, así que vuelven 1.900, y su caso puede estar entre las coincidencias que quedaron fuera. Usa un término más específico, busca en un solo objeto y reduce el ruido en el origen; luego compruébalo como ella, no como administrador. Vuelve a leer La saturación de la búsqueda, paso a paso y Reducir la saturación de la búsqueda: un plan de acción.

11. La automatización debe encontrar una incidencia de entrega en el momento en que se crea. ¿Usar la búsqueda?

No. El índice de búsqueda se actualiza de forma asíncrona y puede ir con 15 minutos o más de retraso. El proceso conoce la estructura, así que una consulta estructurada es la opción determinista. Vuelve a leer La frescura forma parte del diseño.

Explora

Guía de examen de Arquitecto de datos de plataformas certificado por Salesforce (se abre en una pestaña nueva), Salesforce Help, checked 2026-11-01: the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
La sección Explora de cada módulo enumera la documentación de Salesforce detrás de sus datos, con la fecha en que se comprobaron.