Lệch quyền sở hữu, lệch cha và lệch tra cứu

🌐 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)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh Phần này đã thay đổi trong bản tiếng Anh và chưa được dịch lại. (35)

Mô-đun 2 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. Mỗi mô-đun có thể đọc độc lập. Trước: Khi khối lượng thay đổi mọi thứ · Tiếp theo: Khối lượng gặp mô hình chia sẻ

Câu hỏi mô-đun này trả lời: Chuyện gì xảy ra khi quá nhiều bản ghi trỏ vào một thứ?

Vấn đề khối lượng dữ liệu lớn không phải lúc nào cũng là có quá nhiều bản ghi. Đôi khi đó là quá nhiều bản ghi nối với cùng một thứ: một chủ sở hữu, một tài khoản, một bản ghi cha, một giá trị tra cứu. Hãy nghĩ về giao thông. Một thành phố có thể có hàng triệu chiếc xe mà vẫn chạy ổn. Rắc rối bắt đầu khi mọi người cùng rẽ vào một lối ra cao tốc lúc 5 giờ chiều. Tổng số quan trọng, và mức độ tập trung cũng vậy. Tôi gọi những điểm tập trung này là điểm nóng; Salesforce gọi chúng là lệch dữ liệu (data skew). Có vài loại, và một ý tưởng nằm bên dưới tất cả: quá nhiều hoạt động hội tụ về một điểm trong mô hình.

Lệch cha-con

The easiest to picture. One account with 100 contacts: nothing unusual. A thousand: probably fine. Ten thousand: now I’m paying attention. My design rule is no more than about 10,000 children under one parent, and Salesforce’s guidance draws the same line: “a large number of child records (10,000 or more) with a single parent account” is a common cause of poor performance (Parent-Child Data Skew (mở trong thẻ mới)). Salesforce’s own example shows why. Put 300,000 contacts under one account. A user who can see one of those contacts gets implicit access to the account. When that user loses access to the contact, Salesforce has to check the other 299,999 contacts before it can decide whether to remove the user’s access to the account. Do that for many users at once, and it gets expensive. Salesforce also names one way to take part of that cost away: where your security requirements allow, set the child object to Controlled by Parent, so there are no parent implicit shares to maintain (same source). In practice, it’s the most common skew I see, and I’ve seen users notice visible lag at around 20,000 children under one parent. Where somebody feels it depends on what the system is doing. That’s why 10,000 is a design threshold, not a promise that record 10,001 breaks anything. The real question is: why are all these records pointing at the same parent? ⟲

Nhấp để phóng to

Step 1 of 2: every line points at one account. That’s the hot spot. ⟲

Tài khoản “Chưa gán”, và nhóm tài khoản

The classic case is contacts with no real account. Somebody decides every contact needs an account, so they create Unassigned Contacts and put every contact without an account there. Problem solved, until there are 300,000 contacts under it. We created an artificial hot spot because the model required us to put everything somewhere, and the relationship doesn’t even carry business meaning. It worked beautifully at 500 records. Then the Number of Zeros caught up with it. ⟲

What do you do when you’ve got a million contacts under it? I’ve seen child accounts by state, one unhandled-contacts account per state. I’ve seen an automatic version: whenever an account reaches 10,000, create another one. It can be a little awkward, but it spreads the load. ⟲

One answer is an account pool: Unassigned Contacts 001, 002, 003 and so on, with the children spread across them, each kept under the threshold. It works, and it’s Salesforce’s own advice: “Distribute child records so that no parent has more than 10,000 child records,” and for contacts without real accounts, “set up several dummy accounts and distribute the contacts among them” (Best Practices for Deployments with Large Data Volumes: General (mở trong thẻ mới), Winter ‘27). But those aren’t real accounts; they’re architecture artifacts. Users will ask who “Unassigned Contacts 017” is and why it’s in their search results. So when I use a pool, I hide the placeholder parents from normal business experiences as much as I can. It’s a recurring trade-off: sometimes scale forces a structure that exists for the platform, not the business. When it does, don’t pretend it’s business data. Name it, document it, hide it where appropriate. ⟲

Nhấp để phóng to

Step 2 of 2: the same contacts, spread across a pool. Nothing moved but where they point. ⟲

Master-Detail at Volume

Contacts under an account are a lookup. Master-detail is a different decision, and it’s one you make in the data model, long before the records arrive. Here’s the question I ask in class: would an invoice ever have more than 10,000 line items? No, it never would. So an invoice and its lines can be master-detail all day long. Now ask the same question of every master-detail relationship you’re about to build: at the volume we expect, will one parent ever pass 10,000 children? ⟲

Salesforce draws the same line: “As a best practice, don’t exceed 10,000 child records for a master-detail relationship” (Considerations for Object Relationships (mở trong thẻ mới)). Master-detail is the strongest relationship Salesforce gives you, and that’s exactly why the number matters. The detail record has no owner of its own; its access is controlled by the parent. Delete the parent, and every child goes with it. A child can’t move to another parent unless you allowed reparenting. Roll-up summaries on the parent have to keep up as the children change. And saving a child can lock the parent, which is why Salesforce’s loading advice is to group child records by their parent “to minimize locking conflicts” (Loading Data from the API (mở trong thẻ mới)). With ten children, none of that is noticeable. With a hundred thousand, every one of them is. ⟲

It’s also hard to undo. A master-detail relationship can only be converted to a lookup when the parent has no roll-up summary fields, and converting it changes the child’s sharing to Public Read/Write (same source). By the time volume tells you it was the wrong choice, the relationship may be holding up reports, sharing and automation. Count the children before you choose the relationship. ⟲

Steve Trucking has one of these decisions in its model. Each Retail Partner sends a Manifest (Manifest__c, a custom object) for each distribution center, for each working day. Manifest is custom, so master-detail to the partner’s account is allowed, and it’s tempting: the manifest would inherit the partner’s sharing, which is exactly the isolation we want. Now count. Our largest partner has nine or more DCs: nine manifests a working day, about 2,700 a year. Past 10,000 in under four years, under one parent, and every manifest revised on the day, so every revision would touch the partner’s account. That’s why the model makes Manifest a lookup and handles partner access through sharing. The invoice stays small; the manifests keep coming. ⟲

Nhấp để phóng to

Step 1 of 2: master-detail, where the parent stays small. ⟲

Nhấp để phóng to

Step 2 of 2: a lookup, where the children keep coming. ⟲

Watch Account with its contacts and opportunities too. It isn’t master-detail, but it behaves like a pseudo master-detail, with implicit sharing to the parent, which is why the 10,000 guidance shows up there as well. None of this means never use master-detail at scale. It means don’t choose a strongly coupled relationship and then act surprised that the records are strongly coupled. ⟲

Test knowledge. Know the 10,000-children guidance for master-detail, and what master-detail brings with it at volume: no owner on the detail (access controlled by the parent), cascade delete, no reparenting unless allowed, roll-up summaries, and parent locking when children are saved. Converting to a lookup needs no roll-up summaries on the master. ⟲

Lệch quyền sở hữu

Now the owner. I ask the room: who owns a million records? The admin? Is the admin sitting there creating a million records? Usually it’s the integration user or the data load user. The records come in, and nobody knows who to give them to. We create an integration user, it creates records, nobody thinks about ownership (“it’s just the integration user”), and a year later that user owns 2 million records. Salesforce calls it ownership data skew when one user owns more than 10,000 records of an object, and the classic example is all the unassigned leads parked on a dummy user (Ownership Data Skew (mở trong thẻ mới)). That doesn’t mean a user can never own more. It means understanding the consequences: ownership isn’t a Created By stamp. It drives the role hierarchy, sharing rules and recalculation: behind the scenes, Salesforce keeps share records for the owner’s records above them in the role hierarchy. Attach millions of records to one owner who sits deep in the sharing model, and changing anything about that owner gets expensive. ⟲

The guidance matches what I teach in class. If a few users must own a very large number of records, give them no role; if they need one, put them in a separate role at the top of the hierarchy and don’t move them, and keep them out of public groups used as sources for sharing rules (same source). One catch with the top role: that user inherits access to all the data owned by or shared with the users below them. You could spread the records across a bunch of users instead, but for an integration user or a data load user, that typically isn’t worth the trouble. ⟲

We’re isolating the hot spot from the structures that trigger recalculation. Imagine a user who owns 5 million records being moved in a reorganization. That isn’t moving a box on the org chart; Salesforce may have to re-evaluate access across 5 million records. At this scale, organizational changes become data operations. ⟲

Test knowledge. Know the skew thresholds and the fixes: ownership skew when one user owns more than 10,000 records of an object (no role, or a separate role at the top that doesn’t move, and out of public groups used by sharing rules); parent-child skew at about 10,000 children under one parent. ⟲

Ai nên sở hữu bản ghi do máy tạo ra?

Ai tạo một bản ghi và ai sở hữu nó không phải là cùng một câu hỏi. Redrock gửi 500.000 chuyến giao hàng qua API, và người dùng tích hợp tạo ra chúng. Nó có nên sở hữu chúng mãi mãi không? Có thể, nhưng không chỉ vì nó đã tạo ra chúng. Và giờ tác tử cũng tạo bản ghi.

Lập trường của tôi: điều đó 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. Người dùng tích hợp hay người dùng tác tử là người dùng hợp lệ và có thể sở hữu bản ghi. Nếu quyền sở hữu điều khiển quyền truy cập trong đối tượng đó (qua phân cấp vai trò hoặc quy tắc chia sẻ), hãy gán bản ghi cho chủ sở hữu mà doanh nghiệp yêu cầu: một người dùng thật, một hàng đợi ở nơi đối tượng hỗ trợ, hoặc một người dùng chủ sở hữu chuyên dụng. Nếu quyền sở hữu không điều khiển quyền truy cập, giữ người dùng tác tử hay tích hợp làm chủ sở hữu có thể là lựa chọn tốt hơn, vì dấu vết kiểm toán dẫn thẳng về thứ đã tạo ra bản ghi. Dù thế nào, hãy quyết định Owner nghĩa là gì cho đối tượng này, thay vì máy móc gán lại mọi bản ghi do máy tạo chỉ vì con người thường sở hữu bản ghi. Và hãy nhớ rằng Created By vẫn còn đó: gán lại quyền sở hữu không làm mất thông tin rằng tích hợp đã tạo ra nó. Created By và Owner trả lời những câu hỏi khác nhau. Bắt một trường trả lời cả hai là cách bạn có một mô hình tồi.

Lệch tra cứu

A lookup can be a hot spot too: millions of records pointing at the same location, category, reference record or configuration record. Salesforce’s own training defines it: “Lookup skew happens when a very large number of records are associated with a single record in the lookup object” (Large Data Volumes: Design Your Data Model (mở trong thẻ mới)). The danger isn’t “lots of lookups.” It’s concentration combined with activity: if millions of active records reference one record, and transactions keep touching that relationship, operations start colliding over it. That’s record locking, which chapter 11 covers. For now, recognize the shape: many active records, one heavily referenced record, worth inspecting. ⟲

Không phải loại lệch nào cũng nguy hiểm như nhau

Đừng học thuộc “10.000 = xấu”. Năm mươi nghìn bản ghi lịch sử trỏ vào một giá trị tham chiếu không bao giờ thay đổi, không có vai trò gì trong chia sẻ và gần như không có hoạt động đồng thời, có thể vẫn ổn. Hai mươi nghìn bản ghi đang hoạt động dưới một bản ghi cha thay đổi thường xuyên, điều khiển chia sẻ, cấp dữ liệu cho trường tổng hợp và bị nhiều tích hợp chạm vào cùng lúc là một câu chuyện rất khác. Khối lượng có hình dạng, và lệch dữ liệu cũng vậy. Bao nhiêu bản ghi hội tụ ở đó? Chúng thay đổi thường xuyên đến đâu? Bản ghi cha có thay đổi không? Mối quan hệ có điều khiển chia sẻ hay khóa không? Các tích hợp có cập nhật bản ghi con đồng thời không? Việc di chuyển chủ sở hữu hay bản ghi cha có kích hoạt tính lại không? Con số cho tôi biết nhìn vào đâu; hành vi cho tôi biết nên lo đến mức nào.

Steve Trucking: Điểm nóng nằm ở đâu?

Sau năm năm, chúng ta dự kiến khoảng 9 triệu lệnh công việc. Giả sử ai đó nói: “Hãy để người dùng tích hợp sở hữu mọi chuyến giao hàng.” Chín triệu bản ghi, một chủ sở hữu. Quyền sở hữu có quan trọng đối với việc chia sẻ chuyến giao hàng không? Nếu không, một chủ sở hữu khối lượng lớn chuyên dụng có thể hoạt động, được cách ly khỏi phân cấp vai trò và các nhóm của quy tắc chia sẻ như trên. Nếu có, một chủ sở hữu tích hợp duy nhất là mô hình nghiệp vụ sai: tích hợp tạo ra bản ghi; điều đó không có nghĩa nó nên sở hữu bản ghi.

Then the Retail Partner. Every work order carries its partner, deliberately, because partner isolation matters. But if one partner is 40% of the business, five years of deliveries is about 3.6 million work orders under one partner account. Does that make the relationship wrong? No. The business relationship is real, and I’m not going to invent 400 fake Redrock accounts because I don’t like the count. But I am going to look for a split the business would recognize. Each partner has real distribution centers, so a child account per DC under the partner spreads the work orders nine or more ways while every account still means something. Add archiving completed deliveries after the claims window, and the active children per parent stay low. ⟲

Đó là khác biệt giữa hai cách sửa. “Unassigned Contacts” vốn đã là nhân tạo, nên chia nó thành một nhóm không làm mất ý nghĩa gì. Redrock là một đối tác thật; chia nó thành Redrock 001, 002 và 003 sẽ làm hỏng mô hình. Chia nó theo các DC thật của nó thì không. Các cách sửa vì quy mô vẫn phải giữ được ý nghĩa. Đôi khi câu trả lời là một mối quan hệ khác, một chiến lược chia sẻ, một khuôn mẫu truy vấn, một mô hình lưu trữ hay một chính sách lưu trữ khác, không bao giờ là một danh tính giả cho một thực thể nghiệp vụ thật.

Nhấp để phóng to

Inspect, not bad. Concentration matters, not the total. ⟲

Tìm điểm nóng trên sơ đồ

Đây là một bài tập tôi thích. Lấy mô hình dữ liệu và nhìn vào các mũi tên, không chỉ các đối tượng. Với mỗi mối quan hệ, hãy hỏi: bao nhiêu bản ghi có thể dồn lại ở phía này của mũi tên? Rồi hỏi điều tương tự về Owner. Giờ hãy tưởng tượng ba năm, năm năm, mười năm. Bản ghi tập trung ở đâu? Đó thường là nơi vấn đề của ngày mai đang ẩn nấp.

Ngoài kỳ thi: AI thay đổi điều gì. Một người có thể tạo 20 bản ghi mỗi ngày; một tác tử có thể tạo hàng nghìn. Cho một tác tử người dùng riêng, để mọi bản ghi do nó sở hữu, và lệch quyền sở hữu xuất hiện nhanh hơn nhiều so với khi chỉ có con người. Việc tác tử sở hữu bản ghi không sai, nhưng hãy quyết định Owner nghĩa là gì cho bản ghi do tác tử tạo trước khi khối lượng biến giá trị mặc định thành một phần của kiến trúc.

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

• Ở đâu các quan hệ cha-con, quyền sở hữu hay tra cứu làm bản ghi tập trung lại, và chúng có đủ hoạt động để trở thành điểm nóng không.
• Bản ghi do máy tạo có tiếp tục do người dùng tích hợp hay tác tử sở hữu, hay được gán lại vì quyền sở hữu điều khiển quyền truy cập.
• Các chủ sở hữu khối lượng lớn được cách ly khỏi phân cấp vai trò và các nhóm của quy tắc chia sẻ thế nào.
• Khi nào một bản ghi cha nhân tạo có thể được chia thành nhóm, và khi nào một mối quan hệ thật cần một cách chia có ý nghĩa.
• Whether each master-detail relationship stays under about 10,000 children per parent at projected volume, or should be a lookup. ⟲

Một triệu bản ghi trải ra trên hàng nghìn chủ sở hữu và bản ghi cha hành xử rất khác với một triệu bản ghi trỏ vào một chỗ. Hãy tìm điểm nóng sớm: chủ sở hữu, bản ghi cha, quan hệ tra cứu, bất cứ đâu Số chữ số 0 hội tụ. Mục tiêu không phải là loại bỏ mọi mối quan hệ lớn; có những quan hệ phản ánh đúng nghiệp vụ. Mục tiêu là biết dòng xe đang đi về đâu trước khi bạn mở đường cao tốc, vì khi hàng triệu bản ghi đã cùng hướng về một lối ra, thay đổi con đường sẽ khó hơn nhiều.

Tìm hiểu thêm

• Salesforce Developers, Best Practices for Deployments with Large Data Volumes, Loading Data from the API (mở trong thẻ mới) (Winter ‘27): group child records by parent to minimize locking conflicts, checked 2026-11-01. ⟲
• Salesforce Help, Considerations for Object Relationships (mở trong thẻ mới): no more than 10,000 child records for a master-detail relationship; converting master-detail to lookup, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (mở trong thẻ mới) and Parent-Child Data Skew (mở trong thẻ mới), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes: General (mở trong thẻ mới) (Winter ‘27), the 10,000-record owner and parent guidance, checked 2026-11-01. ⟲
• Trailhead, Large Data Volumes: Design Your Data Model (mở trong thẻ mới): parent-child, ownership and lookup skew, checked 2026-11-01. ⟲
• Salesforce engineering blog, Managing Lookup Skew to Avoid Record Lock Exceptions (mở trong thẻ mới) (2013; older, but still the clearest explanation; checked 2026-11-01). ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲