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

Thiết kế cho quy mô lớn

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Hình ảnh được tạo bằng AI

Hướng dẫn ôn tập cho chương 7 của khóa học Data Architect. Hãy đọc bốn mô-đun trước; trang này giúp bạn kiểm tra những gì đã đọng lại.

Về hướng dẫn ôn tập này. Nó chỉ được xây dựng từ nội dung của chính khóa học này và danh sách mục tiêu trong hướng dẫn thi đã công bố của Salesforce. Nó không bao giờ dựa trên câu hỏi thi thật, và không tự nhận biết trong đề thi có gì. Nếu bạn đã thi, xin đừng gửi cho tôi câu hỏi trong đề: thỏa thuận chứng chỉ cấm chia sẻ chúng, và dù sao học thuộc đáp án cũng là cách sai để trở thành kiến trúc sư.

Chương này mở đầu Phần 2 và phần Large Data Volumes của kỳ thi (20%), cùng với lệch dữ liệu từ phần Data Modeling. Thiết kế truy vấn nằm ở chương sau; chương này nói về khối lượng, điểm nóng, chia sẻ ở quy mô lớn và vòng đời. Các con số của nền tảng thay đổi, nên hãy kiểm tra số hiện hành trước khi dựa vào chúng.

Cho kỳ thi

Phần tiêu đề “Cho kỳ thi ”

Hãy đánh dấu khi bạn đi qua. Mỗi điểm liên kết đến nơi được giảng dạy.

LDV-1: một mô hình mở rộng được

DM-5: lệch dữ liệu

  • Test knowledge: I know parent-child skew and the guidance of no more than about 10,000 children per parent; it’s a design threshold, not a cliff. Where security allows, Controlled by Parent on the child takes away the parent’s implicit shares to maintain. (Parent-Child Skew) ⟲
  • Tôi biết cách sửa bằng nhóm tài khoản cho một bản ghi cha nhân tạo, và ẩn các bản ghi cha giữ chỗ khỏi người dùng. (Tài khoản “Chưa gán”, và nhóm tài khoản)
  • Test knowledge: I know Salesforce’s best practice of no more than 10,000 children for one master-detail parent, and what master-detail brings at volume: no owner on the detail, cascade delete, no reparenting unless allowed, roll-up summaries, parent locking. I count the children before I choose master-detail or lookup, and I know converting back to a lookup needs no roll-up summaries on the master. (Master-Detail at Volume) ⟲
  • Test knowledge: I know ownership skew (one user owning more than 10,000 records of an object) and the fix: no role, or a separate stable role at the top, and out of public groups used by sharing rules. (Ownership Skew) ⟲
  • Tôi biết lệch tra cứu: nhiều bản ghi đang hoạt động trỏ vào một bản ghi, và việc khóa bản ghi mà nó có thể gây ra. (Lệch tra cứu)
  • Tôi phân biệt được một loại lệch nguy hiểm với một loại vô hại qua hoạt động của nó, không chỉ qua số lượng. (Không phải loại lệch nào cũng nguy hiểm như nhau)
  • Tôi sửa lệch trên một thực thể nghiệp vụ thật bằng một cách chia có ý nghĩa (một tài khoản con cho mỗi trung tâm phân phối), không bao giờ bằng các bản sao giả của nó. (Steve Trucking: Điểm nóng nằm ở đâu?)

DM-2: chia sẻ ở quy mô lớn

  • Tôi biết các cấu trúc truy cập (chủ sở hữu, vai trò, nhóm, chia sẻ) cũng là dữ liệu, và chúng cũng tăng theo quy mô. (Chia sẻ cũng là dữ liệu)
  • Test knowledge: I 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. (The Share Table Has Its Own Number of Zeros) ⟲
  • Tôi biết một thay đổi phân cấp vai trò ở khối lượng lớn là một thao tác dữ liệu, nên sự ổn định là một đặc tính thiết kế. (Phân cấp vai trò không phải là sơ đồ tổ chức)
  • Test knowledge: I know deferred sharing calculations: make all the changes, then recalculate once in a maintenance window, tested first in a full copy sandbox. (Sharing Recalculation Is Real Work) ⟲
  • Test knowledge: I know granular locking (on by default) lets unrelated group operations run together, but doesn’t fix a poor design. (Granular Locking Helps) ⟲
  • Tôi biết hiệu năng không phải là cái cớ để công khai dữ liệu lẽ ra phải riêng tư. (Đừng tối ưu đến mức bỏ mất bảo mật)

LDV-2: lưu trữ và xóa bỏ

  • Tôi tách được lưu giữ, lưu trữ và xóa bỏ, và đặt chúng ngay từ đầu dự án. (Xóa là điều không tránh khỏi)
  • Tôi đặt sao lưu sẵn sàng trước khi xóa bất cứ thứ gì, và biết sao lưu và lưu trữ là hai năng lực khác nhau (Salesforce Backup & Recover, Archive). (Sao lưu trước khi xóa)
  • Test knowledge: I can choose an archive destination by constraint: big objects, an external store through Salesforce Connect (OData, SQL adapters or a custom adapter), or Salesforce’s Archive. (Where Should the Archive Live?) ⟲
  • Test knowledge: I know what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. (Where Should the Archive Live?) ⟲
  • Test knowledge: I know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, Bulk API 2.0 hard delete; children before parents. (Deletion Is Inevitable) ⟲
  • Tôi biết lưu trữ ba bước (sao chép và đánh dấu, xác minh, xóa và chuyển trạng thái), và nó phải chạy lại được. (Lưu trữ ba bước)
  • Tôi biết dữ liệu đã lưu trữ phải tìm được và giữ được bảo mật của nó. (Một kho lưu trữ không ai tìm được gần như là đã xóa, Kho lưu trữ vẫn phải an toàn)

Ngoài kỳ thi

Phần tiêu đề “Ngoài kỳ thi ”

Kỳ thi là sàn, không phải trần. Đây là những thói quen từ chương này mà một kiến trúc sư cần, dù có câu hỏi nào hỏi về chúng hay không.

  • Salesforce is built for transactions on structured data, on a multitenant database where Salesforce writes the SQL. Millions of records perform well because somebody designed for them. (Built for Transactions) ⟲
  • My large data volume ruler (records in one object): around a million, a little drag; ten million, some effect but still performing; heading toward fifty million, list views take seconds, and past it you’re the convertible with your hair blown back; at a hundred million or more, ask whether the records should be here at all. ⟲
  • What works today may fail tomorrow. ⟲
  • Đôi khi cách sửa tốt nhất là đừng tạo ra vấn đề: giữ GPS, ảnh và lịch sử trạng thái ngoài lõi.
  • 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.
  • Ở quy mô này, thay đổi tổ chức trở thành thao tác dữ liệu.
  • Các cách sửa vì quy mô vẫn phải giữ được ý nghĩa.
  • Tìm điểm nóng trên sơ đồ: nhìn vào các mũi tên và hỏi bao nhiêu bản ghi dồn lại ở mỗi phía.
  • Hãy kiểm thử đúng Số chữ số 0 mà bạn thực sự đang thiết kế cho.
  • AI sẽ thêm nhiều chữ số 0 hơn. Hãy mô hình hóa rõ ràng khối lượng do tác tử tạo ra.
  • Who owns machine-created records depends on whether ownership matters for sharing. Created by and owned by aren’t the same question; decide what Owner means for each object. (Who Should Own Machine-Created Records?) ⟲
  • Nếu hôm nay bạn không lưu trữ, liệu bạn có bao giờ lưu trữ không?
  • Thiết kế lối ra khi bạn thiết kế lối vào. Năm câu trả lời cho mỗi đối tượng: khi nào nó thôi hoạt động, nó đi đâu, làm sao chứng minh, người ta tìm nó thế nào, khi nào nó bị xóa.
  • Tác tử có với tới được dữ liệu đã lưu trữ hay không là quyết định của doanh nghiệp.

Thuật ngữ cần biết

Phần tiêu đề “Thuật ngữ cần biết ”
Thuật ngữTrong một dòng
Khối lượng dữ liệu lớn (LDV)Đủ nhiều bản ghi để hành vi của nền tảng, không chỉ số lượng, định hình thiết kế
Lệch dữ liệuQuá nhiều bản ghi tập trung vào một bản ghi cha, một chủ sở hữu hay một giá trị tra cứu
Lệch cha-conQuá nhiều bản ghi con dưới một bản ghi cha
Lệch quyền sở hữuMột người dùng sở hữu hơn khoảng 10.000 bản ghi của một đối tượng
Lệch tra cứuNhiều bản ghi đang hoạt động tham chiếu đến một bản ghi, gây tranh chấp khóa
Nhóm tài khoảnVài bản ghi cha giữ chỗ cùng chia nhau các bản ghi con của một bản ghi cha nhân tạo
Controlled by ParentA sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain
Share objectThe table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause
Big objectAn object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only
Tính lại chia sẻNền tảng tính lại quyền truy cập sau một thay đổi về chủ sở hữu, vai trò, nhóm hay quy tắc
Hoãn phép tính chia sẻGiữ việc tính lại cho đến khi một loạt thay đổi hoàn tất, rồi chạy nó một lần
Khóa chi tiếtChỉ khóa những phần của bảng tư cách thành viên nhóm mà một thao tác cần
Lưu giữDữ liệu được giữ bao lâu, và vì sao
Lưu trữChuyển dữ liệu ra khỏi khối công việc đang hoạt động trong khi giữ quyền truy cập mà doanh nghiệp cần
Xóa bỏGỡ bỏ dữ liệu vĩnh viễn khi hết thời hạn lưu giữ
Lưu trữ ba bướcSao chép và đánh dấu, xác minh, rồi xóa và chuyển trạng thái

Tự kiểm tra

Phần tiêu đề “Tự kiểm tra ”

Những tình huống ngắn theo phong cách của khóa học. Hãy quyết định câu trả lời trước khi mở ra.

1. Một công ty thực hiện một triệu chuyến giao hàng mỗi năm, tăng trưởng 30 phần trăm, và giữ năm năm. Bạn thiết kế cho khối lượng nào?

Khoảng 9 triệu chuyến giao hàng được giữ trong năm năm, không phải một triệu, rồi đến các bản ghi con của chúng: khoảng 14,5 triệu mục dòng với 1,6 mục mỗi chuyến, và 72 triệu sự kiện trạng thái với tám sự kiện mỗi chuyến. Đọc lại Đừng hỏi hôm nay nó lớn đến đâu.

2. 300.000 liên hệ nằm dưới một tài khoản tên “Unassigned Contacts”. Bạn làm gì?

Đó là lệch cha-con nhân tạo. Rải các liên hệ ra một nhóm tài khoản gồm các bản ghi cha giữ chỗ, mỗi bản ghi dưới ngưỡng, và ẩn các bản ghi giữ chỗ đó khỏi các chế độ xem nghiệp vụ thông thường. Hoặc hỏi xem các liên hệ có thực sự cần một tài khoản không. Đọc lại Tài khoản “Chưa gán”, và nhóm tài khoản.

3. Một Đối tác bán lẻ sẽ có 3,6 triệu lệnh công việc. Ai đó đề xuất các tài khoản Redrock 001, 002 và 003. Ý kiến của bạn?

Không: điều đó làm hỏng một thực thể nghiệp vụ thật. Hãy tìm một cách chia mà doanh nghiệp nhận ra, như một tài khoản con cho mỗi trung tâm phân phối, và lưu trữ các chuyến giao hàng đã hoàn tất để giữ số bản ghi con đang hoạt động ở mức thấp. Đọc lại Steve Trucking: Điểm nóng nằm ở đâu?.

4. Một người dùng tích hợp sở hữu 2 triệu bản ghi và nằm trong một vai trò khu vực sắp bị di chuyển trong một đợt tái cơ cấu. Rủi ro là gì, và cách sửa?

Di chuyển nó buộc phải tính lại quyền truy cập trên 2 triệu bản ghi. Không gán vai trò cho chủ sở hữu khối lượng lớn, hoặc cho họ một vai trò riêng, ổn định ở đỉnh, giữ họ ngoài các nhóm của quy tắc chia sẻ, và quyết định xem quyền sở hữu có nên điều khiển quyền truy cập cho các bản ghi này không. Đọc lại Lệch quyền sở hữu.

5. Một đợt tái cơ cấu sẽ thay đổi hàng trăm vai trò, nhóm và quy tắc chia sẻ trong một cuối tuần. Bạn thực hiện thế nào?

Như một thao tác dữ liệu: kiểm thử ở khối lượng thật trong một sandbox Full, hoãn phép tính chia sẻ, thực hiện mọi thay đổi, tính lại một lần trong một khung bảo trì đã thống nhất, rồi xác minh, kèm một phương án dự phòng. Đọc lại Tính lại chia sẻ là công việc thật.

6. Đội dự định lưu trữ 20 triệu bản ghi bằng một tác vụ vừa sao chép vừa xóa. Bạn sẽ thay đổi gì?

Ba bước: sao chép và đánh dấu là đang chờ, xác minh kho lưu trữ (số lượng, mã định danh, mối quan hệ, khả năng truy xuất), rồi xóa và chuyển trạng thái, với các trạng thái để một lỗi ở bản ghi thứ 14 triệu có thể chạy lại an toàn. Và một bản sao lưu trước khi xóa bất cứ thứ gì. Đọc lại Lưu trữ ba bước.

7. Khách hàng không muốn dữ liệu được lưu ngoài Salesforce, nhưng cần giữ lịch sử cuộc hẹn nhiều năm. Kho lưu trữ có thể nằm ở đâu?

Trên nền tảng: big object, hoặc Archive của Salesforce. Với big object, hãy lên kế hoạch đường truy cập trước: không có giao diện hay báo cáo chuẩn, truy vấn qua chỉ mục. Và giữ cho nó tìm được, ví dụ hiển thị các cuộc hẹn đã lưu trữ bên dưới các cuộc hẹn đang hoạt động. Đọc lại Kho lưu trữ nên nằm ở đâu?.

Tìm hiểu thêm

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