Bỏ qua để đến nội dung
SteveTechArcSteveTechArc Courses

What Works Today May Fail Tomorrow

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)

Chương 7 của Data Architect, và là phần mở đầu của Phần 2: Kiến trúc ở quy mô lớn. Trước: Dữ liệu chủ và danh tính.

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 (mở trong thẻ mới)). 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
Nhấp để phóng to

Phần 1 dạy chúng ta nhìn. Phần 2 đặt sức nặng lên kiến trúc. Chương này là phép thử đầu tiên: bộ xương có gánh nổi các chữ số 0 không?

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

Các ý tưởng trong chương này

Phần tiêu đề “Các ý tưởng trong chương này ”
  • Lên kế hoạch theo Số chữ số 0, tính cả tăng trưởng và suốt thời gian lưu giữ, không phải con số hôm nay. Một triệu bản ghi cha, mỗi bản ghi có tám bản ghi con, không phải là bài toán một triệu bản ghi.
  • What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
  • Thiết kế gọn gàng, rồi lùi lại có chủ đích khi quy mô cho bạn lý do, và đừng biến CRM lõi thành kho dữ liệu của bạn.
  • 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. ⟲
  • Chủ sở hữu khối lượng lớn đứng ngoài phân cấp vai trò, hoặc ở một vai trò riêng, ổn định, trên cùng, và ngoài các nhóm của quy tắc chia sẻ.
  • Ai sở hữu các bản ghi do máy tạo ra tùy thuộc vào việc quyền sở hữu có quan trọng đối với chia sẻ hay không.
  • Ở quy mô lớn, việc sắp xếp lại bảo mật là một thao tác dữ liệu: hoãn các phép tính chia sẻ, diễn tập trong một sandbox Full, tính lại một lần. Và đừng bao giờ công khai dữ liệu vì chế độ riêng tư chậm hơn.
  • Nếu hôm nay bạn không lưu trữ, liệu bạn có bao giờ lưu trữ không? Quyết định việc xóa ngay từ ngày đầu, sao lưu trước khi xóa, và giữ cho kho lưu trữ tìm được.
  • Dữ liệu đã lưu trữ có còn trong tầm với của tác tử hay không là quyết định của doanh nghiệp.

Where volume causes problems

Phần tiêu đề “Where volume causes problems”
Cái gì tăngNó làm chậm cái gìĐược bàn ở đâu
Số bản ghi trong một đối tượngTruy vấn, chế độ xem danh sách, báo cáoMô-đun 1; chương 8
Bản ghi con dưới một bản ghi cha, bản ghi dưới một chủ sở hữuKhóa, tính lại chia sẻMô-đun 2
Children under one master-detail parentLocking, roll-ups, cascade delete, a hard-to-undo choiceModule 2
Người dùng, vai trò, nhóm và quy tắcTính lại quyền truy cập, sắp xếp lạiMô-đun 3
Lịch sử không ai dùngMọi thứ, cộng với dung lượng lưu trữ và rủi roMô-đun 4

Lộ trình qua chương này

Phần tiêu đề “Lộ trình qua chương này ”

Bốn mô-đun, mỗi mô-đun có thể đọc độc lập.

  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. Khối lượng gặp mô hình chia sẻ. Quyền sở hữu như một đòn bẩy truy cập, phân cấp ổn định, hoãn phép tính chia sẻ, khóa chi tiết (granular locking), và cách ly đối tác ở quy mô lớn.
  4. Nếu hôm nay bạn không lưu trữ…. Vòng đời từ ngày đầu, sao lưu trước khi xóa, kho lưu trữ nằm ở đâu, lưu trữ ba bước, và tác tử với dữ liệu cũ.

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

Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”
  • Mỗi đối tượng lớn đến đâu, khi tăng trưởng và trong suốt thời gian lưu giữ.
  • Bản ghi tập trung ở đâu, và những điểm tập trung nào là nguy hiểm.
  • Quyền sở hữu có nghĩa là gì đối với từng đối tượng khối lượng lớn, kể cả những đối tượng do tác tử tạo.
  • Mô hình truy cập mở rộng thế nào, và các đợt sắp xếp lại lớn được lên kế hoạch ra sao.
  • Dữ liệu rời đi thế nào: lưu trữ, xóa bỏ, sao lưu, và ai vẫn còn tìm được nó.

Ngoài kỳ thi: tác tử thêm chữ số 0. Chúng có thể tạo mười bản ghi ở chỗ một người tạo một, mặc định sở hữu tất cả, truy xuất nhanh hơn bất kỳ ai, và với tới cả kho lưu trữ, trừ khi có người quyết định là không được. Mỗi mô-đun kết thúc bằng điều AI thay đổi cho phần việc của nó.

Tìm hiểu thêm

Phần tiêu đề “Tìm hiểu thêm ”

Tiếp theo: Kiến trúc truy vấn và truy xuất