Concevoir pour le volume
Aussi en 19 langues
English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Guide d’étude du chapitre 7 du cours Data Architect. Lisez d’abord les quatre modules ; cette page vous aide à vérifier ce que vous en avez retenu.
À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.
Ce chapitre ouvre la partie 2 et la section Large Data Volumes de l’examen (20 %), avec le déséquilibre de données de Data Modeling. La conception des requêtes est au chapitre suivant ; celui-ci porte sur le volume, les points chauds, le partage à grande échelle et le cycle de vie. Les chiffres de la plateforme changent, alors vérifiez les valeurs actuelles avant de vous y fier.
Pour l’examen
Section intitulée « Pour l’examen »Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.
LDV-1 : un modèle qui passe à l’échelle
- Je dimensionne une conception pour la croissance sur toute la durée de conservation, pas pour le volume d’aujourd’hui, et je multiplie les enfants. (Ne demandez pas sa taille d’aujourd’hui, Multipliez maintenant les enfants)
- Je sais que le volume affecte plus que les requêtes : partage, propriété, verrouillage, vues de liste, rapports, traitements par lots, chargements, suppressions et reprise. (Les requêtes ne sont pas les seules à ralentir)
- Je sais quand une dénormalisation maîtrisée est justifiée par le volume, et ce qu’elle coûte. (Les modèles propres peuvent devenir des modèles coûteux)
- Je sais qu’il ne faut pas transformer le CRM opérationnel en entrepôt de données, et que les instantanés de rapport ne sont pas une stratégie d’entrepôt de données. (Ne faites pas du CRM principal votre entrepôt de données)
- Je sais que le volume a une forme : vingt millions d’enregistrements qui font quoi ? (Le volume a une forme)
DM-5 : le déséquilibre de données
- 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) ⟲
- Je connais la correction par pool de comptes pour un parent artificiel, et je sais qu’il faut cacher les parents de remplissage aux utilisateurs. (Le compte « Non attribué », et les pools de comptes)
- 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) ⟲
- Je connais le déséquilibre de référence : beaucoup d’enregistrements actifs qui pointent vers un seul enregistrement, et le verrouillage des enregistrements qu’il peut provoquer. (Le déséquilibre de référence)
- Je sais distinguer un déséquilibre dangereux d’un déséquilibre inoffensif par son activité, pas seulement par son nombre. (Tous les déséquilibres ne sont pas aussi dangereux)
- Je corrige un déséquilibre sur une entité métier réelle par un découpage qui a du sens (un compte enfant par centre de distribution), jamais par de fausses copies. (Steve Trucking : où sont les points chauds ?)
DM-2 : le partage à grande échelle
- Je sais que les structures d’accès (propriétaires, rôles, groupes, partages) sont aussi des données, et qu’elles grandissent. (Le partage, c’est aussi des données)
- 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) ⟲ - Je sais qu’un changement de hiérarchie des rôles à fort volume est une opération sur les données, donc que la stabilité est une caractéristique de conception. (La hiérarchie des rôles n’est pas un organigramme)
- 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) ⟲
- Je sais que la performance n’est pas une excuse pour rendre publiques des données qui doivent rester privées. (N’optimisez pas au détriment de la sécurité)
LDV-2 : archivage et purge
- Je sais séparer conservation, archivage et purge, et les définir au début d’un projet. (La suppression est inévitable)
- Je mets des sauvegardes en place avant toute suppression, et je sais que sauvegarde et archive sont des capacités différentes (Salesforce Backup & Recover, Archive). (Sauvegardez avant de supprimer)
- 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) ⟲
- Je connais l’archivage en trois étapes (copier et marquer, vérifier, supprimer et basculer), et je sais qu’il doit pouvoir redémarrer. (L’archivage en trois étapes)
- Je sais que les données archivées doivent rester retrouvables et garder leur sécurité. (Une archive que personne ne retrouve est presque une suppression, L’archive doit quand même être sécurisée)
Au-delà de l’examen
Section intitulée « Au-delà de l’examen »L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.
- 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. ⟲
- Parfois, la meilleure correction, c’est de ne pas créer le problème : gardez le GPS, les photos et l’historique des statuts hors du cœur.
- Le chiffre me dit où regarder ; le comportement me dit à quel point m’inquiéter.
- À cette échelle, les changements d’organisation deviennent des opérations sur les données.
- Les corrections pour le volume doivent quand même préserver le sens.
- Trouvez les points chauds sur le diagramme : regardez les flèches et demandez combien d’enregistrements s’accumulent de chaque côté.
- Testez le Nombre de zéros pour lequel vous concevez réellement.
- L’IA va ajouter des zéros. Modélisez explicitement le volume généré par les agents.
- 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 vous n’archivez pas aujourd’hui, allez-vous un jour archiver ?
- Concevez la sortie quand vous concevez l’entrée. Cinq réponses par objet : quand il cesse d’être actif, où il va, comment on le prouve, comment on le retrouve, quand il est supprimé.
- Que les agents puissent atteindre les données archivées, c’est au métier d’en décider.
Les mots à connaître
Section intitulée « Les mots à connaître »| Terme | En une ligne |
|---|---|
| Gros volumes de données (LDV) | Assez d’enregistrements pour que le comportement de la plateforme, pas seulement le nombre, façonne la conception |
| Déséquilibre de données (data skew) | Trop d’enregistrements concentrés sur un même parent, propriétaire ou valeur de référence |
| Déséquilibre parent-enfant | Trop d’enfants sous un même enregistrement parent |
| Déséquilibre de propriété | Un utilisateur qui possède plus d’environ 10 000 enregistrements d’un objet |
| Déséquilibre de référence | Beaucoup d’enregistrements actifs qui référencent un seul enregistrement, ce qui provoque des conflits de verrouillage |
| Pool de comptes | Plusieurs parents de remplissage qui se partagent les enfants d’un parent artificiel |
| 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 |
| Recalcul du partage | La plateforme qui recalcule les accès après un changement de propriétaires, de rôles, de groupes ou de règles |
| Calcul de partage différé | Retenir le recalcul jusqu’à ce qu’un lot de changements soit terminé, puis l’exécuter une seule fois |
| Verrouillage granulaire | Ne verrouiller que les parties des tables d’appartenance aux groupes dont une opération a besoin |
| Conservation | Combien de temps les données sont gardées, et pourquoi |
| Archivage | Sortir des données de la charge de travail active tout en gardant l’accès dont le métier a besoin |
| Purge | Supprimer définitivement des données à la fin de leur durée de conservation |
| Archivage en trois étapes | Copier et marquer, vérifier, puis supprimer et basculer |
Testez-vous
Section intitulée « Testez-vous »De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.
1. Une entreprise effectue un million de livraisons par an, avec 30 % de croissance, et les conserve cinq ans. Pour quel volume concevez-vous ?
Environ 9 millions de livraisons conservées sur cinq ans, pas un million, puis leurs enfants : environ 14,5 millions d’articles à 1,6 par livraison, et 72 millions d’événements de statut à huit par livraison. Relisez Ne demandez pas sa taille d’aujourd’hui.
2. 300 000 contacts sont rangés sous un compte appelé « Contacts non attribués ». Que faites-vous ?
C’est un déséquilibre parent-enfant artificiel. Répartissez les contacts dans un pool de comptes de parents de remplissage, chacun sous le seuil, et cachez ces parents des vues métier normales. Ou demandez si les contacts ont vraiment besoin d’un compte. Relisez Le compte « Non attribué », et les pools de comptes.
3. Un partenaire distributeur aura 3,6 millions d'ordres d'exécution. Quelqu'un propose des comptes Redrock 001, 002 et 003. Votre avis ?
Non : cela corrompt une entité métier réelle. Cherchez un découpage que le métier reconnaît, comme un compte enfant par centre de distribution, et archivez les livraisons terminées pour garder peu d’enfants actifs. Relisez Steve Trucking : où sont les points chauds ?.
4. Un utilisateur d'intégration possède 2 millions d'enregistrements et se trouve dans un rôle régional qui va être déplacé lors d'une réorganisation. Quel est le risque, et la correction ?
Le déplacer force un recalcul des accès sur 2 millions d’enregistrements. Ne donnez aucun rôle aux propriétaires à fort volume, ou un rôle distinct et stable au sommet, tenez-les hors des groupes des règles de partage, et décidez si la propriété doit vraiment piloter l’accès pour ces enregistrements. Relisez Le déséquilibre de propriété.
5. Une réorganisation va changer des centaines de rôles, de groupes et de règles de partage en un week-end. Comment la menez-vous ?
Comme une opération sur les données : testez-la au vrai volume dans un sandbox complet, différez les calculs de partage, faites tous les changements, recalculez une seule fois dans une fenêtre de maintenance convenue, puis vérifiez, avec un plan de repli. Relisez Le recalcul du partage est un vrai travail.
6. L'équipe prévoit d'archiver 20 millions d'enregistrements avec un seul traitement qui copie et supprime. Que changeriez-vous ?
Trois étapes : copier et marquer en attente, vérifier l’archive (décomptes, identifiants, relations, récupération), puis supprimer et basculer, avec des états pour qu’un échec à l’enregistrement 14 millions puisse redémarrer en sécurité. Et une sauvegarde avant toute suppression. Relisez L’archivage en trois étapes.
7. Le client ne veut pas de données stockées hors de Salesforce, mais doit garder des années d'historique de rendez-vous. Où l'archive pourrait-elle vivre ?
Sur la plateforme : les big objects, ou l’Archive de Salesforce. Avec les big objects, planifiez d’abord le chemin d’accès : pas d’interface ni de rapports standard, des requêtes par l’index. Et gardez-la retrouvable, par exemple en affichant les rendez-vous archivés sous les rendez-vous actifs. Relisez Où l’archive doit-elle vivre ?.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Guide d’examen Architecte de données de plate-forme certifié Salesforce (s'ouvre dans un nouvel onglet), 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 section Pour aller plus loin de chaque module liste la documentation Salesforce derrière ses faits.