What Works Today May Fail Tomorrow

🌐 มีให้อ่านอีก 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)

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ ส่วนนี้มีการเปลี่ยนแปลงในฉบับภาษาอังกฤษและยังไม่ได้แปลใหม่ (16)

บทที่ 7 ของ Data Architect และเป็นจุดเริ่มต้นของส่วนที่ 2: สถาปัตยกรรมในระดับขนาดใหญ่ ก่อนหน้า: ข้อมูลหลักและตัวตน

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 (เปิดในแท็บใหม่)). 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. ⟲

คลิกเพื่อขยาย

ส่วนที่ 1 สอนให้เรามองเห็น ส่วนที่ 2 วางน้ำหนักลงบนสถาปัตยกรรม บทนี้คือการทดสอบแรก: โครงกระดูกจะรับน้ำหนักของเลขศูนย์ได้ไหม?

Image generated with AI. ⟲

แนวคิดในบทนี้

• วางแผนด้วยจำนวนเลขศูนย์ โดยคิดถึงการเติบโตและตลอดระยะเวลาการเก็บรักษา ไม่ใช่จำนวนในวันนี้ เรกคอร์ดแม่หนึ่งล้านรายการที่แต่ละรายการมีเรกคอร์ดลูกแปดรายการ ไม่ใช่ปัญหาหนึ่งล้านเรกคอร์ด
• What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
• ออกแบบให้สะอาด แล้วถอยออกมาอย่างตั้งใจ เมื่อขนาดให้เหตุผลกับคุณ และอย่าทำให้ CRM หลักกลายเป็นคลังข้อมูลของคุณ
• 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. ⟲
• เจ้าของที่ถือเรกคอร์ดปริมาณมากต้องอยู่นอกลำดับชั้นบทบาท หรืออยู่ในบทบาทของตัวเองที่มั่นคงที่ด้านบนสุด และอยู่นอกกลุ่มที่กฎการแชร์ใช้
• ใครควรเป็นเจ้าของเรกคอร์ดที่เครื่องสร้างขึ้น ขึ้นอยู่กับว่าความเป็นเจ้าของมีผลต่อการแชร์หรือไม่
• ในระดับขนาดใหญ่ การจัดโครงสร้างความปลอดภัยใหม่คือการดำเนินการกับข้อมูล เลื่อนการคำนวณการแชร์ ซ้อมใน Full sandbox แล้วคำนวณใหม่ครั้งเดียว และอย่าทำให้ข้อมูลเป็นสาธารณะเพียงเพราะแบบส่วนตัวช้ากว่า
• ถ้าคุณไม่จัดเก็บถาวรวันนี้ คุณจะจัดเก็บถาวรเมื่อไหร่? ตัดสินใจเรื่องการลบตั้งแต่วันแรก สำรองข้อมูลก่อนลบ และทำให้ข้อมูลที่จัดเก็บถาวรยังค้นหาได้
• การที่ข้อมูลที่จัดเก็บถาวรแล้วยังอยู่ในระยะที่เอเจนต์เข้าถึงได้หรือไม่ เป็นการตัดสินใจของธุรกิจ

Where volume causes problems

อะไรที่เติบโต	อะไรที่ช้าลง	ครอบคลุมที่ไหน
เรกคอร์ดในออบเจกต์เดียว	Query มุมมองรายการ รายงาน	โมดูลที่ 1; บทที่ 8
เรกคอร์ดลูกใต้เรกคอร์ดแม่เดียว เรกคอร์ดใต้เจ้าของคนเดียว	การล็อก การคำนวณการแชร์ใหม่	โมดูลที่ 2
Children under one master-detail parent	Locking, roll-ups, cascade delete, a hard-to-undo choice	Module 2
ผู้ใช้ บทบาท กลุ่ม และกฎ	การคำนวณสิทธิ์เข้าถึงใหม่ การจัดโครงสร้างใหม่	โมดูลที่ 3
ประวัติที่ไม่มีใครใช้	ทุกอย่าง บวกพื้นที่จัดเก็บและความเสี่ยง	โมดูลที่ 4

เส้นทางผ่านบทนี้

สี่โมดูล แต่ละโมดูลอ่านแยกกันได้

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. เมื่อปริมาณพบกับโมเดลการแชร์ ความเป็นเจ้าของในฐานะคันโยกของสิทธิ์เข้าถึง ลำดับชั้นที่มั่นคง การเลื่อนการคำนวณการแชร์ การล็อกแบบละเอียด และการแยกพาร์ทเนอร์ในระดับขนาดใหญ่
4. ถ้าคุณไม่จัดเก็บถาวรวันนี้… วงจรชีวิตตั้งแต่วันแรก สำรองข้อมูลก่อนลบ ที่เก็บข้อมูลถาวรอยู่ที่ไหน การจัดเก็บถาวรสามขั้นตอน และเอเจนต์กับข้อมูลเก่า

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• แต่ละออบเจกต์จะใหญ่แค่ไหน เมื่อเติบโตและตลอดระยะเวลาการเก็บรักษา
• เรกคอร์ดกระจุกตัวอยู่ที่ไหน และการกระจุกตัวแบบไหนที่อันตราย
• ความเป็นเจ้าของหมายถึงอะไร สำหรับออบเจกต์ปริมาณมากแต่ละตัว รวมถึงออบเจกต์ที่เอเจนต์สร้าง
• โมเดลสิทธิ์เข้าถึงขยายตัวอย่างไร และการจัดโครงสร้างใหม่ครั้งใหญ่วางแผนอย่างไร
• ข้อมูลออกไปอย่างไร: จัดเก็บถาวร ลบทิ้ง สำรองข้อมูล และใครยังค้นหามันได้

นอกเหนือจากการสอบ: เอเจนต์เพิ่มเลขศูนย์ มันอาจสร้างสิบเรกคอร์ดในที่ที่คนสร้างหนึ่งเรกคอร์ด เป็นเจ้าของทั้งหมดโดยค่าเริ่มต้น ดึงข้อมูลได้เร็วกว่าใคร และเอื้อมเข้าไปถึงข้อมูลที่จัดเก็บถาวร เว้นแต่จะมีคนตัดสินใจว่าไม่ควร แต่ละโมดูลจบด้วยสิ่งที่ AI เปลี่ยนสำหรับส่วนของปัญหานั้น

ศึกษาเพิ่มเติม

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (เปิดในแท็บใหม่) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (เปิดในแท็บใหม่) (Winter ‘27), checked 2026-11-01. ⟲

ถัดไป: สถาปัตยกรรม Query และการดึงข้อมูล