Projetando para escala
Também em 19 idiomas
English · Español · 日本語 · 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)
Guia de estudo do capítulo 7 do curso Data Architect. Leia primeiro os quatro módulos; esta página ajuda você a conferir o que ficou.
Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.
Este capítulo abre a Parte 2 e a seção Large Data Volumes do exame (20%), junto com o desequilíbrio de dados de Data Modeling. O design de consultas é o próximo capítulo; este trata de volume, pontos quentes, compartilhamento em escala e ciclo de vida. Os números da plataforma mudam, então confira os atuais antes de confiar neles.
Para o exame
Seção intitulada “Para o exame ”Marque conforme avança. Cada item tem um link para onde é ensinado.
LDV-1: um modelo que escala
- Dimensiono um design para o crescimento ao longo do período de retenção, não para o volume de hoje, e multiplico os filhos. (Não pergunte o tamanho de hoje, Agora multiplique os filhos)
- Sei que o volume afeta mais do que as consultas: compartilhamento, propriedade, bloqueios, exibições de lista, relatórios, lotes, cargas, exclusões e recuperação. (As consultas não são a única coisa que fica lenta)
- Sei quando a escala justifica uma desnormalização controlada, e quanto ela custa. (Modelos limpos podem virar modelos caros)
- Sei que não devo transformar o CRM operacional no data warehouse, e que snapshots de relatório não são uma estratégia de data warehouse. (Não transforme o CRM principal no seu data warehouse)
- Sei que o volume tem forma: vinte milhões de registros fazendo o quê? (O volume tem forma)
DM-5: desequilíbrio de dados
- 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) ⟲
- Conheço a solução do pool de contas para um pai artificial, e que é preciso esconder os pais de preenchimento dos usuários. (A conta “Não atribuído”, e os pools de contas)
- Test knowledge: I know Salesforce’s best practice of no more than 10,000 children for one master-detail parent, and what master-detail brings at volume: no owner on the detail, cascade delete, no reparenting unless allowed, roll-up summaries, parent locking. I count the children before I choose master-detail or lookup, and I know converting back to a lookup needs no roll-up summaries on the master. (Master-Detail at Volume) ⟲
- Test knowledge: I know ownership skew (one user owning more than 10,000 records of an object) and the fix: no role, or a separate stable role at the top, and out of public groups used by sharing rules. (Ownership Skew) ⟲
- Conheço o desequilíbrio de pesquisa: muitos registros ativos apontando para um registro, e o bloqueio de registros que ele pode causar. (Desequilíbrio de pesquisa)
- Sei distinguir um desequilíbrio perigoso de um inofensivo pela atividade, não só pela contagem. (Nem todo desequilíbrio é igualmente perigoso)
- Resolvo o desequilíbrio de uma entidade de negócio real com uma divisão com significado (uma conta filha por centro de distribuição), nunca com cópias falsas dela. (Steve Trucking: onde estão os pontos quentes?)
DM-2: compartilhamento em escala
- Sei que as estruturas de acesso (proprietários, papéis, grupos, compartilhamentos) também são dados, e escalam. (O compartilhamento também é dado)
- 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) ⟲ - Sei que uma mudança na hierarquia de papéis com volume é uma operação de dados, então a estabilidade é uma característica do design. (A hierarquia de papéis não é um organograma)
- Test knowledge: I know deferred sharing calculations: make all the changes, then recalculate once in a maintenance window, tested first in a full copy sandbox. (Sharing Recalculation Is Real Work) ⟲
- Test knowledge: I know granular locking (on by default) lets unrelated group operations run together, but doesn’t fix a poor design. (Granular Locking Helps) ⟲
- Sei que desempenho não é desculpa para tornar públicos dados que deveriam ser privados. (Não sacrifique a segurança em nome da otimização)
LDV-2: arquivamento e expurgo
- Sei manter separados retenção, arquivamento e expurgo, e defini-los no início de um projeto. (A exclusão é inevitável)
- Coloco os backups em ordem antes de excluir qualquer coisa, e sei que backup e arquivo são capacidades diferentes (Salesforce Backup & Recover, Archive). (Faça backup antes de excluir)
- Test knowledge: I can choose an archive destination by constraint: big objects, an external store through Salesforce Connect (OData, SQL adapters or a custom adapter), or Salesforce’s Archive. (Where Should the Archive Live?) ⟲
- 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?) ⟲
- Test knowledge: I know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, Bulk API 2.0 hard delete; children before parents. (Deletion Is Inevitable) ⟲
- Conheço o arquivamento em três etapas (copiar e marcar, verificar, excluir e virar a chave), e que ele precisa poder ser retomado. (O arquivamento em três etapas)
- Sei que os dados arquivados precisam continuar encontráveis e manter a sua segurança. (Um arquivo que ninguém encontra é quase uma exclusão, O arquivo continua precisando ser seguro)
Além do exame
Seção intitulada “Além do exame ”O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.
- 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. ⟲
- What works today may fail tomorrow. ⟲
- Às vezes a melhor solução é não criar o problema: mantenha o GPS, as fotos e o histórico de status fora do núcleo.
- O número me diz onde olhar; o comportamento me diz o quanto me preocupar.
- Nessa escala, mudanças organizacionais viram operações de dados.
- As soluções de escala também precisam preservar o significado.
- Encontre os pontos quentes no diagrama: olhe as setas e pergunte quantos registros se acumulam de cada lado.
- Teste o Número de Zeros para o qual você está realmente projetando.
- A IA vai acrescentar mais zeros. Modele explicitamente o volume gerado 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?) ⟲
- Se você não arquiva hoje, algum dia vai arquivar?
- Projete a saída quando projetar a entrada. Cinco respostas por objeto: quando deixa de ser ativo, para onde vai, como provamos, como alguém o encontra, quando é excluído.
- Se os agentes podem alcançar os dados arquivados é decisão do negócio.
Palavras para conhecer
Seção intitulada “Palavras para conhecer ”| Termo | Em uma linha |
|---|---|
| Grande volume de dados (LDV) | Registros suficientes para que o comportamento da plataforma, não só a contagem, molde o design |
| Desequilíbrio de dados (data skew) | Registros demais concentrados num pai, proprietário ou valor de pesquisa |
| Desequilíbrio pai-filho | Filhos demais sob um registro pai |
| Desequilíbrio de propriedade | Um usuário dono de mais de uns 10.000 registros de um objeto |
| Desequilíbrio de pesquisa | Muitos registros ativos referenciando um registro, causando contenção de bloqueios |
| Pool de contas | Vários pais de preenchimento dividindo os filhos de um pai 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 do compartilhamento | A plataforma calculando de novo o acesso depois de uma mudança em proprietários, papéis, grupos ou regras |
| Cálculo de compartilhamento adiado | Segurar o recálculo até um lote de mudanças terminar e então rodá-lo uma vez |
| Bloqueio granular | Bloquear só as partes das tabelas de associação a grupos de que uma operação precisa |
| Retenção | Por quanto tempo os dados são guardados, e por quê |
| Arquivamento | Tirar dados da carga de trabalho ativa mantendo o acesso de que o negócio precisa |
| Expurgo | Remover dados para sempre no fim da sua retenção |
| Arquivamento em três etapas | Copiar e marcar, verificar, depois excluir e virar a chave |
Teste-se
Seção intitulada “Teste-se ”Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.
1. Uma empresa faz um milhão de entregas por ano, cresce 30 por cento e guarda cinco anos. Para qual volume você projeta?
Para cerca de 9 milhões de entregas guardadas ao longo de cinco anos, não um milhão, e depois os filhos delas: cerca de 14,5 milhões de itens de linha a 1,6 por entrega, e 72 milhões de eventos de status a oito por entrega. Releia Não pergunte o tamanho de hoje.
2. Há 300.000 contatos sob uma conta chamada "Contatos não atribuídos". O que você faz?
É um desequilíbrio pai-filho artificial. Espalhe os contatos num pool de contas de pais de preenchimento, cada um abaixo do limite, e esconda esses pais de preenchimento das visões normais de negócio. Ou pergunte se os contatos precisam de uma conta, afinal. Releia A conta “Não atribuído”, e os pools de contas.
3. Um parceiro varejista terá 3,6 milhões de ordens de serviço. Alguém propõe as contas Redrock 001, 002 e 003. O que você acha?
Não: isso corrompe uma entidade de negócio real. Procure uma divisão que o negócio reconheça, como uma conta filha por centro de distribuição, e arquive as entregas concluídas para manter baixos os filhos ativos. Releia Steve Trucking: onde estão os pontos quentes?.
4. Um usuário de integração é dono de 2 milhões de registros e está num papel regional que vai mudar de lugar numa reorganização. Qual é o risco, e a solução?
Movê-lo força o recálculo do acesso em 2 milhões de registros. Dê aos proprietários de alto volume nenhum papel, ou um papel separado e estável no topo, mantenha-os fora dos grupos das regras de compartilhamento e decida se a propriedade deveria determinar o acesso a esses registros, afinal. Releia Desequilíbrio de propriedade.
5. Uma reorganização vai mudar centenas de papéis, grupos e regras de compartilhamento num fim de semana. Como você a conduz?
Como uma operação de dados: teste-a com o volume real num sandbox de cópia completa, adie os cálculos de compartilhamento, faça todas as mudanças, recalcule uma vez numa janela de manutenção combinada e depois verifique, com um plano alternativo. Releia O recálculo do compartilhamento é trabalho de verdade.
6. A equipe planeja arquivar 20 milhões de registros com um único job que copia e exclui. O que você mudaria?
Três etapas: copiar e marcar como pendente, verificar o arquivo (contagens, identificadores, relacionamentos, recuperação), depois excluir e virar a chave, com estados para que uma falha no registro 14 milhões possa ser retomada com segurança. E um backup antes de excluir qualquer coisa. Releia O arquivamento em três etapas.
7. O cliente não quer dados armazenados fora do Salesforce, mas precisa guardar anos de histórico de agendamentos. Onde o arquivo poderia ficar?
Dentro da plataforma: big objects, ou o Archive do Salesforce. Com big objects, planeje primeiro o caminho de acesso: sem interface nem relatórios padrão, consultados pelo índice. E mantenha-o encontrável, por exemplo mostrando os agendamentos arquivados abaixo dos ativos. Releia Onde o arquivo deve ficar?.
Para saber mais
Seção intitulada “Para saber mais ”- Salesforce Certified Platform Data Architect Exam Guide (abre em uma nova aba), 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 tem a sua própria seção Para saber mais com a documentação do Salesforce por trás dos seus fatos.