为规模而设计
另有 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)
Data Architect 课程第 7 章的学习指南。请先阅读四个模块；这一页帮你检查自己记住了什么。
**关于本学习指南。**它只依据本课程自己的内容，以及 Salesforce 公开发布的考试指南中的目标清单编写。它从不基于真实的考试题目，也不声称知道考试会考什么。如果你参加过考试，请不要把考题发给我：认证协议禁止分享考题，而且死记答案本来就不是成为架构师的正确方式。
这一章开启第 2 部分，以及考试的“大数据量”部分（20%），外加“数据建模”部分的数据倾斜。查询设计在下一章；这一章讲的是数据量、热点、大规模共享和生命周期。平台的数字会变，依赖它们之前请先查看当前的数字。
边学边打勾。每一条都链接到讲授它的地方。
LDV-1：一个能扩展的模型
- 我知道要按整个保留期内的增长来给设计定规模，而不是按今天的数据量，并且会把子记录乘进去。（别问它今天有多大、现在把子记录乘进去）
- 我知道数据量影响的不只是查询：还有共享、所有权、锁定、列表视图、报表、批处理、加载、删除和恢复。（变慢的不只是查询）
- 我知道什么时候规模足以支持受控的反规范化，以及它的代价。（干净的模型可能变成昂贵的模型）
- 我知道不要把运营 CRM 变成数据仓库，也知道报表快照不是数据仓库策略。（不要把核心 CRM 变成你的数据仓库）
- 我知道数据量是有形状的：做什么的两千万条记录？（数据量是有形状的）
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) ⟲
- 我知道用客户池修复人为的父记录，并把占位父记录对用户藏起来。（“未分配”客户与客户池）
- 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) ⟲
- 我知道查找倾斜：很多活动记录指向同一条记录，以及它可能引起的记录锁定。（查找倾斜）
- 我能根据活动，而不只是数量，区分危险的倾斜和无害的倾斜。（并非每种倾斜都同样危险）
- 对一个真实业务实体上的倾斜，我用有含义的拆分来修复（每个配送中心一个子客户），绝不制造它的假副本。（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：归档与清除
- 我能把保留、归档和清除分开，并在项目开始时就定下来。（删除不可避免）
- 我知道在删除任何东西之前先把备份做好，也知道备份和归档是不同的能力（Salesforce Backup & Recover、Archive）。（删除之前先备份）
- 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) ⟲
- 我知道三步归档（复制并标记、验证、删除并切换），也知道它必须可以重启。（三步归档）
- 我知道归档数据必须保持可查找，并保留它的安全性。（没人找得到的归档，几乎就是删除、归档仍然必须安全）
考试是底线，不是天花板。下面这些是本章中架构师需要的习惯，不管有没有考题问到它们。
- 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、照片和状态历史放在核心之外。
- 数字告诉我该看哪里；行为告诉我该有多担心。
- 在这个规模下，组织变化就成了数据操作。
- 规模上的修复仍然必须保留含义。
- **在图上找出热点：**看箭头，问每一侧会堆积多少条记录。
- 测试你真正要设计的“零的个数”。
- **AI 会增加更多的零。**要明确地对智能体产生的数据量建模。
- 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?) ⟲
- 如果你今天不归档，你还会有归档的那一天吗？
- **设计入口的时候，就设计出口。**每个对象五个答案：它什么时候不再活动，去哪里，我们如何证明，别人怎么找到它，什么时候删除。
- 智能体能否触及归档数据，由业务决定。
| 术语 | 一句话解释 |
|---|---|
| 大数据量（LDV） | 记录多到平台的行为（而不只是数量）开始影响设计 |
| 数据倾斜 | 太多记录集中在一个父记录、所有人或查找值上 |
| 父子倾斜 | 一个父记录下的子记录太多 |
| 所有权倾斜 | 一个用户拥有某个对象超过大约 10,000 条记录 |
| 查找倾斜 | 很多活动记录引用同一条记录，导致锁争用 |
| 客户池 | 几个占位父记录分担一个人为父记录的子记录 |
| 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 |
| 共享重新计算 | 所有人、角色、组或规则变化后，平台重新计算访问权限 |
| 推迟共享计算 | 等一批变化做完之后，再把重新计算只运行一次 |
| 细粒度锁定 | 只锁住操作所需的那部分组成员关系表 |
| 保留 | 数据保存多久，以及为什么 |
| 归档 | 把数据移出活动工作负载，同时保留业务需要的访问 |
| 清除 | 在保留期结束时永久删除数据 |
| 三步归档 | 复制并标记，验证，然后删除并切换 |
按课程风格编写的简短情景题。打开答案之前，先想好你的答案。
1. 一家公司每年配送 100 万次，每年增长 30%，保留五年。你按多大的数据量来设计？
大约 900 万次配送，保留五年，而不是 100 万次，然后还有它们的子记录：按每次配送 1.6 个计算，大约 1,450 万个行项目；按每次配送 8 个计算，7,200 万个状态事件。重读别问它今天有多大。
2. 300,000 个联系人挂在一个叫“Unassigned Contacts”的客户下。你怎么做？
这是人为的父子倾斜。把联系人分散到一个由占位父记录组成的客户池里，每个都低于阈值，并把这些占位记录从正常的业务视图里藏起来。或者问问这些联系人到底需不需要客户。重读“未分配”客户与客户池。
3. 一个零售合作伙伴将会有 360 万个工作订单。有人提议建 Redrock 001、002 和 003 客户。你怎么看？
不行：这会破坏一个真实的业务实体。找一个业务认得出的拆分方式，比如每个配送中心一个子客户，并归档已完成的配送，让活动子记录保持在低位。重读Steve Trucking：热点在哪里？。
4. 一个集成用户拥有 200 万条记录，所在的区域角色即将在重组中被移动。风险是什么，怎么修复？
移动它会迫使对 200 万条记录重新计算访问权限。不给拥有大量记录的所有人角色，或在顶部给一个独立、稳定的角色，让他们不进入共享规则组，并决定对这些记录而言所有权到底是否应该驱动访问。重读所有权倾斜。
5. 一次重组将在一个周末里改动几百个角色、组和共享规则。你怎么执行？
把它当作一次数据操作：在完整副本沙盒里按真实数据量测试，推迟共享计算，做完所有变化，在商定的维护窗口里只重新计算一次，然后验证，并准备后备方案。重读共享重新计算是真实的工作。
6. 团队计划用一个既复制又删除的作业归档 2,000 万条记录。你会改什么？
分三步：复制并标记为待处理，验证归档（数量、标识符、关系、检索），然后删除并切换，并设置状态，让在第 1,400 万条记录处的失败可以安全重启。而且在删除任何东西之前先备份。重读三步归档。
7. 客户不希望数据存放在 Salesforce 之外，但需要保留多年的预约历史。归档可以放在哪里？
放在平台上：big object，或 Salesforce 的 Archive。用 big object 的话，先规划好访问路径：没有标准界面或报表，通过索引查询。还要让它保持可查找，比如在活动预约下方显示已归档的预约。重读归档应该放在哪里？。
- Salesforce Certified Platform Data Architect Exam Guide （在新标签页中打开）, Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- 每个模块自己的“延伸探索”部分都列出了其中事实所依据的 Salesforce 文档。