Перейти до вмісту
SteveTechArcSteveTechArc Courses

Проєктування для масштабу

Також доступно 19 мовами

English · Español · 日本語 · 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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Зображення згенеровано ШІ

Навчальний посібник до розділу 7 курсу Data Architect. Спершу прочитайте чотири модулі; ця сторінка допоможе перевірити, що запам’яталося.

Про цей посібник. Він побудований лише на власному змісті цього курсу та на переліку цілей в опублікованому посібнику Salesforce до іспиту. Він ніколи не спирається на справжні екзаменаційні запитання і не претендує на знання того, що буде на іспиті. Якщо ви складали іспит, будь ласка, не надсилайте мені запитань із нього: сертифікаційна угода забороняє ними ділитися, а завчати відповіді — у будь-якому разі хибний шлях до того, щоб стати архітектором.

Цей розділ відкриває Частину 2 і розділ іспиту Large Data Volumes (20%), разом із перекосом даних із Data Modeling. Проєктування запитів — у наступному розділі; цей — про обсяг, гарячі точки, спільний доступ у масштабі та життєвий цикл. Числа платформи змінюються, тож перевіряйте актуальні, перш ніж на них покладатися.

Для іспиту

Section titled “Для іспиту ”

Позначайте їх у міру просування. Кожен пункт веде туди, де його пояснено.

LDV-1: модель, що масштабується

DM-5: перекіс даних

  • 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) ⟲
  • Я знаю виправлення через пул акаунтів для штучного батьківського запису і те, що батьківські записи-заповнювачі слід ховати від користувачів. (Акаунт «Unassigned» і пули акаунтів)
  • 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) ⟲
  • Я знаю перекіс lookup: багато активних записів, що вказують на один запис, і блокування записів, яке це може спричинити. (Перекіс lookup)
  • Я можу відрізнити небезпечний перекіс від нешкідливого за його активністю, а не лише за кількістю. (Не кожен перекіс однаково небезпечний)
  • Я виправляю перекіс на справжній бізнес-сутності змістовним поділом (дочірній акаунт на кожен розподільчий центр), а не її фальшивими копіями. (Steve Trucking: де гарячі точки?)

DM-2: спільний доступ у масштабі

  • Я знаю, що структури доступу (власники, ролі, групи, надання доступу) — теж дані, і вони масштабуються. (Спільний доступ — теж дані)
  • 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) ⟲
  • Я знаю, що зміна ієрархії ролей на великих обсягах — це операція з даними, тож стабільність — властивість проєкту. (Ієрархія ролей — не оргсхема)
  • 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) ⟲
  • Я знаю, що продуктивність — не виправдання, щоб робити публічними дані, які мають бути приватними. (Не оптимізуйте безпеку до нуля)

LDV-2: архівування й остаточне видалення

За межами іспиту

Section titled “За межами іспиту ”

Іспит — це підлога, а не стеля. Ось звички з цього розділу, потрібні архітекторові, незалежно від того, чи спитають про них колись на іспиті.

  • 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. ⟲
  • Іноді найкраще виправлення — не створювати проблему: тримайте GPS, фото й історію статусів поза ядром.
  • Число каже мені, куди дивитися; поведінка каже, наскільки хвилюватися.
  • На такому масштабі організаційні зміни стають операціями з даними.
  • Виправлення заради масштабу все одно мають зберігати зміст.
  • Знайдіть гарячі точки на діаграмі: подивіться на стрілки і спитайте, скільки записів накопичується з кожного боку.
  • Тестуйте ту «кількість нулів», для якої ви справді проєктуєте.
  • ШІ додасть ще нулів. Явно моделюйте обсяг, що генерують агенти.
  • 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?) ⟲
  • Якщо ви не архівуєте сьогодні, чи будете ви колись архівувати?
  • Проєктуйте вихід, коли проєктуєте вхід. П’ять відповідей для кожного об’єкта: коли він перестає бути активним, куди йде, як ми це доводимо, як його знаходять, коли його видаляють.
  • Чи можуть агенти дістатися до архівних даних — вирішує бізнес.

Ключові терміни

Section titled “Ключові терміни ”
ТермінОдним реченням
Великі обсяги даних (LDV)Достатньо записів, щоб проєкт визначала поведінка платформи, а не лише кількість
Перекіс данихЗабагато записів, сконцентрованих на одному батьківському записі, власникові чи значенні lookup
Перекіс «батько–нащадок»Забагато дочірніх записів під одним батьківським
Перекіс власностіОдин користувач володіє понад приблизно 10 000 записів одного об’єкта
Перекіс lookupБагато активних записів посилаються на один запис, спричиняючи конкуренцію за блокування
Пул акаунтівКілька батьківських записів-заповнювачів, що ділять між собою дочірні записи штучного батьківського
Controlled by ParentA sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain
Share objectThe table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause
Big objectAn object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only
Перерахунок спільного доступуПлатформа заново прораховує доступ після зміни власників, ролей, груп чи правил
Відкладене обчислення спільного доступуЗатримка перерахунку, доки не завершиться пакет змін, а потім один запуск
Гранулярне блокуванняБлокування лише тих частин таблиць членства в групах, які потрібні операції
ЗберіганняЯк довго зберігають дані і чому
АрхівуванняВиведення даних з активного навантаження зі збереженням доступу, потрібного бізнесу
Остаточне видаленняВидалення даних назавжди наприкінці строку зберігання
Архівування у три крокиСкопіювати й позначити, перевірити, потім видалити й перемкнути

Перевірте себе

Section titled “Перевірте себе ”

Короткі сценарії в стилі курсу. Визначтеся з відповіддю, перш ніж розгорнути її.

1. Компанія робить мільйон доставок на рік, зростає на 30 відсотків і зберігає дані п’ять років. На який обсяг ви проєктуєте?

Приблизно на 9 мільйонів доставок, збережених за п’ять років, а не на мільйон, а потім на їхні дочірні записи: приблизно 14,5 мільйона рядків при 1,6 на доставку і 72 мільйони подій статусу при восьми на доставку. Перечитайте Не питайте, наскільки великим це є сьогодні.

2. 300 000 контактів сидять під одним акаунтом «Unassigned Contacts». Що ви робите?

Це штучний перекіс «батько–нащадок». Розподіліть контакти між пулом акаунтів-заповнювачів, кожен під порогом, і сховайте ці заповнювачі від звичайних бізнесових представлень. Або спитайте, чи взагалі контактам потрібен акаунт. Перечитайте Акаунт «Unassigned» і пули акаунтів.

3. В одного роздрібного партнера буде 3,6 мільйона робочих замовлень. Хтось пропонує акаунти Redrock 001, 002 і 003. Ваша думка?

Ні: це псує справжню бізнес-сутність. Шукайте поділ, який упізнає бізнес, як-от дочірній акаунт на кожен розподільчий центр, і архівуйте завершені доставки, щоб активних дочірніх записів було мало. Перечитайте Steve Trucking: де гарячі точки?.

4. Інтеграційний користувач володіє 2 мільйонами записів і сидить у регіональній ролі, яку от-от перемістять під час реорганізації. Який ризик і яке виправлення?

Переміщення змусить перерахувати доступ до 2 мільйонів записів. Не давайте власникам великих обсягів ролі або дайте окрему стабільну роль на вершині, тримайте їх поза групами правил спільного доступу і вирішіть, чи взагалі власність має керувати доступом до цих записів. Перечитайте Перекіс власності.

5. Реорганізація змінить сотні ролей, груп і правил спільного доступу за вихідні. Як ви це проведете?

Як операцію з даними: протестуйте на реальному обсязі у full copy sandbox, відкладіть обчислення спільного доступу, внесіть усі зміни, перерахуйте один раз в узгоджене вікно обслуговування, потім перевірте, маючи запасний план. Перечитайте Перерахунок спільного доступу — справжня робота.

6. Команда планує заархівувати 20 мільйонів записів одним завданням, яке копіює і видаляє. Що б ви змінили?

Три кроки: скопіювати й позначити як «очікує», перевірити архів (кількості, ідентифікатори, зв’язки, отримання), потім видалити й перемкнути, зі станами, щоб збій на 14-мільйонному записі можна було безпечно перезапустити. І резервна копія перед будь-яким видаленням. Перечитайте Архівування у три кроки.

7. Клієнт не хоче зберігати дані поза Salesforce, але мусить тримати роки історії записів на прийом. Де може жити архів?

На платформі: big objects або Archive від Salesforce. Із big objects спершу сплануйте шлях доступу: немає стандартного інтерфейсу чи звітів, запити — через індекс. І зробіть архів знаходжуваним, наприклад показуйте архівні записи на прийом під активними. Перечитайте Де має жити архів?.

Додаткові матеріали

Section titled “Додаткові матеріали ”