การออกแบบเพื่อรองรับขนาด
มีให้อ่านอีก 19 ภาษา
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
คู่มือทบทวนสำหรับบทที่ 7 ของหลักสูตร Data Architect อ่านสี่โมดูลก่อน หน้านี้ช่วยให้คุณตรวจสอบว่าอะไรติดอยู่ในหัวบ้าง
เกี่ยวกับคู่มือทบทวนนี้ คู่มือนี้สร้างขึ้นจากเนื้อหาของหลักสูตรนี้และรายการวัตถุประสงค์ในคู่มือการสอบที่ Salesforce เผยแพร่เท่านั้น ไม่เคยอิงจากข้อสอบจริง และไม่ได้อ้างว่ารู้ว่าข้อสอบมีอะไร ถ้าคุณเคยสอบแล้ว ได้โปรดอย่าส่งข้อสอบมาให้ผม: ข้อตกลงการรับรองห้ามแชร์ข้อสอบ และการท่องจำคำตอบก็เป็นวิธีที่ผิดในการเป็นสถาปนิกอยู่ดี
บทนี้เปิดส่วนที่ 2 และส่วน Large Data Volumes ของข้อสอบ (20%) พร้อมเรื่องข้อมูลกระจุกตัวจากส่วน Data Modeling การออกแบบ query อยู่ในบทถัดไป บทนี้ว่าด้วยปริมาณ จุดร้อน การแชร์ในระดับขนาดใหญ่ และวงจรชีวิต ตัวเลขของแพลตฟอร์มเปลี่ยนได้ จึงควรตรวจสอบตัวเลขปัจจุบันก่อนพึ่งพามัน
สำหรับการสอบ
หัวข้อที่มีชื่อว่า “สำหรับการสอบ ”ทำเครื่องหมายไปทีละข้อ แต่ละข้อลิงก์ไปยังส่วนที่สอนเรื่องนั้น
LDV-1: โมเดลที่รองรับการขยายตัว
- ฉันกำหนดขนาดการออกแบบตามการเติบโตตลอดระยะเวลาการเก็บรักษา ไม่ใช่ปริมาณวันนี้ และฉันคูณเรกคอร์ดลูกเข้าไปด้วย (อย่าถามว่าวันนี้มันใหญ่แค่ไหน, ทีนี้คูณเรกคอร์ดลูกเข้าไป)
- ฉันรู้ว่าปริมาณมีผลมากกว่าแค่ query: การแชร์ ความเป็นเจ้าของ การล็อก มุมมองรายการ รายงาน batch การโหลด การลบ และการกู้คืน (Query ไม่ใช่สิ่งเดียวที่ช้าลง)
- ฉันรู้ว่าเมื่อไหร่ที่ขนาดเป็นเหตุผลให้ลดการ normalize อย่างควบคุมได้ และต้นทุนของมันคืออะไร (โมเดลที่สะอาดอาจกลายเป็นโมเดลที่แพง)
- ฉันรู้ว่าไม่ควรเปลี่ยน CRM สำหรับการปฏิบัติงานให้กลายเป็นคลังข้อมูล และ reporting snapshot ไม่ใช่กลยุทธ์คลังข้อมูล (อย่าทำให้ CRM หลักกลายเป็นคลังข้อมูลของคุณ)
- ฉันรู้ว่าปริมาณมีรูปร่าง: ยี่สิบล้านเรกคอร์ดที่ทำอะไร? (ปริมาณมีรูปร่าง)
DM-5: ข้อมูลกระจุกตัว
- 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) ⟲
- ฉันรู้วิธีแก้ด้วยกลุ่มบัญชีสำรองสำหรับเรกคอร์ดแม่เทียม และการซ่อนเรกคอร์ดแม่ที่เป็นตัวยึดที่ไว้จากผู้ใช้ (บัญชี “Unassigned” และกลุ่มบัญชีสำรอง)
- 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) ⟲
- ฉันรู้เรื่องข้อมูลกระจุกตัวแบบ lookup: เรกคอร์ดที่ยังใช้งานจำนวนมากชี้ไปยังเรกคอร์ดเดียว และการล็อกเรกคอร์ดที่มันอาจก่อให้เกิด (ข้อมูลกระจุกตัวแบบ lookup)
- ฉันแยกข้อมูลกระจุกตัวที่อันตรายออกจากแบบที่ไม่มีพิษภัยได้จากกิจกรรมของมัน ไม่ใช่แค่จำนวน (ข้อมูลกระจุกตัวไม่ได้อันตรายเท่ากันทุกแบบ)
- ฉันแก้ข้อมูลกระจุกตัวบนเอนทิตีธุรกิจจริงด้วยการแบ่งที่มีความหมาย (บัญชีลูกหนึ่งบัญชีต่อศูนย์กระจายสินค้า) ไม่ใช่สำเนาปลอมของมัน (Steve Trucking: จุดร้อนอยู่ที่ไหน?)
DM-2: การแชร์ในระดับขนาดใหญ่
- ฉันรู้ว่าโครงสร้างสิทธิ์เข้าถึง (เจ้าของ บทบาท กลุ่ม การแชร์) ก็เป็นข้อมูลเช่นกัน และมันขยายตัวตาม (การแชร์ก็เป็นข้อมูลเช่นกัน)
- 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) ⟲ - ฉันรู้ว่าการเปลี่ยนลำดับชั้นบทบาทเมื่อปริมาณมากคือการดำเนินการกับข้อมูล ดังนั้นความมั่นคงคือคุณสมบัติของการออกแบบ (ลำดับชั้นบทบาทไม่ใช่ผังองค์กร)
- 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) ⟲
- ฉันรู้ว่าประสิทธิภาพไม่ใช่ข้ออ้างในการทำข้อมูลที่ควรเป็นส่วนตัวให้เป็นสาธารณะ (อย่าปรับประสิทธิภาพจนความปลอดภัยหายไป)
LDV-2: การจัดเก็บถาวรและการลบทิ้ง
- ฉันแยกการเก็บรักษา การจัดเก็บถาวร และการลบทิ้งออกจากกันได้ และกำหนดมันตั้งแต่เริ่มโครงการ (การลบหลีกเลี่ยงไม่ได้)
- ฉันจัดให้มีการสำรองข้อมูลก่อนลบอะไรก็ตาม และรู้ว่าการสำรองข้อมูลกับการจัดเก็บถาวรเป็นความสามารถคนละอย่าง (Salesforce Backup & Recover, Archive) (สำรองข้อมูลก่อนลบ)
- 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) ⟲
- ฉันรู้เรื่องการจัดเก็บถาวรสามขั้นตอน (คัดลอกและติดธง ตรวจยืนยัน ลบและพลิกสถานะ) และมันต้องเริ่มใหม่ได้ (การจัดเก็บถาวรสามขั้นตอน)
- ฉันรู้ว่าข้อมูลที่จัดเก็บถาวรต้องยังค้นหาได้และรักษาความปลอดภัยของมันไว้ (ที่จัดเก็บถาวรที่ไม่มีใครหาเจอ เกือบเท่ากับการลบ, ที่จัดเก็บถาวรยังต้องปลอดภัย)
นอกเหนือจากการสอบ
หัวข้อที่มีชื่อว่า “นอกเหนือจากการสอบ ”การสอบคือพื้น ไม่ใช่เพดาน นี่คือนิสัยจากบทนี้ที่สถาปนิกต้องมี ไม่ว่าจะมีคำถามข้อใดถามถึงหรือไม่
- 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. ⟲
- บางครั้งการแก้ที่ดีที่สุดคืออย่าสร้างปัญหา: เก็บ GPS ภาพถ่าย และประวัติสถานะไว้นอกระบบหลัก
- ตัวเลขบอกผมว่าควรมองที่ไหน พฤติกรรมบอกผมว่าควรกังวลแค่ไหน
- ในระดับนี้ การเปลี่ยนแปลงองค์กรกลายเป็นการดำเนินการกับข้อมูล
- การแก้ปัญหาด้านขนาดยังต้องรักษาความหมาย
- หาจุดร้อนบนแผนภาพ: ดูที่ลูกศรแล้วถามว่าเรกคอร์ดจะกองรวมกันที่แต่ละฝั่งได้กี่รายการ
- ทดสอบที่จำนวนเลขศูนย์ที่คุณกำลังออกแบบจริงๆ
- AI จะเพิ่มเลขศูนย์ให้มากขึ้น จงสร้างโมเดลปริมาณที่เอเจนต์สร้างขึ้นอย่างชัดเจน
- 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?) ⟲
- ถ้าคุณไม่เก็บถาวรวันนี้ คุณจะได้เก็บถาวรไหม?
- ออกแบบทางออกตอนที่คุณออกแบบทางเข้า ห้าคำตอบต่อออบเจกต์: เมื่อไหร่ที่มันเลิกใช้งาน มันไปที่ไหน เราพิสูจน์อย่างไร คนหามันเจอได้อย่างไร มันถูกลบเมื่อไหร่
- การที่เอเจนต์เข้าถึงข้อมูลที่จัดเก็บถาวรได้หรือไม่ เป็นการตัดสินใจของธุรกิจ
คำศัพท์ที่ควรรู้
หัวข้อที่มีชื่อว่า “คำศัพท์ที่ควรรู้ ”| คำศัพท์ | ในหนึ่งบรรทัด |
|---|---|
| ข้อมูลปริมาณมาก (LDV) | เรกคอร์ดมากพอที่พฤติกรรมของแพลตฟอร์ม ไม่ใช่แค่จำนวน เป็นตัวกำหนดการออกแบบ |
| ข้อมูลกระจุกตัว (data skew) | เรกคอร์ดมากเกินไปที่กระจุกอยู่กับเรกคอร์ดแม่ เจ้าของ หรือค่า lookup เดียว |
| ข้อมูลกระจุกตัวแบบแม่-ลูก | เรกคอร์ดลูกมากเกินไปใต้เรกคอร์ดแม่หนึ่งรายการ |
| ข้อมูลกระจุกตัวด้านความเป็นเจ้าของ | ผู้ใช้คนเดียวเป็นเจ้าของมากกว่าประมาณ 10,000 เรกคอร์ดของออบเจกต์หนึ่ง |
| ข้อมูลกระจุกตัวแบบ lookup | เรกคอร์ดที่ยังใช้งานจำนวนมากอ้างอิงถึงเรกคอร์ดเดียว ทำให้เกิดการแย่งล็อก |
| กลุ่มบัญชีสำรอง (account pool) | เรกคอร์ดแม่ที่เป็นตัวยึดที่ไว้หลายตัวที่แบ่งเรกคอร์ดลูกของเรกคอร์ดแม่เทียมกันไป |
| Controlled by Parent | A sharing setting where the child’s access comes from its parent, so the parent has no implicit shares to maintain |
| Share object | The table of sharing rows for an object (AccountShare, Object__Share): one row per grant, with a row cause |
| Big object | An object built for very large volumes, reached through Apex, APIs and its index; object and field permissions only |
| การคำนวณการแชร์ใหม่ | แพลตฟอร์มคำนวณสิทธิ์เข้าถึงใหม่หลังการเปลี่ยนแปลงเจ้าของ บทบาท กลุ่ม หรือกฎ |
| การเลื่อนการคำนวณการแชร์ | พักการคำนวณใหม่ไว้จนกว่าการเปลี่ยนแปลงชุดหนึ่งจะเสร็จ แล้วรันครั้งเดียว |
| การล็อกแบบละเอียด | ล็อกเฉพาะส่วนของตารางการเป็นสมาชิกกลุ่มที่การดำเนินการต้องใช้ |
| การเก็บรักษา | ข้อมูลถูกเก็บไว้นานแค่ไหน และทำไม |
| การจัดเก็บถาวร | การย้ายข้อมูลออกจากภาระงานที่ใช้งานอยู่ ขณะที่ยังรักษาสิทธิ์เข้าถึงที่ธุรกิจต้องการ |
| การลบทิ้ง | การนำข้อมูลออกอย่างถาวรเมื่อสิ้นสุดระยะการเก็บรักษา |
| การจัดเก็บถาวรสามขั้นตอน | คัดลอกและติดธง ตรวจยืนยัน แล้วลบและพลิกสถานะ |
ทดสอบตัวเอง
หัวข้อที่มีชื่อว่า “ทดสอบตัวเอง ”สถานการณ์สั้นๆ ในแบบของหลักสูตร ตัดสินคำตอบของคุณก่อนเปิดดู
1. บริษัทหนึ่งจัดส่งหนึ่งล้านรายการต่อปี เติบโต 30 เปอร์เซ็นต์ และเก็บไว้ห้าปี คุณออกแบบสำหรับปริมาณเท่าไร?
ประมาณ 9 ล้านการจัดส่งที่เก็บไว้ตลอดห้าปี ไม่ใช่หนึ่งล้าน แล้วยังมีเรกคอร์ดลูก: ประมาณ 14.5 ล้านรายการที่ 1.6 รายการต่อการจัดส่ง และ 72 ล้านเหตุการณ์สถานะที่แปดครั้งต่อการจัดส่ง อ่านทวน อย่าถามว่าวันนี้มันใหญ่แค่ไหน
2. ผู้ติดต่อ 300,000 รายอยู่ใต้บัญชีเดียวชื่อ “Unassigned Contacts” คุณทำอย่างไร?
นั่นคือข้อมูลกระจุกตัวแบบแม่-ลูกที่เป็นของเทียม กระจายผู้ติดต่อไปยังกลุ่มบัญชีสำรองที่เป็นเรกคอร์ดแม่ตัวยึดที่ไว้ โดยให้แต่ละบัญชีอยู่ใต้เกณฑ์ และซ่อนตัวยึดที่ไว้เหล่านั้นจากมุมมองทางธุรกิจปกติ หรือถามว่าผู้ติดต่อต้องมีบัญชีจริงๆ หรือไม่ อ่านทวน บัญชี “Unassigned” และกลุ่มบัญชีสำรอง
3. พาร์ทเนอร์ค้าปลีกรายหนึ่งจะมี 3.6 ล้านใบสั่งงาน มีคนเสนอให้สร้างบัญชี Redrock 001, 002 และ 003 คุณเห็นอย่างไร?
ไม่: นั่นทำให้เอนทิตีธุรกิจจริงเสียหาย มองหาการแบ่งที่ธุรกิจจดจำได้ เช่นบัญชีลูกหนึ่งบัญชีต่อศูนย์กระจายสินค้า และจัดเก็บถาวรการจัดส่งที่เสร็จแล้วเพื่อให้เรกคอร์ดลูกที่ยังใช้งานอยู่ในระดับต่ำ อ่านทวน Steve Trucking: จุดร้อนอยู่ที่ไหน?
4. ผู้ใช้สำหรับการผสานรวมคนหนึ่งเป็นเจ้าของ 2 ล้านเรกคอร์ด และอยู่ในบทบาทระดับภูมิภาคที่กำลังจะถูกย้ายในการปรับโครงสร้าง ความเสี่ยงคืออะไร และแก้อย่างไร?
การย้ายมันบังคับให้คำนวณสิทธิ์เข้าถึงใหม่ทั่ว 2 ล้านเรกคอร์ด ไม่ต้องกำหนดบทบาทให้เจ้าของที่ถือเรกคอร์ดปริมาณมาก หรือให้บทบาทแยกที่มั่นคงที่ด้านบนสุด กันไว้นอกกลุ่มของกฎการแชร์ และตัดสินใจว่าความเป็นเจ้าของควรขับเคลื่อนสิทธิ์เข้าถึงสำหรับเรกคอร์ดเหล่านี้หรือไม่ อ่านทวน ข้อมูลกระจุกตัวด้านความเป็นเจ้าของ
5. การปรับโครงสร้างจะเปลี่ยนบทบาท กลุ่ม และกฎการแชร์หลายร้อยรายการในช่วงสุดสัปดาห์ คุณดำเนินการอย่างไร?
ในฐานะการดำเนินการกับข้อมูล: ทดสอบที่ปริมาณจริงใน full copy sandbox เลื่อนการคำนวณการแชร์ ทำการเปลี่ยนแปลงทั้งหมด คำนวณใหม่ครั้งเดียวในช่วงเวลาบำรุงรักษาที่ตกลงกัน แล้วตรวจยืนยัน พร้อมแผนสำรอง อ่านทวน การคำนวณการแชร์ใหม่คืองานจริง
6. ทีมวางแผนจะจัดเก็บถาวร 20 ล้านเรกคอร์ดด้วยงานเดียวที่คัดลอกและลบ คุณจะเปลี่ยนอะไร?
สามขั้นตอน: คัดลอกและติดธงว่ารอดำเนินการ ตรวจยืนยันที่จัดเก็บถาวร (จำนวน ตัวระบุ ความสัมพันธ์ การดึงกลับ) แล้วลบและพลิกสถานะ โดยมีสถานะต่างๆ เพื่อให้ความล้มเหลวที่เรกคอร์ดที่ 14 ล้านเริ่มใหม่ได้อย่างปลอดภัย และสำรองข้อมูลก่อนลบอะไรก็ตาม อ่านทวน การจัดเก็บถาวรสามขั้นตอน
7. ลูกค้าไม่ต้องการให้เก็บข้อมูลนอก Salesforce แต่ต้องเก็บประวัติการนัดหมายหลายปี ที่จัดเก็บถาวรอยู่ที่ไหนได้บ้าง?
บนแพลตฟอร์ม: big object หรือ Archive ของ Salesforce ถ้าใช้ big object ให้วางแผนเส้นทางการเข้าถึงก่อน: ไม่มี UI หรือรายงานมาตรฐาน query ผ่านดัชนี และทำให้มันยังค้นหาได้ เช่นแสดงการนัดหมายที่จัดเก็บถาวรใต้รายการที่ใช้งานอยู่ อ่านทวน ที่จัดเก็บถาวรควรอยู่ที่ไหน?
ศึกษาเพิ่มเติม
หัวข้อที่มีชื่อว่า “ศึกษาเพิ่มเติม ”- Salesforce Certified Platform Data Architect Exam Guide (เปิดในแท็บใหม่), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- ส่วนศึกษาเพิ่มเติมของแต่ละโมดูลแสดงรายการเอกสาร Salesforce ที่อยู่เบื้องหลังข้อเท็จจริงในโมดูลนั้น