What Works Today May Fail Tomorrow
Juga tersedia dalam 19 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Bab 7 dari Data Architect, dan awal Bagian 2: Arsitektur dalam Skala Besar. Sebelumnya: Data Master dan Identitas.
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 (terbuka di tab baru)). 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. ⟲
Bagian 1 mengajari kita untuk melihat. Bagian 2 memberi arsitekturnya beban. Bab ini ujian pertamanya: apakah kerangkanya sanggup menahan nol-nol itu?
Image generated with AI. ⟲
Gagasan-gagasan dalam bab ini
Section titled “Gagasan-gagasan dalam bab ini ”- Rencanakan dengan Jumlah Nol, termasuk pertumbuhan dan seluruh masa retensi, bukan volume hari ini. Satu juta induk dengan delapan anak masing-masing bukanlah masalah satu juta rekaman.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Rancang dengan bersih, lalu mundur dengan sengaja ketika volume memberi alasan, dan jangan jadikan CRM inti sebagai gudang data Anda.
- 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. ⟲
- Jauhkan pemilik bervolume tinggi dari hierarki peran, atau tempatkan dalam peran tersendiri yang stabil di puncak, dan di luar grup aturan berbagi.
- Siapa pemilik rekaman buatan mesin bergantung pada apakah kepemilikan penting untuk berbagi.
- Dalam skala besar, penataan ulang keamanan adalah operasi data: tunda perhitungan berbagi, uji coba di sandbox salinan penuh, hitung ulang sekali saja. Dan jangan pernah membuat data publik karena privat lebih lambat.
- Jika Anda tidak mengarsipkan hari ini, apakah Anda akan pernah mengarsipkan? Putuskan penghapusan sejak hari pertama, cadangkan sebelum menghapus, dan buat arsip tetap bisa ditemukan.
- Apakah data arsip tetap bisa dijangkau agen adalah keputusan bisnis.
Where volume causes problems
Section titled “Where volume causes problems”| Apa yang tumbuh | Apa yang diperlambatnya | Di mana dibahas |
|---|---|---|
| Rekaman dalam satu objek | Kueri, tampilan daftar, laporan | Modul 1; bab 8 |
| Anak di bawah satu induk, rekaman milik satu pemilik | Penguncian, penghitungan ulang berbagi | Modul 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Pengguna, peran, grup, dan aturan | Penghitungan ulang akses, penataan ulang | Modul 3 |
| Riwayat yang tidak dipakai siapa pun | Semuanya, ditambah penyimpanan dan risiko | Modul 4 |
Alur bab ini
Section titled “Alur bab ini ”Empat modul, masing-masing dapat dibaca secara mandiri.
- 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. ⟲
- 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. ⟲
- Ketika Volume Bertemu Model Berbagi. Kepemilikan sebagai tuas akses, hierarki yang stabil, perhitungan berbagi yang ditunda, penguncian granular, dan isolasi mitra dalam skala besar.
- Jika Anda Tidak Mengarsipkan Hari Ini…. Siklus hidup sejak hari pertama, cadangan sebelum penghapusan, di mana arsip tinggal, arsip tiga langkah, serta agen dan data lama.
Yang diputuskan arsitek di sini
Section titled “Yang diputuskan arsitek di sini ”- Seberapa besar setiap objek akan tumbuh, termasuk pertumbuhan dan seluruh masa retensi.
- Di mana rekaman menumpuk, dan tumpukan mana yang berbahaya.
- Apa arti kepemilikan untuk setiap objek bervolume tinggi, termasuk yang dibuat agen.
- Bagaimana model akses berskala, dan bagaimana penataan ulang besar direncanakan.
- Bagaimana data keluar: arsip, pembersihan, cadangan, dan siapa yang masih bisa menemukannya.
Di luar ujian: agen menambah nol. Mereka bisa membuat sepuluh rekaman di mana seseorang membuat satu, memiliki semuanya secara bawaan, mengambil data lebih cepat daripada siapa pun, dan menjangkau arsip kecuali seseorang memutuskan sebaliknya. Setiap modul diakhiri dengan apa yang diubah AI untuk bagian masalahnya.
Jelajahi
Section titled “Jelajahi ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (terbuka di tab baru), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (terbuka di tab baru) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (terbuka di tab baru) (Winter ‘27), checked 2026-11-01. ⟲
Berikutnya: Arsitektur Kueri dan Pengambilan Data