Diseñar para la escala
También en 19 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Guía de estudio del capítulo 7 del curso Data Architect. Lee primero los cuatro 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 abre la Parte 2 y la sección Large Data Volumes del examen (20 %), junto con el sesgo de datos de Data Modeling. El diseño de consultas es el próximo capítulo; este trata del volumen, los puntos calientes, el uso compartido a escala y el ciclo de vida. Las cifras de la plataforma cambian, así que comprueba las actuales antes de confiar en ellas.
Para el examen
Sección titulada «Para el examen »Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.
LDV-1: un modelo que escala
- Dimensiono un diseño para el crecimiento a lo largo del periodo de retención, no para el volumen de hoy, y multiplico los hijos. (No preguntes cuánto ocupa hoy, Ahora multiplica los hijos)
- Sé que el volumen afecta a más cosas que las consultas: uso compartido, propiedad, bloqueos, vistas de lista, informes, lotes, cargas, borrados y recuperación. (Las consultas no son lo único que se ralentiza)
- Sé cuándo la escala justifica una desnormalización controlada, y lo que cuesta. (Los modelos limpios pueden volverse modelos caros)
- Sé que no hay que convertir el CRM operativo en el almacén de datos, y que las instantáneas de informes no son una estrategia de almacén de datos. (No conviertas el CRM principal en tu almacén de datos)
- Sé que el volumen tiene forma: ¿veinte millones de registros haciendo qué? (El volumen tiene forma)
DM-5: sesgo de datos
- Test knowledge: I know parent-child skew and the guidance of no more than about 10,000 children per parent; it’s a design threshold, not a cliff. Where security allows, Controlled by Parent on the child takes away the parent’s implicit shares to maintain. (Parent-Child Skew) ⟲
- Conozco la solución del grupo de cuentas para un padre artificial, y que hay que ocultar a los usuarios los padres de relleno. (La cuenta “Sin asignar” y los grupos de cuentas)
- Conocimiento para el examen: conozco la buena práctica de Salesforce de no más de 10.000 hijos para un solo padre principal-detalle, y lo que trae principal-detalle con volumen: sin propietario en el detalle, borrado en cascada, sin cambio de padre salvo que se permita, campos de resumen acumulado y bloqueo del padre. Cuento los hijos antes de elegir principal-detalle o búsqueda, y sé que volver a convertirla en una búsqueda exige que no haya campos de resumen acumulado en el principal. (Principal-detalle con volumen)
- Conocimiento para el examen: conozco el sesgo de propiedad (un usuario propietario de más de 10.000 registros de un objeto) y la solución: ninguna función, o una función aparte y estable en la cima, y fuera de los grupos públicos que usan las reglas de uso compartido. (Sesgo de propiedad)
- Conozco el sesgo de búsqueda: muchos registros activos que apuntan a un registro, y el bloqueo de registros que puede provocar. (Sesgo de búsqueda)
- Sé distinguir un sesgo peligroso de uno inofensivo por su actividad, no solo por su número. (No todos los sesgos son igual de peligrosos)
- Corrijo el sesgo de una entidad de negocio real con una división con significado (una cuenta hija por centro de distribución), nunca con copias falsas de ella. (Steve Trucking: ¿dónde están los puntos calientes?)
DM-2: uso compartido a escala
- Sé que las estructuras de acceso (propietarios, funciones, grupos, registros compartidos) también son datos, y escalan. (El uso compartido también son datos)
- Test knowledge: I know the share object (
AccountShare,Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. (The Share Table Has Its Own Number of Zeros) ⟲ - Sé que un cambio en la jerarquía de funciones con volumen es una operación de datos, así que la estabilidad es una característica del diseño. (La jerarquía de funciones no es un organigrama)
- Conocimiento para el examen: conozco los cálculos de uso compartido diferidos: haz todos los cambios y luego recalcula una sola vez en una ventana de mantenimiento, probado antes en un sandbox de copia completa. (Recalcular el uso compartido es trabajo de verdad)
- Conocimiento para el examen: sé que el bloqueo granular (activado por defecto) permite que operaciones de grupo no relacionadas se ejecuten a la vez, pero no arregla un mal diseño. (El bloqueo granular ayuda)
- Sé que el rendimiento no es una excusa para hacer públicos datos que deberían ser privados. (No sacrifiques la seguridad para optimizar)
LDV-2: archivado y purga
- Sé mantener separadas la retención, el archivado y la purga, y definirlas al inicio de un proyecto. (La eliminación es inevitable)
- Tengo listas las copias de seguridad antes de borrar nada, y sé que la copia de seguridad y el archivo son capacidades distintas (Salesforce Backup & Recover, Archive). (Haz una copia de seguridad antes de borrar)
- Conocimiento para el examen: sé elegir el destino de un archivo según la restricción: objetos grandes (big objects), un almacén externo a través de Salesforce Connect (OData, adaptadores SQL o un adaptador personalizado) o Archive de Salesforce. (¿Dónde debe vivir el archivo?)
- Test knowledge: I know what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. (Where Should the Archive Live?) ⟲
- Conocimiento para el examen: sé cómo purgar con volumen: los registros eliminados de forma lógica permanecen 15 días en la Papelera de reciclaje y siguen ralentizando las consultas; para un millón de registros o más, el borrado definitivo (hard delete) de Bulk API 2.0; los hijos antes que los padres. (La eliminación es inevitable)
- Conozco el archivado en tres pasos (copiar y marcar, verificar, borrar y cambiar), y que debe poder reanudarse. (El archivado en tres pasos)
- Sé que los datos archivados deben seguir siendo localizables y conservar su seguridad. (Un archivo que nadie puede encontrar es casi una eliminación, El archivo sigue teniendo que ser seguro)
Más allá del examen
Sección titulada «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.
- Salesforce is built for transactions on structured data, on a multitenant database where Salesforce writes the SQL. Millions of records perform well because somebody designed for them. (Built for Transactions) ⟲
- My large data volume ruler (records in one object): around a million, a little drag; ten million, some effect but still performing; heading toward fifty million, list views take seconds, and past it you’re the convertible with your hair blown back; at a hundred million or more, ask whether the records should be here at all. ⟲
- Lo que funciona hoy puede fallar mañana.
- A veces la mejor solución es no crear el problema: mantén el GPS, las fotos y el historial de estados fuera del núcleo.
- El número me dice dónde mirar; el comportamiento me dice cuánto preocuparme.
- A esta escala, los cambios organizativos se convierten en operaciones de datos.
- Las soluciones de escala también tienen que preservar el significado.
- Encuentra los puntos calientes en el diagrama: mira las flechas y pregunta cuántos registros se acumulan en cada lado.
- Prueba el Número de Ceros para el que de verdad estás diseñando.
- La IA va a añadir más ceros. Modela de forma explícita el volumen generado por agentes.
- Who owns machine-created records depends on whether ownership matters for sharing. Created by and owned by aren’t the same question; decide what Owner means for each object. (Who Should Own Machine-Created Records?) ⟲
- Si no estás archivando hoy, ¿vas a archivar alguna vez?
- Diseña la salida cuando diseñas la entrada. Cinco respuestas por objeto: cuándo deja de estar activo, adónde va, cómo lo demostramos, cómo lo encuentra alguien, cuándo se borra.
- Si los agentes pueden llegar a los datos archivados es una decisión del negocio.
Palabras que conviene conocer
Sección titulada «Palabras que conviene conocer »| Término | En una línea |
|---|---|
| Gran volumen de datos (LDV) | Tantos registros que el comportamiento de la plataforma, no solo la cifra, da forma al diseño |
| Sesgo de datos (data skew) | Demasiados registros concentrados en un padre, propietario o valor de búsqueda |
| Sesgo padre-hijo | Demasiados hijos bajo un registro padre |
| Sesgo de propiedad | Un usuario propietario de más de unos 10.000 registros de un objeto |
| Sesgo de búsqueda | Muchos registros activos que hacen referencia a un registro, lo que provoca contención de bloqueos |
| Grupo de cuentas (account pool) | Varios padres de relleno que se reparten los hijos de un padre artificial |
| Controlled by Parent | A sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain |
| Share object | The table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause |
| Big object | An object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only |
| Recálculo del uso compartido | La plataforma vuelve a calcular el acceso tras un cambio de propietarios, funciones, grupos o reglas |
| Cálculo de uso compartido aplazado | Retener el recálculo hasta terminar un lote de cambios y luego ejecutarlo una sola vez |
| Bloqueo granular | Bloquear solo las partes de las tablas de pertenencia a grupos que necesita una operación |
| Retención | Cuánto tiempo se conservan los datos, y por qué |
| Archivado | Sacar datos de la carga de trabajo activa manteniendo el acceso que necesita el negocio |
| Purga | Eliminar datos de forma permanente al final de su retención |
| Archivado en tres pasos | Copiar y marcar, verificar, y luego borrar y cambiar |
Ponte a prueba
Sección titulada «Ponte a prueba »Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.
1. Una empresa hace un millón de entregas al año, crece un 30 por ciento y conserva cinco años. ¿Para qué volumen diseñas?
Para unos 9 millones de entregas conservadas a lo largo de cinco años, no un millón, y luego sus hijos: unos 14,5 millones de partidas a 1,6 por entrega, y 72 millones de eventos de estado a ocho por entrega. Vuelve a leer No preguntes cuánto ocupa hoy.
2. Hay 300.000 contactos bajo una cuenta llamada "Contactos sin asignar". ¿Qué haces?
Es un sesgo padre-hijo artificial. Reparte los contactos en un grupo de cuentas de padres de relleno, cada uno por debajo del umbral, y oculta esos padres de relleno de las vistas normales de negocio. O pregúntate si los contactos necesitan una cuenta en absoluto. Vuelve a leer La cuenta “Sin asignar” y los grupos de cuentas.
3. Un socio minorista tendrá 3,6 millones de órdenes de trabajo. Alguien propone las cuentas Redrock 001, 002 y 003. ¿Qué opinas?
No: eso corrompe una entidad de negocio real. Busca una división que el negocio reconozca, como una cuenta hija por centro de distribución, y archiva las entregas completadas para mantener bajos los hijos activos. Vuelve a leer Steve Trucking: ¿dónde están los puntos calientes?.
4. Un usuario de integración es propietario de 2 millones de registros y está en una función regional que va a moverse en una reorganización. ¿Cuál es el riesgo, y la solución?
Moverlo obliga a recalcular el acceso en 2 millones de registros. No des ninguna función a los propietarios de gran volumen, o dales una función aparte y estable en la cima, mantenlos fuera de los grupos de las reglas de uso compartido y decide si la propiedad debería determinar el acceso a estos registros en absoluto. Vuelve a leer Sesgo de propiedad.
5. Una reorganización cambiará cientos de funciones, grupos y reglas de uso compartido en un fin de semana. ¿Cómo la ejecutas?
Como una operación de datos: pruébala con el volumen real en un sandbox de copia completa, aplaza los cálculos de uso compartido, haz todos los cambios, recalcula una sola vez en una ventana de mantenimiento acordada y luego verifica, con un plan alternativo. Vuelve a leer El recálculo del uso compartido es trabajo real.
6. El equipo planea archivar 20 millones de registros con un solo trabajo que copia y borra. ¿Qué cambiarías?
Tres pasos: copiar y marcar como pendiente, verificar el archivo (recuentos, identificadores, relaciones, recuperación), y luego borrar y cambiar, con estados para que un fallo en el registro 14 millones pueda reanudarse con seguridad. Y una copia de seguridad antes de borrar nada. Vuelve a leer El archivado en tres pasos.
7. El cliente no quiere datos almacenados fuera de Salesforce, pero necesita conservar años de historial de citas. ¿Dónde podría vivir el archivo?
Dentro de la plataforma: big objects, o Archive de Salesforce. Con big objects, planifica primero el camino de acceso: sin interfaz ni informes estándar, con consultas a través del índice. Y mantenlo localizable, por ejemplo mostrando las citas archivadas debajo de las vivas. Vuelve a leer ¿Dónde debería vivir el archivo?.
Explora
Sección titulada «Explora »- Salesforce Certified Platform Data Architect Exam Guide (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. ⟲
- Cada módulo tiene su propia sección Explora con la documentación de Salesforce que respalda sus datos.