What Works Today May Fail Tomorrow
Також доступно 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)
Розділ 7 курсу Data Architect, початок Частини 2: Архітектура в масштабі. Попередній: Основні дані та ідентичність.
A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. The object is the same, the fields are the same, the relationships are the same. Add a few zeros, and the architecture changes. ⟲
Start with what the platform is built for. Salesforce’s core database handles “upwards of 1.1 trillion transactions per month,” and Salesforce’s own architects describe it as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (відкривається в новій вкладці)). It’s built for transactions, on a multitenant database where Salesforce writes the SQL, not you. At small volumes you can ignore the platform’s shape. At large volumes, it reminds you it’s there. ⟲
So I teach large data volumes with a rough ruler, for records in a single object. At about 1 million, there’s a little drag as dashboards and reports show up. Around 10 million, some effect, but still performing. Heading toward 50 million, you notice it: list views take two, three, four seconds. Past 50 million, you’re driving a convertible with your head out the window, and your hair is blown back: you’ve got to be streamlined, and you’ve got to know what you’re doing. At 100 million or more, I start asking a different question: should these records be here at all? That’s a rule of thumb from the community, not a Salesforce limit. The lesson is that volume changes the design, and most large-data-volume problems are design problems: cheap to prevent, expensive to fix. ⟲
Частина 1 навчила нас бачити. Частина 2 кладе на архітектуру вагу. Цей розділ — перше випробування: чи витримає скелет нулі?
Image generated with AI. ⟲
Ідеї цього розділу
Section titled “Ідеї цього розділу ”- Плануйте за «кількістю нулів» — з урахуванням зростання і всього періоду зберігання, а не сьогоднішньої кількості. Мільйон батьківських записів, у кожного з яких вісім дочірніх, — це не задача на мільйон записів.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Проєктуйте чисто, а потім свідомо відступайте, коли масштаб дає вам на це причину, і не перетворюйте основну CRM на сховище даних.
- 10,000 children per parent is a design threshold, not a limit: Salesforce draws the same line, and past about 20,000 I’ve seen visible lag. Account pools work, but hide the placeholder parents. ⟲
- Власники великих обсягів записів залишаються поза ієрархією ролей або у власній стабільній ролі на самій вершині, і поза групами правил спільного доступу.
- Хто володіє записами, створеними машиною, залежить від того, чи важить власність для спільного доступу.
- У масштабі перебудова безпеки — це операція з даними: відкладіть обчислення спільного доступу, відрепетируйте у Full sandbox, перерахуйте один раз. І ніколи не робіть дані публічними лише тому, що приватний режим повільніший.
- Якщо ви не архівуєте сьогодні, чи будете ви колись архівувати? Вирішіть питання видалення з першого дня, робіть резервну копію перед видаленням і подбайте, щоб архіви можна було знайти.
- Чи залишаються архівні дані досяжними для агентів — вирішує бізнес.
Where volume causes problems
Section titled “Where volume causes problems”| Що зростає | Що це уповільнює | Де про це йдеться |
|---|---|---|
| Записи в одному об’єкті | Запити, представлення списків, звіти | Модуль 1; розділ 8 |
| Дочірні записи під одним батьківським, записи одного власника | Блокування, перерахунок спільного доступу | Модуль 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Користувачі, ролі, групи й правила | Перерахунок доступу, перебудови | Модуль 3 |
| Історія, якою ніхто не користується | Усе, а також сховище і ризик | Модуль 4 |
Шлях через цей розділ
Section titled “Шлях через цей розділ ”Чотири модулі, кожен самостійний.
- When Volume Changes Everything. Built for transactions, the ruler, the Number of Zeros at 30% growth, denormalizing for scale, and keeping analytics out of core. ⟲
- Hot Spots: Ownership, Parent and Lookup Skew. Too many records pointing at one thing, account pools, master-detail at volume (count the children before you choose the relationship), high-volume owners, and who owns agent-created records. ⟲
- Обсяг зустрічає модель спільного доступу. Власність як важіль доступу, стабільні ієрархії, відкладені обчислення спільного доступу, гранулярне блокування та ізоляція партнерів у масштабі.
- Якщо ви не архівуєте сьогодні…. Життєвий цикл із першого дня, резервна копія перед видаленням, де живе архів, архівування у три кроки, а також агенти й старі дані.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Наскільки великим стане кожен об’єкт з урахуванням зростання і періоду зберігання.
- Де концентруються записи і які концентрації небезпечні.
- Що означає власність для кожного об’єкта з великим обсягом, зокрема для тих, які створюють агенти.
- Як масштабується модель доступу і як плануються великі перебудови.
- Як дані залишають систему: архівування, остаточне видалення, резервне копіювання і хто ще може їх знайти.
За межами іспиту: агенти додають нулі. Вони можуть створити десять записів там, де людина створила один, за замовчуванням володіти ними всіма, отримувати дані швидше за будь-кого й діставатися до архівів, якщо ніхто не вирішить, що не слід. Кожен модуль закінчується тим, що ШІ змінює у своїй частині задачі.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (відкривається в новій вкладці), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (відкривається в новій вкладці) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (відкривається в новій вкладці) (Winter ‘27), checked 2026-11-01. ⟲