Skip to content
SteveTechArcSteveTechArc Courses

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)

Data Architect 第 7 章，也是第 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. ⟲

The LDV ruler The LDV ruler, four steps in records in a single object. One million: a little drag; dashboards and reports take a moment, depending on how you filter. Ten million: some effect, but still performing. Fifty million: the convertible; list views take two, three, four seconds, reports and dashboards take time, and past it your hair is blown back. One hundred million and up: should it be here? When will you archive, and is this operational data or an audit log? Underneath: records in a single object; a rule of thumb from the community, not a Salesforce limit. {"author": "Steve Simpson", "blueprint": "1.1.0", "builder": "standard 1.53.0", "built": "2026-10-29", "id": "DGM-DA-LDV-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} 1 million a little drag YOU NOTICE Dashboards and reports take a moment Depends on how you filter 10 million some effect YOU NOTICE Some effect Still performing 50 million the convertible YOU NOTICE List views take 2, 3, 4 seconds Reports and dashboards take time Past it, your hair is blown back 100 million + should it be here? YOU ASK When will you archive? Operational data, or an audit log? Records in a single object. A rule of thumb from the community, not a Salesforce limit. © 2026 Twinshark LLC · stevetecharc.com
点击放大

第 1 部分教会我们去看。第 2 部分给架构加上重量。这一章是第一次考验：骨架撑得住这些零吗？

A small four-seat propeller plane parked beside a wide-body passenger jet that towers over it: the same job, built for a hundred times the load.

Image generated with AI. ⟲

本章的思想

Section titled “本章的思想 ”
  • **用“零的个数”来规划，**包括增长和整个保留期，而不是今天的数据量。100 万个父记录、每个带 8 个子记录，不是一个 100 万条记录的问题。
  • 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. ⟲
  • **拥有大量记录的所有人要放在角色层级之外，**或者放在顶部一个稳定的独立角色里，并且不进入共享规则的组。
  • 机器创建的记录归谁所有，取决于所有权对共享是否重要。
  • **在大规模下，安全调整就是一次数据操作：**推迟共享计算，在完整沙盒里演练，只重新计算一次。并且永远不要因为私有更慢就把数据设为公开。
  • **如果你今天不归档，你还会归档吗？**从第一天就决定删除，删除之前先备份，并让归档可以被找到。
  • 归档数据是否仍然能被智能体访问，由业务决定。

Where volume causes problems

Section titled “Where volume causes problems”
什么在增长它拖慢什么在哪里讲
一个对象里的记录查询、列表视图、报表模块 1；第 8 章
一个父记录下的子记录、一个所有人名下的记录锁、共享重新计算模块 2
Children under one master-detail parentLocking, roll-ups, cascade delete, a hard-to-undo choiceModule 2
用户、角色、组和规则访问权限重新计算、调整模块 3
没人用的历史一切，外加存储和风险模块 4

本章的路线

Section titled “本章的路线 ”

四个模块，每个都可以单独阅读。

  1. 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. ⟲
  2. 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. ⟲
  3. **当数据量遇上共享模型。**所有权作为访问杠杆、稳定的层级、推迟的共享计算、细粒度锁定，以及大规模的合作伙伴隔离。
  4. **如果你今天不归档……。**从第一天开始的生命周期、删除前备份、归档放在哪里、三步归档，以及智能体与旧数据。

架构师在这里决定什么

Section titled “架构师在这里决定什么 ”
  • **每个对象会长到多大，**包括增长和整个保留期。
  • **记录在哪里扎堆，**以及哪些扎堆是危险的。
  • **所有权意味着什么，**对每一个大数据量对象，包括智能体创建的对象。
  • **访问模型如何扩展，**以及大型调整如何规划。
  • **数据如何离开：**归档、清除、备份，以及谁还能找到它。

**考试之外：**智能体会增加零。一个人创建一条记录的地方，它们可能创建十条，默认拥有所有这些记录，比任何人都更快地检索数据，并且能触及归档，除非有人决定它们不应该这样。每个模块的结尾都会讲 AI 对它那一部分问题带来了什么改变。

延伸探索

Section titled “延伸探索 ”

下一章：查询与检索架构

关注我

© 2023–2026 Twinshark LLC. All rights reserved. · 内容使用

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

法律声明以英文书写，以英文版本为准。