Progettare per la scala
Disponibile anche in 19 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Guida allo studio del capitolo 7 del corso Data Architect. Leggi prima i quattro moduli; questa pagina ti aiuta a verificare cosa ti è rimasto.
Su questa guida allo studio. È costruita solo con i contenuti di questo corso e con l’elenco degli obiettivi della guida all’esame pubblicata da Salesforce. Non si basa mai su domande reali d’esame, e non pretende di sapere cosa c’è nell’esame. Se hai sostenuto l’esame, per favore non mandarmi domande: l’accordo di certificazione vieta di condividerle, e memorizzare le risposte è comunque il modo sbagliato per diventare architetto.
Questo capitolo apre la Parte 2 e la sezione Large Data Volumes dell’esame (20%), con lo squilibrio dei dati di Data Modeling. La progettazione delle query è nel prossimo capitolo; questo parla di volume, punti caldi, condivisione su larga scala e ciclo di vita. I numeri della piattaforma cambiano, quindi verifica quelli attuali prima di farci affidamento.
Per l’esame
Sezione intitolata “Per l’esame ”Spuntali man mano. Ognuno rimanda al punto in cui è spiegato.
LDV-1: un modello che scala
- Dimensiono un progetto per la crescita lungo tutto il periodo di conservazione, non per il volume di oggi, e moltiplico i figli. (Non chiedere quanto è grande oggi, Ora moltiplica i figli)
- So che il volume incide su più delle query: condivisione, titolarità, blocchi, viste elenco, report, batch, caricamenti, eliminazioni e ripristino. (Non sono solo le query a rallentare)
- So quando una denormalizzazione controllata è giustificata dalla scala, e quanto costa. (I modelli puliti possono diventare modelli costosi)
- So che non devo trasformare il CRM operativo nel data warehouse, e che gli snapshot dei report non sono una strategia di data warehouse. (Non trasformare il CRM principale nel tuo data warehouse)
- So che il volume ha una forma: venti milioni di record che fanno cosa? (Il volume ha una forma)
DM-5: lo squilibrio dei dati
- 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) ⟲
- Conosco la soluzione del pool di account per un padre artificiale, e so che i padri segnaposto vanno nascosti agli utenti. (L’account “Non assegnato” e i pool di account)
- 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) ⟲
- Conosco lo squilibrio di ricerca: tanti record attivi che puntano a un solo record, e il blocco dei record che può causare. (Lo squilibrio di ricerca)
- So distinguere uno squilibrio pericoloso da uno innocuo in base alla sua attività, non solo al suo numero. (Non tutti gli squilibri sono ugualmente pericolosi)
- Correggo lo squilibrio su un’entità di business reale con una suddivisione che abbia significato (un account figlio per centro di distribuzione), mai con copie finte. (Steve Trucking: dove sono i punti caldi?)
DM-2: la condivisione su larga scala
- So che le strutture di accesso (titolari, ruoli, gruppi, condivisioni) sono anch’esse dati, e che scalano. (Anche la condivisione è un dato)
- 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) ⟲ - So che una modifica alla gerarchia dei ruoli ad alto volume è un’operazione sui dati, quindi la stabilità è una caratteristica di progetto. (La gerarchia dei ruoli non è un organigramma)
- 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) ⟲
- So che le prestazioni non sono una scusa per rendere pubblici dati che dovrebbero essere privati. (Non sacrificare la sicurezza all’ottimizzazione)
LDV-2: archiviazione ed eliminazione definitiva
- So tenere separate conservazione, archiviazione ed eliminazione definitiva, e definirle all’inizio di un progetto. (L’eliminazione è inevitabile)
- Metto in piedi i backup prima che si elimini qualsiasi cosa, e so che backup e archivio sono capacità diverse (Salesforce Backup & Recover, Archive). (Fai il backup prima di eliminare)
- 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) ⟲
- Conosco l’archiviazione in tre passaggi (copia e contrassegna, verifica, elimina e commuta), e so che deve poter ripartire. (L’archiviazione in tre passaggi)
- So che i dati archiviati devono restare reperibili e mantenere la loro sicurezza. (Un archivio che nessuno trova è quasi un’eliminazione, L’archivio deve comunque essere sicuro)
Oltre l’esame
Sezione intitolata “Oltre l’esame ”L’esame è il pavimento, non il soffitto. Queste sono le abitudini di questo capitolo di cui un architetto ha bisogno, che una domanda le chieda o no.
- 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. ⟲
- A volte la soluzione migliore è non creare il problema: tieni GPS, foto e storico degli stati fuori dal core.
- Il numero mi dice dove guardare; il comportamento mi dice quanto preoccuparmi.
- A questa scala, i cambiamenti organizzativi diventano operazioni sui dati.
- Le soluzioni per la scala devono comunque preservare il significato.
- Trova i punti caldi sul diagramma: guarda le frecce e chiediti quanti record si accumulano da ogni lato.
- Testa il Numero di Zeri per cui stai davvero progettando.
- L’IA aggiungerà altri zeri. Modella esplicitamente il volume generato dagli agenti.
- 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 non archiviate oggi, archivierete mai?
- Progetta l’uscita quando progetti l’entrata. Cinque risposte per oggetto: quando smette di essere attivo, dove va, come lo dimostriamo, come lo trova qualcuno, quando viene eliminato.
- Se gli agenti possono raggiungere i dati archiviati lo decide il business.
Parole da conoscere
Sezione intitolata “Parole da conoscere ”| Termine | In una riga |
|---|---|
| Grandi volumi di dati (LDV) | Abbastanza record perché sia il comportamento della piattaforma, non solo il numero, a determinare il progetto |
| Squilibrio dei dati (data skew) | Troppi record concentrati su un solo padre, titolare o valore di ricerca |
| Squilibrio padre-figlio | Troppi figli sotto un solo record padre |
| Squilibrio di titolarità | Un utente titolare di più di circa 10.000 record di un oggetto |
| Squilibrio di ricerca | Tanti record attivi che fanno riferimento a un solo record, causando contesa sui blocchi |
| Pool di account | Diversi padri segnaposto che si dividono i figli di un padre artificiale |
| 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 |
| Ricalcolo della condivisione | La piattaforma che ricalcola gli accessi dopo una modifica a titolari, ruoli, gruppi o regole |
| Calcolo di condivisione rimandato | Trattenere il ricalcolo finché un lotto di modifiche è completo, poi eseguirlo una volta |
| Blocco granulare | Bloccare solo le parti delle tabelle di appartenenza ai gruppi di cui un’operazione ha bisogno |
| Conservazione | Per quanto tempo i dati vengono tenuti, e perché |
| Archiviazione | Spostare dati fuori dal carico di lavoro attivo mantenendo l’accesso di cui il business ha bisogno |
| Eliminazione definitiva | Rimuovere per sempre i dati alla fine del loro periodo di conservazione |
| Archiviazione in tre passaggi | Copia e contrassegna, verifica, poi elimina e commuta |
Mettiti alla prova
Sezione intitolata “Mettiti alla prova ”Brevi scenari nello stile del corso. Decidi la tua risposta prima di aprirla.
1. Un'azienda effettua un milione di consegne all'anno, cresce del 30 per cento e conserva cinque anni. Per quale volume progetti?
Circa 9 milioni di consegne conservate in cinque anni, non un milione, e poi i loro figli: circa 14,5 milioni di voci a 1,6 per consegna, e 72 milioni di eventi di stato a otto per consegna. Rileggi Non chiedere quanto è grande oggi.
2. 300.000 contatti stanno sotto un account chiamato “Contatti non assegnati”. Cosa fai?
È uno squilibrio padre-figlio artificiale. Distribuisci i contatti in un pool di account di padri segnaposto, ciascuno sotto la soglia, e nascondi quei segnaposto dalle normali viste di business. Oppure chiediti se i contatti abbiano davvero bisogno di un account. Rileggi L’account “Non assegnato” e i pool di account.
3. Un partner retail avrà 3,6 milioni di ordini di lavoro. Qualcuno propone gli account Redrock 001, 002 e 003. Cosa ne pensi?
No: corrompe un’entità di business reale. Cerca una suddivisione che il business riconosca, come un account figlio per centro di distribuzione, e archivia le consegne completate per tenere bassi i figli attivi. Rileggi Steve Trucking: dove sono i punti caldi?.
4. Un utente di integrazione è titolare di 2 milioni di record e si trova in un ruolo regionale che sta per essere spostato in una riorganizzazione. Qual è il rischio, e la soluzione?
Spostarlo impone un ricalcolo degli accessi su 2 milioni di record. Non dare un ruolo ai titolari ad alto volume, o dagli un ruolo separato e stabile in cima, tienili fuori dai gruppi delle regole di condivisione, e decidi se la titolarità debba davvero guidare l’accesso per questi record. Rileggi Lo squilibrio di titolarità.
5. Una riorganizzazione cambierà centinaia di ruoli, gruppi e regole di condivisione in un fine settimana. Come la gestisci?
Come un’operazione sui dati: testala al volume reale in una sandbox Full, rimanda i calcoli di condivisione, fai tutte le modifiche, ricalcola una volta in una finestra di manutenzione concordata, poi verifica, con un piano di riserva. Rileggi Il ricalcolo della condivisione è lavoro vero.
6. Il team prevede di archiviare 20 milioni di record con un solo job che copia ed elimina. Cosa cambieresti?
Tre passaggi: copia e contrassegna come in attesa, verifica l’archivio (conteggi, identificativi, relazioni, recupero), poi elimina e commuta, con stati che permettano a un errore al record 14 milioni di ripartire in sicurezza. E un backup prima di eliminare qualsiasi cosa. Rileggi L’archiviazione in tre passaggi.
7. Il cliente non vuole dati archiviati fuori da Salesforce, ma deve conservare anni di storico degli appuntamenti. Dove potrebbe vivere l'archivio?
Sulla piattaforma: big object, o l’Archive di Salesforce. Con i big object, pianifica prima il percorso di accesso: niente interfaccia o report standard, query attraverso l’indice. E mantienilo reperibile, per esempio mostrando gli appuntamenti archiviati sotto quelli attivi. Rileggi Dove deve vivere l’archivio?.
Per approfondire
Sezione intitolata “Per approfondire ”- Salesforce Certified Platform Data Architect Exam Guide (si apre in una nuova scheda), 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 sezione Per approfondire di ogni modulo elenca la documentazione Salesforce dietro i suoi fatti.