Projektowanie pod skalę
Dostępne także w 19 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Przewodnik do nauki do rozdziału 7 kursu Data Architect. Najpierw przeczytaj cztery moduły; ta strona pomoże ci sprawdzić, co zostało w głowie.
O tym przewodniku. Powstał wyłącznie na podstawie treści tego kursu i listy celów z opublikowanego przez Salesforce przewodnika po egzaminie. Nigdy nie opiera się na prawdziwych pytaniach egzaminacyjnych i nie twierdzi, że wie, co jest na egzaminie. Jeśli masz egzamin za sobą, proszę, nie przysyłaj mi z niego pytań: umowa certyfikacyjna zabrania ich udostępniania, a wkuwanie odpowiedzi i tak jest złą drogą do zostania architektem.
Ten rozdział otwiera część 2 i część egzaminu Large Data Volumes (20%), razem z nierównomiernym rozkładem danych z części Data Modeling. Projektowanie zapytań jest w następnym rozdziale; ten jest o wolumenie, gorących punktach, udostępnianiu w dużej skali i cyklu życia. Liczby platformy się zmieniają, więc zanim na nich polegasz, sprawdź aktualne.
Na egzamin
Dział zatytułowany „Na egzamin ”Odhaczaj je po kolei. Każdy punkt prowadzi do miejsca, w którym go omówiono.
LDV-1: model, który się skaluje
- Wymiaruję projekt według wzrostu w całym okresie retencji, a nie według dzisiejszego wolumenu, i mnożę rekordy podrzędne. (Nie pytaj, jak duże to jest dziś, Teraz pomnóż rekordy podrzędne)
- Wiem, że wolumen wpływa na więcej niż zapytania: udostępnianie, własność, blokady, widoki list, raporty, zadania wsadowe, ładowanie, usuwanie i odzyskiwanie. (Nie tylko zapytania zwalniają)
- Wiem, kiedy skala uzasadnia kontrolowaną denormalizację i ile ona kosztuje. (Czyste modele mogą stać się drogimi modelami)
- Wiem, żeby nie zamieniać operacyjnego CRM w hurtownię danych, i że migawki raportowe to nie strategia hurtowni danych. (Nie zamieniaj podstawowego CRM w hurtownię danych)
- Wiem, że wolumen ma kształt: dwadzieścia milionów rekordów, które robią co? (Wolumen ma kształt)
DM-5: nierównomierny rozkład danych
- 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) ⟲
- Znam rozwiązanie z pulą kont dla sztucznego rekordu nadrzędnego i wiem, że zastępcze rekordy nadrzędne trzeba ukryć przed użytkownikami. (Konto „Unassigned” i pule kont)
- 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) ⟲
- Znam nierównomierny rozkład wyszukiwań: wiele aktywnych rekordów wskazujących na jeden rekord i blokowanie rekordów, które może z tego wynikać. (Nierównomierny rozkład wyszukiwań)
- Potrafię odróżnić groźny nierównomierny rozkład od nieszkodliwego po jego aktywności, a nie tylko po liczbie. (Nie każdy nierównomierny rozkład jest równie groźny)
- Naprawiam nierównomierny rozkład na prawdziwym podmiocie biznesowym znaczącym podziałem (konto podrzędne dla każdego centrum dystrybucyjnego), nigdy jego fałszywymi kopiami. (Steve Trucking: gdzie są gorące punkty?)
DM-2: udostępnianie w dużej skali
- Wiem, że struktury dostępu (właściciele, role, grupy, udostępnienia) to też dane i że się skalują. (Udostępnianie to też dane)
- 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) ⟲ - Wiem, że zmiana hierarchii ról przy dużym wolumenie to operacja na danych, więc stabilność jest cechą projektu. (Hierarchia ról to nie schemat organizacyjny)
- 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) ⟲
- Wiem, że wydajność nie jest wymówką, żeby upubliczniać dane, które powinny być prywatne. (Nie optymalizuj kosztem bezpieczeństwa)
LDV-2: archiwizacja i czyszczenie
- Potrafię rozdzielić retencję, archiwizację i czyszczenie i ustalić je na początku projektu. (Usuwanie jest nieuniknione)
- Przygotowuję kopie zapasowe, zanim cokolwiek zostanie usunięte, i wiem, że kopia zapasowa i archiwum to różne możliwości (Salesforce Backup & Recover, Archive). (Zrób kopię zapasową, zanim usuniesz)
- 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) ⟲
- Znam archiwum w trzech krokach (skopiuj i oznacz, zweryfikuj, usuń i przełącz) i wiem, że musi dać się wznowić. (Archiwum w trzech krokach)
- Wiem, że dane zarchiwizowane muszą dać się znaleźć i zachować swoje zabezpieczenia. (Archiwum, którego nikt nie może znaleźć, to prawie usunięcie, Archiwum nadal musi być bezpieczne)
Poza egzaminem
Dział zatytułowany „Poza egzaminem ”Egzamin to podłoga, nie sufit. Oto nawyki z tego rozdziału, których architekt potrzebuje, niezależnie od tego, czy jakiekolwiek pytanie o nie zapyta.
- 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. ⟲
- Czasem najlepszą poprawką jest nie stworzyć problemu: trzymaj GPS, zdjęcia i historię statusów poza core.
- Liczba mówi mi, gdzie patrzeć; zachowanie mówi mi, jak bardzo się martwić.
- W tej skali zmiany organizacyjne stają się operacjami na danych.
- Poprawki skali nadal muszą zachowywać znaczenie.
- Znajdź gorące punkty na diagramie: patrz na strzałki i pytaj, ile rekordów gromadzi się po każdej stronie.
- Testuj Liczbę Zer, dla której naprawdę projektujesz.
- AI doda więcej zer. Modeluj jawnie wolumen generowany przez agentów.
- 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?) ⟲
- Jeśli nie archiwizujesz dziś, czy kiedykolwiek będziesz archiwizować?
- Projektuj wyjście, gdy projektujesz wejście. Pięć odpowiedzi na obiekt: kiedy przestaje być aktywny, dokąd trafia, jak to udowodnimy, jak ktoś go znajdzie, kiedy zostanie usunięty.
- To, czy agenci mogą sięgać do danych zarchiwizowanych, jest decyzją biznesu.
Słowa do zapamiętania
Dział zatytułowany „Słowa do zapamiętania ”| Termin | W jednym zdaniu |
|---|---|
| Duży wolumen danych (LDV) | Tyle rekordów, że projekt kształtuje zachowanie platformy, a nie tylko ich liczba |
| Nierównomierny rozkład danych | Zbyt wiele rekordów skupionych na jednym rekordzie nadrzędnym, właścicielu lub wartości wyszukiwania |
| Nierównomierny rozkład nadrzędny-podrzędny | Zbyt wiele rekordów podrzędnych pod jednym rekordem nadrzędnym |
| Nierównomierny rozkład własności | Jeden użytkownik jest właścicielem ponad około 10 000 rekordów obiektu |
| Nierównomierny rozkład wyszukiwań | Wiele aktywnych rekordów odwołujących się do jednego rekordu, co powoduje rywalizację o blokady |
| Pula kont | Kilka zastępczych rekordów nadrzędnych dzielących rekordy podrzędne sztucznego rekordu nadrzędnego |
| 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 |
| Przeliczanie udostępniania | Ponowne wyliczanie dostępu przez platformę po zmianie właścicieli, ról, grup lub reguł |
| Odroczone obliczenia udostępniania | Wstrzymanie przeliczania do zakończenia serii zmian, a potem jednorazowe uruchomienie |
| Blokowanie granularne | Blokowanie tylko tych części tabel członkostwa w grupach, których potrzebuje operacja |
| Retencja | Jak długo dane są przechowywane i dlaczego |
| Archiwizacja | Wyprowadzanie danych z aktywnego obciążenia z zachowaniem dostępu, którego potrzebuje biznes |
| Czyszczenie | Trwałe usuwanie danych na koniec ich okresu retencji |
| Archiwum w trzech krokach | Skopiuj i oznacz, zweryfikuj, potem usuń i przełącz |
Sprawdź się
Dział zatytułowany „Sprawdź się ”Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.
1. Firma realizuje milion dostaw rocznie, rośnie o 30 procent i przechowuje pięć lat. Dla jakiego wolumenu projektujesz?
Dla około 9 milionów dostaw przechowywanych przez pięć lat, a nie dla miliona, a potem dla ich rekordów podrzędnych: około 14,5 miliona pozycji przy 1,6 na dostawę i 72 miliony zdarzeń statusu przy ośmiu na dostawę. Przeczytaj ponownie Nie pytaj, jak duże to jest dziś.
2. Pod jednym kontem o nazwie „Unassigned Contacts” jest 300 000 kontaktów. Co robisz?
To sztuczny nierównomierny rozkład nadrzędny-podrzędny. Rozłóż kontakty na pulę kont z zastępczymi rekordami nadrzędnymi, każdy poniżej progu, i ukryj te rekordy zastępcze przed normalnymi widokami biznesowymi. Albo zapytaj, czy te kontakty w ogóle potrzebują konta. Przeczytaj ponownie Konto „Unassigned” i pule kont.
3. Jeden partner detaliczny będzie miał 3,6 miliona zleceń pracy. Ktoś proponuje konta Redrock 001, 002 i 003. Twoje zdanie?
Nie: to psuje prawdziwy podmiot biznesowy. Szukaj podziału, który biznes rozpozna, na przykład konta podrzędnego dla każdego centrum dystrybucyjnego, i archiwizuj zakończone dostawy, żeby liczba aktywnych rekordów podrzędnych była niska. Przeczytaj ponownie Steve Trucking: gdzie są gorące punkty?.
4. Użytkownik integracji jest właścicielem 2 milionów rekordów i ma rolę regionalną, która ma zostać przeniesiona w reorganizacji. Jakie jest ryzyko i jak to naprawić?
Przeniesienie go wymusza przeliczenie dostępu w 2 milionach rekordów. Nie dawaj właścicielom dużej liczby rekordów roli albo daj im osobną, stabilną rolę na szczycie, trzymaj ich poza grupami reguł udostępniania i zdecyduj, czy w ogóle własność powinna sterować dostępem do tych rekordów. Przeczytaj ponownie Nierównomierny rozkład własności.
5. Reorganizacja zmieni w ciągu weekendu setki ról, grup i reguł udostępniania. Jak ją przeprowadzisz?
Jako operację na danych: przetestuj przy prawdziwym wolumenie w sandboxie z pełną kopią, odrocz obliczenia udostępniania, wprowadź wszystkie zmiany, przelicz raz w uzgodnionym oknie serwisowym, potem zweryfikuj, z planem awaryjnym. Przeczytaj ponownie Przeliczanie udostępniania to prawdziwa praca.
6. Zespół planuje zarchiwizować 20 milionów rekordów jednym zadaniem, które kopiuje i usuwa. Co warto zmienić?
Trzy kroki: skopiuj i oznacz jako oczekujące, zweryfikuj archiwum (liczby, identyfikatory, relacje, pobieranie), potem usuń i przełącz, ze stanami, dzięki którym awarię na 14-milionowym rekordzie da się bezpiecznie wznowić. I kopia zapasowa, zanim cokolwiek zostanie usunięte. Przeczytaj ponownie Archiwum w trzech krokach.
7. Klient nie chce przechowywać danych poza Salesforce, ale musi trzymać wiele lat historii wizyt. Gdzie może być archiwum?
Na platformie: big objects albo Archive od Salesforce. Przy big objects najpierw zaplanuj ścieżkę dostępu: bez standardowego interfejsu i raportowania, zapytania przez indeks. I zadbaj, żeby dało się je znaleźć, na przykład pokazując zarchiwizowane wizyty pod bieżącymi. Przeczytaj ponownie Gdzie powinno być archiwum?.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Salesforce Certified Platform Data Architect Exam Guide (otwiera się w nowej karcie), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Sekcja „Do zgłębienia” w każdym module wymienia dokumentację Salesforce stojącą za jego faktami.