Khối lượng gặp mô hình chia sẻ

🌐 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 3 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: Điểm nóng: Lệch quyền sở hữu, lệch cha và lệch tra cứu · Tiếp theo: Nếu hôm nay bạn không lưu trữ…

Câu hỏi mô-đun này trả lời: Làm sao một mô hình tôn trọng chia sẻ vẫn nhanh ở khối lượng lớn?

Mô-đun trước đã tìm ra các điểm nóng. Giờ hãy thêm bảo mật, nơi một kiến trúc dữ liệu trông hợp lý trở nên đắt đỏ. Chín triệu lệnh công việc là một bài toán khối lượng. Chín triệu lệnh công việc, mỗi lệnh chỉ hiển thị cho đúng những người dùng nội bộ cần thấy và đúng Đối tác bán lẻ của nó, là một bài toán chia sẻ ở khối lượng lớn. Một bản ghi không chỉ được lưu; Salesforce còn phải trả lời ai được thấy nó? Ở quy mô lớn, câu trả lời đó là một phần của kiến trúc dữ liệu.

Chia sẻ cũng là dữ liệu

Khi kiến trúc sư đếm khối lượng, họ đếm bản ghi nghiệp vụ. Nhưng Salesforce cũng duy trì những gì hỗ trợ quyền truy cập: chủ sở hữu, vai trò, nhóm, quy tắc chia sẻ, chia sẻ tường minh, tư cách thành viên. Ở quy mô nhỏ, bạn có thể quên rằng khối công việc đó tồn tại. Ở quy mô lớn thì không. Đó là lý do tôi không bao giờ nói “đội bảo mật sẽ lo chuyện chia sẻ sau”. Mối quan hệ tôi chọn, chủ sở hữu, bản ghi cha, mô hình người dùng bên ngoài: mỗi thứ đều ảnh hưởng đến chia sẻ. Kiến trúc sư dữ liệu và kiến trúc sư chia sẻ có thể là những người khác nhau, nhưng kiến trúc của họ gắn với nhau.

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (mở trong thẻ mới); Sharing a Record Using Apex (mở trong thẻ mới)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood (mở trong thẻ mới), Winter ‘27, archived copy (mở trong thẻ mới)). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare (mở trong thẻ mới)). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

Nhấp để phóng to

Step 1 of 3: the records. Nine million work orders. ⟲

Nhấp để phóng to

Step 2 of 3: the share table, three rules to groups. ⟲

Nhấp để phóng to

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. ⟲

Bắt đầu từ yêu cầu truy cập

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

Phân cấp vai trò không phải là sơ đồ tổ chức

Các nhóm thiết kế phân cấp vai trò giống hệt sơ đồ tổ chức. Rồi công ty tái cơ cấu, ai đó di chuyển một vai trò, và Salesforce phải tính ra hệ quả về quyền truy cập. Ở quy mô nhỏ không ai để ý. Ở hàng triệu bản ghi, tái cơ cấu là một thao tác dữ liệu lớn. Đó là lý do hướng dẫn cho chủ sở hữu khối lượng lớn là không gán vai trò, hoặc một vai trò riêng, ổn định ở đỉnh phân cấp (Ownership Data Skew (mở trong thẻ mới)). Nguyên tắc này áp dụng rộng hơn: ở quy mô lớn, sự ổn định là một đặc tính thiết kế. Càng nhiều bản ghi treo trên một cấu trúc chia sẻ, bạn càng phải thay đổi nó cẩn thận.

Nhóm cũng vậy. Nhóm công khai cấp dữ liệu cho quy tắc chia sẻ; người dùng thuộc về nhóm; nhóm chứa nhóm. Những công cụ hữu ích, nhưng nếu một lượng lớn người dùng và bản ghi phụ thuộc vào tư cách thành viên nhóm thay đổi liên tục, bạn cần hiểu việc tính lại. Đó là lý do chủ sở hữu khối lượng lớn đứng ngoài các nhóm công khai được dùng làm nguồn cho quy tắc chia sẻ (cùng nguồn). Bài học không phải là “nhóm công khai là xấu”. Mà là: đừng nối điểm tập trung bản ghi lớn nhất của bạn với các cấu trúc truy cập biến động nhất mà không suy nghĩ kỹ.

Tính lại chia sẻ là công việc thật

Steve Trucking thay đổi mô hình vận hành: hàng trăm người dùng chuyển chỗ, quyền sở hữu thay đổi, vai trò và nhóm thay đổi, một quy tắc chia sẻ lớn thay đổi. Nghe như cấu hình. Nhưng nền tảng có thể phải tính lại quyền truy cập trên một lượng lớn bản ghi, nên tôi coi đó là một thao tác dữ liệu. Bao nhiêu người dùng, bản ghi, thay đổi quyền sở hữu và tư cách thành viên? Bao nhiêu việc tính lại? Chúng ta có thể kiểm thử nó ở khối lượng thật không? Khi nào nên chạy, và người dùng thấy gì trong lúc đó? Một đợt sắp xếp lại bảo mật lớn xứng đáng được đối xử kỷ luật như một đợt chuyển đổi dữ liệu lớn.

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance (mở trong thẻ mới)). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale (mở trong thẻ mới), Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

Nhấp để phóng to

At scale, access realignment is a data operation. ⟲

“Hoãn” không có nghĩa là tùy tiện. Nếu một thay đổi đủ lớn để phải hoãn chia sẻ, tôi muốn có một kế hoạch: kiểm thử ở khối lượng thực tế, một khung bảo trì được doanh nghiệp đồng ý, bước xác minh, phương án dự phòng nếu nó không chạy xong, và hiểu được người dùng trải nghiệm gì trong lúc đó. Hướng dẫn của Salesforce là mô phỏng nó trước trong một sandbox Full (cùng nguồn), vì một mô hình bảo mật chạy tuyệt vời với 5.000 bản ghi thử nghiệm chẳng chứng minh được gì về 50 triệu. Hãy kiểm thử đúng Số chữ số 0 mà bạn thực sự đang thiết kế cho.

Khóa chi tiết giúp ích, nhưng không phải thuốc chữa

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking (mở trong thẻ mới)); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking: Cách ly đối tác ở quy mô lớn

Ở Điểm kiểm tra 1, mỗi lệnh công việc mang theo Đối tác bán lẻ của nó, một cách bền vững, vì cách ly đối tác là một yêu cầu. Các con số quy mô làm điều đó quan trọng hơn, không kém đi: nếu Redrock chiếm 40% doanh nghiệp, đó là khoảng 3,6 triệu lệnh công việc của Redrock trong năm năm. Mối quan hệ là đúng; Redrock thực sự là một đối tác. Vậy nên thiết kế truy cập phải đi theo quan hệ nghiệp vụ thật (người dùng đối tác thấy lệnh công việc của đối tác mình, quản lý DC chỉ thấy của DC mình) thay vì bóp méo mô hình. Cấu trúc tài khoản con cho mỗi DC từ mô-đun trước giúp ở đây hai lần: nó rải các bản ghi con ra, và nó cho quyền truy cập cấp DC một thứ thật để bám vào.

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

Truy cập nội bộ lại khác nữa

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

Đôi khi bảo mật nên thay đổi mô hình. Khi hai loại thông tin có chủ sở hữu, vòng đời, đối tượng người xem hay nhu cầu chia sẻ hoàn toàn khác nhau, bạn có thể chồng các biện pháp kiểm soát cấp trường lên một bản ghi, hoặc tách dữ liệu thành đối tượng riêng với ranh giới riêng. Tôi không tách chỉ để khỏi phải cấu hình bảo mật cấp trường, nhưng bảo mật là lý do chính đáng để thay đổi mô hình vật lý.

Chia sẻ có Số chữ số 0 của riêng nó

Hai thiết kế, mỗi thiết kế 10 triệu bản ghi: một có quyền sở hữu đơn giản, phân cấp ổn định, ít quy tắc chia sẻ và ít biến động thành viên; cái kia có quyền sở hữu phân tán cao, vai trò thay đổi thường xuyên, các nhóm lồng nhau lớn, nhiều quy tắc chia sẻ và tái cơ cấu liên tục. Cùng số bản ghi, bài toán quy mô hoàn toàn khác. Vậy nên với mỗi đối tượng khối lượng lớn, tôi cũng muốn các con số của mô hình truy cập: bao nhiêu chủ sở hữu và tập trung đến đâu, quyền truy cập mặc định, những quan hệ phân cấp, quy tắc và nhóm nào quan trọng, bao nhiêu người dùng bên ngoài, và chuyện gì xảy ra khi ai đó đổi vai trò, một đối tác được thêm vào, hay một khu vực được tái cơ cấu. Rồi một câu hỏi: đợt tính lại lớn nhất mà thiết kế này có thể gây ra là gì? Đó là kịch bản tôi muốn được kiểm thử.

Nhấp để phóng to

Count the access model, not just the records. ⟲

Đừng tối ưu đến mức bỏ mất bảo mật

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

Ngoài kỳ thi: AI thay đổi điều gì. Tác tử truy xuất và tổng hợp nhanh hơn bất kỳ người nào, điều đó làm cho một mô hình truy cập quá rộng trở nên nguy hiểm hơn. Đừng dựa vào một câu lệnh prompt nói “đừng cho Redrock thấy dữ liệu của Brightwave”. Ranh giới thuộc về kiến trúc: ủy quyền nên giới hạn những gì tác tử với tới được, chứ không phải chỉ dẫn về những gì nó chọn tiết lộ. Hãy mở rộng mô hình ủy quyền cùng với mô hình dữ liệu.

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

• Những mối quan hệ, chủ sở hữu, vai trò, nhóm và quy tắc chia sẻ nào điều khiển quyền truy cập cho mỗi đối tượng khối lượng lớn.
• Các chủ sở hữu khối lượng lớn và những điểm nóng khác có được cách ly khỏi các cấu trúc phân cấp và nhóm biến động không.
• Các đợt sắp xếp lại quyền truy cập lớn được kiểm thử, lên lịch, tính lại một lần và xác minh ở khối lượng thực tế thế nào.
• Những nhu cầu bảo mật khác nhau có biện minh cho việc tách dữ liệu thay vì làm phức tạp quyền truy cập vào một bản ghi không.
• Quyền truy cập của đối tác, nhân viên, ứng dụng và tác tử giữ gắn với quan hệ nghiệp vụ thế nào, chứ không phải với những lối tắt về danh tính.

Vẽ một thiết kế an toàn cho 1.000 bản ghi thì dễ, và một thiết kế nhanh nơi ai cũng thấy mọi thứ cũng dễ. Việc của kiến trúc sư là hệ thống mà cả hai cùng tồn tại: đúng người thấy đúng dữ liệu, và nó vẫn chạy khi chúng ta thêm các chữ số 0. Ở quy mô lớn, chia sẻ là một phần của kiến trúc dữ liệu.

Tìm hiểu thêm

• Object Reference for the Salesforce Platform, WorkOrderShare (mở trong thẻ mới) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (mở trong thẻ mới) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (mở trong thẻ mới), Group Membership Locking (mở trong thẻ mới) and Deferred Sharing Maintenance (mở trong thẻ mới), checked 2026-11-01. ⟲
• Để đi sâu hơn: khóa học Sharing and Visibility Architect, Chia sẻ ở quy mô lớn (coming soon).
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood (mở trong thẻ mới) (Winter ‘27, archived copy (mở trong thẻ mới)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (mở trong thẻ mới) and Sharing a Record Using Apex (mở trong thẻ mới), checked 2026-11-01. ⟲