Khi khối lượng thay đổi mọi thứ

Cũng có bằng 19 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

A wheelbarrow buried under a teetering heap of bricks, its tire flattened, in front of a forklift holding a full pallet of the same bricks with ease. — Hình ảnh được tạo bằng AI

Mô-đun 1 trong 4 của chương Thiết kế cho quy mô lớn, chương 7 của khóa học Data Architect, và là phần mở đầu của Phần 2. Mỗi mô-đun có thể đọc độc lập. Tiếp theo: Điểm nóng: Lệch quyền sở hữu, lệch cha và lệch tra cứu

Câu hỏi mô-đun này trả lời: Cái gì hỏng khi dữ liệu tăng lên, và khi nào?

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. ⟲

Đây là chỗ chúng ta chuyển từ See sang Design. Ở Phần 1, chúng ta học cách nhìn nghiệp vụ, mô hình dữ liệu, bản đồ hệ thống doanh nghiệp, quản trị và thẩm quyền. Giờ chúng ta sẽ đặt sức nặng lên kiến trúc đó. Và câu hỏi đầu tiên tôi đặt ra là: nó sẽ lớn đến đâu?

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 (mở trong thẻ mới)). 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 (mở trong thẻ mới)). 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. ⟲

Cây thước khối lượng dữ liệu lớn của tôi

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 (mở trong thẻ mới)). 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. ⟲

Cây thước bắt đầu ở một triệu không phải là ngẫu nhiên. Chính phép tính truy vấn của nền tảng thay đổi ở “một triệu bản ghi đầu tiên”, như chương sau sẽ cho thấy. Tuy vậy, con số chính xác không phải là bài học. Bài học là: khối lượng thay đổi thiết kế.

Nhấp để phóng to

Every zero changes what you notice. A rule of thumb, not a limit. ⟲

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 (mở trong thẻ mới)). ⟲

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 (mở trong thẻ mới)). 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 (mở trong thẻ mới)). 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. ⟲

Đừng hỏi hôm nay nó lớn đến đâu

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. ⟲

Đó là lý do tôi dạy Số chữ số 0 của Steve. Đừng ám ảnh với độ chính xác giả tạo ngay từ đầu. Hãy nắm đúng bậc độ lớn. Mười nghìn, một trăm nghìn, một triệu, mười triệu, một trăm triệu? Kiến trúc có thể thay đổi mỗi lần chúng ta thêm một chữ số 0.

Giờ hãy nhân các bản ghi con

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. ⟲

Và dữ liệu chúng ta không đưa vào lõi

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. ⟲

Truy vấn không phải là thứ duy nhất chậm đi

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. ⟲

Mô hình gọn gàng có thể trở thành mô hình đắt đỏ

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. ⟲

Giả sử các báo cáo theo phạm vi đối tác trên mục dòng lệnh công việc liên tục cần Đối tác bán lẻ, mà trong mô hình gọn gàng nằm cách hai bước: mục dòng → lệnh công việc → đối tác. Ở quy mô đủ lớn, có thể có lý do để đặt một bản sao được quản trị của mã định danh đối tác ngay trên mục dòng. Giờ tôi đã tạo ra dữ liệu trùng lặp, và điều đó tạo ra trách nhiệm. Nó được điền thế nào? Nó có thể thay đổi không? Làm sao tôi giữ nó đúng? Bản sao nào có thẩm quyền? Đó là những chi phí thật, và đôi khi tôi chấp nhận trùng lặp có kiểm soát để đạt được hiệu năng mà doanh nghiệp cần. Thiết kế hướng đến chuẩn hóa, rồi lùi lại có chủ đích khi quy mô cho bạn lý do. Đừng phi chuẩn hóa vì nó dễ xây hơn; hãy phi chuẩn hóa vì bạn giải thích được lợi ích và cái giá bạn chấp nhận.

Đừng biến CRM lõi thành kho dữ liệu của bạn

Còn một sai lầm về quy mô nữa mà tôi thấy. Doanh nghiệp muốn báo cáo, nên chúng ta cứ thêm dữ liệu lịch sử vào CRM vận hành, rồi thêm nữa, cho đến khi lý do trở thành “chúng tôi cần nó để báo cáo”. Đó là lúc tôi hỏi liệu chúng ta đã biến hệ thống vận hành thành hệ thống phân tích chưa. Đó là những khối công việc khác nhau. Steve Trucking cần Salesforce để vận hành các chuyến giao hàng hôm nay: nhân viên hỗ trợ cần trạng thái hôm nay, điều phối viên cần tuyến hôm nay, đối tác cần tiến độ hôm nay. Một nhà phân tích so sánh năm năm hiệu suất giao hàng theo khu vực, đối tác, xe tải, thời tiết, tổ giao hàng và khung giờ giao, kết hợp với dữ liệu tài chính, là một khối công việc phân tích. Salesforce có thể báo cáo trên dữ liệu vận hành. Điều đó không có nghĩa là mọi câu hỏi phân tích về lịch sử đều thuộc về kho vận hành. Steve Trucking đã có Snowflake. Vậy hãy hỏi: hệ thống vận hành phải trả lời những câu hỏi nào, và những câu hỏi nào thuộc về nền tảng phân tích? Phần 3 bàn kỹ về kho dữ liệu.

Và ảnh chụp báo cáo (reporting snapshot) không phải là chiến lược kho dữ liệu. Các đối tượng báo cáo được làm phẳng, các bản ghi ảnh chụp, các bản sao giá trị giúp báo cáo dễ hơn: đôi khi hợp lý. Chúng cũng có thể là cách trì hoãn câu hỏi kiến trúc. Nếu tôi tạo thêm hàng triệu bản ghi để có thể báo cáo trên hàng triệu bản ghi tôi đã có, tôi muốn biết chuyện đó dừng ở đâu. Đừng tiếp tục sản xuất bản ghi vận hành chỉ vì không ai muốn bắt đầu cuộc trò chuyện về kho dữ liệu.

Khối lượng có hình dạng

Hai hệ thống có thể cùng có 20 triệu bản ghi mà hành xử rất khác nhau. Một hệ thống giữ 20 triệu bản ghi lịch sử, gần như không bao giờ được cập nhật, thường được lấy từng bản ghi một theo một mã định danh đã biết, với ít độ phức tạp về chia sẻ. Hệ thống kia giữ 20 triệu bản ghi đang hoạt động, liên tục được cập nhật, với quyền sở hữu phức tạp, báo cáo nặng, nhiều người dùng, những điểm tập trung cha-con lớn và tích hợp thường xuyên. Không phải cùng một bài toán. Vậy nên chỉ số lượng bản ghi thôi là chưa đủ. Nó tăng nhanh thế nào? Nó thay đổi thường xuyên đến đâu? Nó được truy vấn, chia sẻ và liên kết thế nào? Nó phải ở trạng thái hoạt động bao lâu? Bao nhiêu đến, hoặc thay đổi, cùng một lúc? Chuyện gì xảy ra khi chúng ta xóa nó? “Salesforce xử lý được 20 triệu bản ghi” không phải là câu trả lời. Câu hỏi thú vị là: hai mươi triệu bản ghi làm gì?

AI sẽ thêm nhiều chữ số 0 hơn

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. ⟲

Ngoài kỳ thi: AI thay đổi điều gì. AI có thể làm tăng mạnh tốc độ các hệ thống tạo và truy xuất dữ liệu. Hãy mô hình hóa rõ ràng khối lượng do tác tử tạo ra thay vì giả định rằng tốc độ giao dịch của con người trong quá khứ sẽ dự đoán được quy mô tương lai.

Steve Trucking: kiến trúc đã đang thay đổi

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. ⟲

Nhấp để phóng to

Follow the model, and the zeros multiply. ⟲

Kiến trúc sư quyết định gì ở đây

Số chữ số 0 trông thế nào hôm nay, với mức tăng trưởng dự kiến, và trong suốt thời gian lưu giữ, chứ không chỉ là khối lượng hôm nay có chạy được hay không.
Những cấu trúc gọn gàng nào giữ nguyên chuẩn hóa, và ở đâu phi chuẩn hóa có kiểm soát được biện minh bởi quy mô.
Dữ liệu nào ở lại trong lõi vận hành của Salesforce và dữ liệu nào thuộc về kho lưu trữ chuyên biệt, nền tảng phân tích hoặc hệ thống khác.
Một yêu cầu báo cáo có thực sự mang tính vận hành không, hay là dấu hiệu doanh nghiệp cần một kiến trúc phân tích.
Các nguồn tạo dữ liệu mới như tác tử thay đổi giả định về khối lượng thế nào trước khi bản ghi của chúng trở thành vấn đề của ngày mai.

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. ⟲

Tìm hiểu thêm

Salesforce Help, Data and File Storage Allocations (mở trong thẻ mới): 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 (mở trong thẻ mới) (release 264, archived copy (mở trong thẻ mới)), checked 2026-10-20. ⟲
Salesforce Developers, Best Practices for Deployments with Large Data Volumes (mở trong thẻ mới), Winter ‘27, checked 2026-11-01. ⟲
Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (mở trong thẻ mới), checked 2026-11-01. ⟲
Salesforce, Best Practices for Deployments with Large Data Volumes, Winter ‘16 edition (mở trong thẻ mới) (archived copy (mở trong thẻ mới)) (release 198), checked 2026-10-20. ⟲
Salesforce, Developer Limits and Allocations Quick Reference, Winter ‘16 edition (mở trong thẻ mới) (archived copy (mở trong thẻ mới)) and Winter ‘27 edition (mở trong thẻ mới) (archived copy (mở trong thẻ mới)), checked 2026-10-20. ⟲
Salesforce Developers, SOAP API End-of-Life Policy (mở trong thẻ mới), checked 2026-11-01. ⟲
Salesforce Developers, Execution Governors and Limits (mở trong thẻ mới), Apex Developer Guide, Winter ‘27, checked 2026-11-01. ⟲
Salesforce Developers, Working with Very Large SOQL Queries (mở trong thẻ mới), 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. ⟲
Bản mô tả Steve Trucking, mục 4 (khối lượng).