當資料量改變一切
另有 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)
第 1 個模組，共 4 個，屬於 Data Architect 課程第 7 章為規模而設計，也是第 2 部分的開始。每個模組都可以單獨閱讀。 下一篇：熱點：所有權、父記錄和查閱傾斜
**本模組回答的問題：**資料增長時，什麼會壞，什麼時候壞？
A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. That’s one of the things that makes data architecture difficult. The object is the same. The fields are the same. The relationships are the same. The business requirement may even be the same. But add a few zeros and the architecture changes. ⟲
這裡我們從看轉向設計。在第 1 部分，我們學會了看清業務、資料模型、企業全景、治理和權威。現在我們要給這個架構加上重量。我問的第一個問題是：它會長到多大？
Built for Transactions
Section titled “Built for Transactions”Salesforce runs some of the largest CRM implementations in the world, and its core database handles “upwards of 1.1 trillion transactions per month.” Salesforce’s own architects describe that database as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow （在新標籤頁中開啟）). It’s built for that: transactional work on structured data. And every record comes with a lot of built-in capabilities and functionality that are part of the core Salesforce platform: the object model, sharing and security, pages, reports, automation, search. All of it runs on a multitenant database, where Salesforce writes the SQL, not you. ⟲
I once taught this class at Dreamforce to a room with a lot of database administrators from Oracle and SQL Server, and of course they were asking, “Why doesn’t Salesforce act this way? Why doesn’t Salesforce do this?” By the end they were smiling, because they’d understood why. Chapter 3 described Salesforce as a multitenant, metadata-driven platform: the apartment building. We’re not tuning our own dedicated database. Salesforce’s storage, indexing, sharing, locking, query optimization and resource protections are designed for many tenants at once. That’s not bad; it’s why we get so much capability without running database infrastructure. But it means the architect needs to understand the platform’s shape. ⟲
Salesforce says it plainly in its own guide: as data sets get larger, “the time required for certain operations grows,” and the architect’s choices change that time “by several orders of magnitude” (Best Practices for Deployments with Large Data Volumes （在新標籤頁中開啟）). That’s not a weakness. It’s the design. At small volumes you can sometimes ignore the platform’s shape. At large volumes, it reminds you it’s there, and we’ll see that very clearly with selectivity and indexes in the next chapter. That’s why the architect has to know how big this gets. ⟲
The same guide ends with the other half of the story. Salesforce is “a robust environment in which native and custom applications can scale to large volumes of data very quickly while continuing to perform well,” and it names the two ways you get there: make queries selective, and reduce the amount of active data. Millions of records can perform well on Salesforce. They perform well because somebody designed for them. That’s what this part of the course is about. ⟲
我的大數據量刻度尺
Section titled “我的大數據量刻度尺 ”When I’m teaching large data volumes, I use a rough ruler. It’s not a Salesforce limit. The numbers are general figures discussed in the community, and Salesforce itself calls a large data volume “an imprecise, elastic term”: tens of thousands of users, tens of millions of records, or hundreds of gigabytes of storage (Best Practices for Deployments with Large Data Volumes （在新標籤頁中開啟）). And when I say records, I mean records in a single object, not across all your objects. ⟲
Like every number in this course, the ruler has a date on it. More on that in a moment. ⟲
At about 1 million records in an object, there’s just a little bit of drag as dashboards and reports show up. Not a lot, depending on how you filter. Around 10 million, there’s some effect, but it’s still performing. Heading toward 50 million, you start to notice it: list views taking two, three, four seconds, reports and dashboards taking time. Past 50 million, I like to say you’re driving a convertible with your head out the window, and your hair is blown back. Don’t stick your head out the window: past 50 million you’ve got to be streamlined, and you’ve got to know what you’re doing. And once we’re talking about 100 million records or more, I start asking a different question: should these records be here at all? I’ve heard of people running a hundred million or more in an object. But if you’re at 50 million today, you’re going to 100, 150, 200 million in the years ahead. If you’re not archiving today, when will you? If somebody tells me they have 150 million records in an object and almost nobody ever looks at the old ones, that’s not an operational object any more. That’s an audit log. ⟲
刻度尺從 100 萬開始並非偶然。正如下一章所示，平台自身的查詢計算在「前 100 萬條記錄」處也會變化。不過，具體數字不是重點。重點是：資料量會改變設計。
Every zero changes what you notice. A rule of thumb, not a limit. ⟲
The Platform Keeps Growing
Section titled “The Platform Keeps Growing”Salesforce ships three releases a year. Over time the platform grows, some limits are raised, and systems get faster. So I don’t want you to treat any number in this course as if it were permanent, including mine. Salesforce keeps every release’s edition of its guides online, which means we can do something useful: put ten years side by side. Here’s Winter ‘16, from late 2015, next to Winter ‘27, from 2026. ⟲
| Winter ‘16 (2015) | Winter ‘27 (2026) | |
|---|---|---|
| Big objects | Didn’t exist yet | “Consistent performance, whether you have 1 million records, 100 million, or even 1 billion” |
| Skinny table columns | 100 | 200 |
| Index selectivity thresholds | Capped at 1 million records (standard) and 333,333 (custom) | No published cap, and the optimizer can add an index on its own |
| Minimum data storage | 1 GB per org, or 20 MB per user | 10 GB per org, plus storage per user |
| Bulk API batches a day | 5,000 | 15,000 |
| Parent-to-child levels in one SOQL query | 1 | 5 |
| Apex heap per transaction | 6 MB (12 MB asynchronous) | 10 MB (25 MB asynchronous) |
That’s the upward direction: limits raised, caps removed, new kinds of storage, and an optimizer that now “recognizes that an index can improve performance for frequently run queries” and adds one (Working with Very Large SOQL Queries （在新標籤頁中開啟）). ⟲
Now look at what didn’t move in those ten years. The definition of a large data volume is word for word the same: “tens of thousands of users, tens of millions of records, or hundreds of gigabytes.” The advice to avoid having any user own more than 10,000 records is the same. And an Apex transaction still gets 100 SOQL queries, 50,000 records and 10 seconds of CPU (Execution Governors and Limits （在新標籤頁中開啟）). Those are the house rules of the apartment building, the guardrails that keep one tenant from hurting the others, and they’ve barely moved. ⟲
Salesforce is open about the pace, too. It ships three releases a year, each with a new API version, and it commits to “supporting each API version for a minimum of 3 years from the date of first release,” with at least a year’s notice before support for a version ends (SOAP API End-of-Life Policy （在新標籤頁中開啟）). In practice versions live much longer: as I write this, version 41.0, from Winter ‘18, is still supported. If you’re new, you don’t need the history. But it does change decisions. The org you inherit was designed under older limits, and some of its workarounds may not be needed any more. The integration you build today is pinned to an API version with a clock on it. And study material written a few releases ago may still teach yesterday’s numbers. ⟲
So when you read a number in this course, read the date next to it. The specific limits will keep changing, mostly upward, and Salesforce will keep pivoting. The thinking won’t: know your Number of Zeros, keep the active data small, make your queries selective, and check the current edition of the guide before you commit to a number. That’s why I teach the ruler as a ruler, not a law. For now, it’s a good place to start. ⟲
The sources, both editions: Best Practices for Deployments with Large Data Volumes, Winter ‘16 （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）) and Winter ‘27 （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）); Salesforce Limits Quick Reference Guide, Winter ‘16 （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）), and Salesforce Developer Limits and Allocations Quick Reference, Winter ‘27 （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）); Data and File Storage Allocations （在新標籤頁中開啟） (10 GB “starting in late March 2019”); Execution Governors and Limits （在新標籤頁中開啟）, Winter ‘27. ⟲
別問它今天有多大
Section titled “別問它今天有多大 ”One of the easiest mistakes is sizing an architecture from today’s data. Steve Trucking has about 1 million deliveries a year. If I only ask “can Salesforce handle one million deliveries?”, I’m asking the wrong question. Steve Trucking expects about 30% annual growth: 1.0 million in year one, 1.3 in year two, 1.69 in year three, about 2.2 in year four, about 2.86 in year five. That’s annual volume. If we keep all five years, we’re not designing for 2.86 million deliveries; we’re designing for roughly 9.04 million. And that’s before we ask how much history already exists. ⟲
所以我教 Steve 的「零的個數」（Steve’s Number of Zeros）。不要一開始就執著於虛假的精確。找到正確的數量級。一萬、十萬、一百萬、一千萬、一億？每多一個零，架構都可能改變。
現在把子記錄乘進去
Section titled “現在把子記錄乘進去 ”The delivery isn’t the only record. Steve Trucking averages about 1.6 line items a delivery, so over five years that’s about 14.5 million work order line items. And there are around eight status changes a delivery: about 72.3 million status events. The requirement sounded like “track deliveries.” The architecture has to deal with tens of millions of related records. One million parents with eight children each is not a one-million-record problem. You have to follow the model. ⟲
還有我們沒放進核心的資料
Section titled “還有我們沒放進核心的資料 ”Checkpoint 1 also gave us four to five million photos a year, and FleetLink produces about 200,000 GPS readings a day: roughly 73 million a year before growth. That’s why we decided not to put every GPS reading, every photo or every status change into the Salesforce operational model. We hadn’t even started this chapter, and the Number of Zeros was already telling us something. It’s like telling the doctor, “It hurts when I raise my arm,” and the doctor says, “Then don’t raise your arm.” Sometimes the best way to solve a large-data-volume problem is don’t create it in the first place. ⟲
變慢的不只是查詢
Section titled “變慢的不只是查詢 ”When people hear large data volumes, they think “queries get slow.” Yes, and the next chapter is all about query and retrieval. But it’s bigger than that. As volume grows, I care about sharing calculations, ownership, record locking, parent-child relationships, list views, related lists, reports, search results, batch processing, integrations, data loads, deletes, archiving, backups and recovery. Even a harmless-looking decision gets expensive when it’s repeated millions of times. ⟲
That’s the lesson: what works today may fail tomorrow. Maybe nobody notices at 50,000 records, or at 500,000. Then growth pushes the object through several million, and an old design assumption becomes the bottleneck. The system didn’t randomly go bad. The architecture crossed the scale where that decision mattered. ⟲
乾淨的模型可能變成昂貴的模型
Section titled “乾淨的模型可能變成昂貴的模型 ”My starting position is still: design clean first, then back off when necessary. Understand the entities and relationships; don’t duplicate data because it’s convenient. But normalization is a principle, not a rule. If a report or operational query constantly has to walk several relationships across tens of millions of records to get one value, at some scale I may copy that value closer to where it’s used. That’s denormalization. ⟲
假設按合作夥伴統計工作訂單明細項目的報表總是需要零售合作夥伴（Retail Partner），而在乾淨的模型裡它隔著兩跳：明細項目 → 工作訂單 → 合作夥伴。資料量夠大時，可能就有理由把合作夥伴識別符號的一個受管控副本直接放到明細項目上。這樣我就製造了重複資料，也隨之承擔了責任。它怎麼填充？會變嗎？怎麼保持準確？哪個副本是權威的？這些都是真實的成本，而為了獲得業務需要的效能，我有時會接受受控的重複。**朝著規範化去設計，然後在資料量給你理由時有意識地退一步。**不要因為更容易構建就反規範化；要因為你能說清楚收益和你接受的成本才反規範化。
不要把核心 CRM 變成你的資料倉儲
Section titled “不要把核心 CRM 變成你的資料倉儲 ”我還看到另一個資料量錯誤。業務想要報表，於是不斷往運營 CRM 里加歷史資料，加了又加，直到理由變成「報表要用」。這時我會問：我們是不是把運營系統變成了分析系統？這是兩種不同的工作負載。Steve Trucking 需要 Salesforce 來運轉今天的配送：客服需要今天的狀態，排程需要今天的路線，合作夥伴需要今天的進度。一位按地區、合作夥伴、卡車、天氣、配送小組和配送時段比較五年配送表現、並和財務資料交叉分析的分析師，承擔的是分析工作負載。Salesforce 可以對運營資料做報表。這不意味著每一個歷史分析問題都屬於運營儲存。Steve Trucking 已經有 Snowflake 了。所以要問：**哪些問題必須由運營系統回答，哪些屬於分析平台？**第 3 部分會深入講資料倉儲。
報表快照也不是資料倉儲策略。拍平的報表物件、快照記錄、為方便報表而複製的值：有時是正當的。它們也可能是推遲架構問題的一種方式。如果我為了能對已有的幾百萬條記錄做報表，又建立了幾百萬條記錄，我想知道這在哪裡結束。不要因為沒人願意談資料倉儲，就不斷製造運營記錄。
資料量是有形狀的
Section titled “資料量是有形狀的 ”兩個系統可能各有 2,000 萬條記錄，行為卻非常不同。一個是 2,000 萬條歷史記錄，幾乎從不更新，通常按已知 ID 逐條讀取，共用也不復雜。另一個是 2,000 萬條活動記錄，不斷更新，所有權複雜，報表多，使用者多，父子扎堆嚴重，整合頻繁。這不是同一個問題。所以只看記錄數不夠。它增長多快？多久變一次？怎麼被查詢、共用、關聯？要保持活動多久？一次會進來或變化多少？刪除時會發生什麼？「Salesforce 能處理 2,000 萬條記錄」不是答案。有意思的問題是：做什麼的 2,000 萬條記錄？
AI 會增加更多的零
Section titled “AI 會增加更多的零 ”Agents can create data very quickly: interactions, tasks, summaries, recommendations, logs, intermediate results, events, audit information. Maybe that’s useful. But AI doesn’t make storage free, or sharing calculations, or indexing, and it certainly doesn’t make useless history valuable. If an agent creates ten records where a human process used to create one, our volume assumptions may be wrong before the business itself grows. I’m not yet seeing agents generate more records in the orgs I work with, but it’s the natural progression of more and more data being tracked. ⟲
**考試之外：AI 改變了什麼。**AI 可以大幅提高系統建立和檢索資料的速度。要明確地對代理程式產生的資料量建模，而不是假設人工交易的歷史速度能預測未來的資料量。
Steve Trucking：架構已經在變了
Section titled “Steve Trucking：架構已經在變了 ”At the end of Part 1 we made several decisions that are now reinforcing each other. The work order is central. The current status lives in the org, and the history of every status change is published to the warehouse, Snowflake. Photos live outside the core. Raw GPS stays with FleetLink. At five years of 30% growth, we’re approaching 9 million work orders, 14.5 million line items and 72.3 million status events, and hundreds of millions of GPS readings if we’d copied them all. ⟲
Was keeping raw GPS out of the operational model just an integration decision? No; it was a scale decision too. Was putting photos off-core just a storage decision? No; scale again. And the status history? It has real business value, so we keep it. But at 72.3 million events, keeping it outside the operational database is the difference between an org that carries its history and an org that’s buried by it. The question that remains for what we do keep in core: how long should those records stay active? That’s module 4. ⟲
Follow the model, and the zeros multiply. ⟲
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 今天的「零的個數」是什麼樣，包括預期增長和整個保留期，而不只是今天的資料量行不行。
- 哪些乾淨的結構保持規範化，哪些地方資料量足以支援受控的反規範化。
- 哪些資料留在 Salesforce 的運營核心，哪些屬於專門的儲存、分析平台或其他系統。
- 一個報表需求是真正的運營需求，還是業務需要分析架構的訊號。
- 像代理程式這樣的新生產者，如何在它們的記錄變成明天的問題之前改變資料量假設。
Large data volume architecture isn’t about being afraid of big numbers. Salesforce runs very large implementations. One million records isn’t automatically a problem; neither is ten million or a hundred million. But every zero should make me ask another question: how will we find them, who owns them, how are they shared, what are they related to, how often do they change, how long do we need them, and where should they live? In Part 1 we learned to recognize the right entities and relationships. Now we make sure those bones can carry the weight, because what works today may fail tomorrow. ⟲
- Salesforce Help, Data and File Storage Allocations （在新標籤頁中開啟）: 10 GB of data storage since late March 2019, checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘27 edition （在新標籤頁中開啟） (release 264, archived copy （在新標籤頁中開啟）), checked 2026-10-20. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes （在新標籤頁中開啟）, Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘16 edition （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）) (release 198), checked 2026-10-20. ⟲
- Salesforce, Developer Limits and Allocations Quick Reference, Winter ‘16 edition （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）) and Winter ‘27 edition （在新標籤頁中開啟） (archived copy （在新標籤頁中開啟）), checked 2026-10-20. ⟲
- Salesforce Developers, SOAP API End-of-Life Policy （在新標籤頁中開啟）, checked 2026-11-01. ⟲
- Salesforce Developers, Execution Governors and Limits （在新標籤頁中開啟）, Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Developers, Working with Very Large SOQL Queries （在新標籤頁中開啟）, Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
- SteveTechArc, Salesforce Documents by Release: the guides cited here, once a year from Winter ‘16 to today, each with an archived copy. ⟲
- Steve Trucking 的簡介，第 4 節（資料量）。