Merancang untuk Skala
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)
Panduan belajar untuk bab 7 kursus Data Architect. Baca dulu empat modulnya; halaman ini membantu Anda memeriksa apa yang sudah melekat.
Tentang panduan belajar ini. Panduan ini disusun hanya dari konten kursus ini sendiri dan daftar tujuan yang tercantum dalam panduan ujian resmi Salesforce. Panduan ini tidak pernah didasarkan pada soal ujian yang sebenarnya, dan tidak mengklaim tahu apa yang keluar di ujian. Jika Anda sudah mengikuti ujiannya, mohon jangan kirimkan soal-soalnya kepada saya: perjanjian sertifikasi melarang membagikannya, dan menghafal jawaban memang cara yang salah untuk menjadi arsitek.
Bab ini membuka Bagian 2 dan bagian Large Data Volumes dalam ujian (20%), ditambah data skew dari Data Modeling. Desain kueri ada di bab berikutnya; bab ini tentang volume, titik panas, berbagi dalam skala besar, dan siklus hidup. Angka-angka platform berubah, jadi periksa angka terkini sebelum mengandalkannya.
Untuk Ujian
Section titled “Untuk Ujian ”Centang satu per satu sambil berjalan. Setiap poin bertaut ke tempat ia diajarkan.
LDV-1: model yang berskala
- Saya mengukur desain untuk pertumbuhan sepanjang masa retensi, bukan volume hari ini, dan saya mengalikan anak-anaknya. (Jangan Tanya Seberapa Besar Hari Ini, Sekarang Kalikan Anak-anaknya)
- Saya tahu volume memengaruhi lebih dari kueri: berbagi, kepemilikan, penguncian, tampilan daftar, laporan, batch, pemuatan, penghapusan, dan pemulihan. (Bukan Hanya Kueri yang Melambat)
- Saya tahu kapan denormalisasi terkendali dibenarkan oleh skala, dan berapa biayanya. (Model yang Bersih Bisa Menjadi Model yang Mahal)
- Saya tahu untuk tidak mengubah CRM operasional menjadi gudang data, dan bahwa snapshot pelaporan bukan strategi gudang data. (Jangan Jadikan CRM Inti sebagai Gudang Data Anda)
- Saya tahu volume punya bentuk: dua puluh juta rekaman yang melakukan apa? (Volume Punya Bentuk)
DM-5: data skew
- 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) ⟲
- Saya tahu perbaikan pool akun untuk induk buatan, dan untuk menyembunyikan induk pengganti dari pengguna. (Akun “Unassigned” dan Pool Akun)
- 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) ⟲
- Saya tahu skew lookup: banyak rekaman aktif yang menunjuk ke satu rekaman, dan penguncian rekaman yang bisa ditimbulkannya. (Skew Lookup)
- Saya bisa membedakan skew yang berbahaya dari yang tidak berbahaya berdasarkan aktivitasnya, bukan hanya jumlahnya. (Tidak Setiap Skew Sama Berbahayanya)
- Saya memperbaiki skew pada entitas bisnis yang nyata dengan pemisahan yang bermakna (akun anak per pusat distribusi), tidak pernah dengan salinan palsunya. (Steve Trucking: Di Mana Titik Panasnya?)
DM-2: berbagi dalam skala besar
- Saya tahu struktur akses (pemilik, peran, grup, berbagi) juga data, dan ikut berskala. (Berbagi Juga Data)
- 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) ⟲ - Saya tahu perubahan hierarki peran pada volume besar adalah operasi data, jadi stabilitas adalah fitur desain. (Hierarki Peran Bukan Bagan Organisasi)
- 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) ⟲
- Saya tahu kinerja bukan alasan untuk menjadikan publik data yang seharusnya privat. (Jangan Mengorbankan Keamanan demi Optimasi)
LDV-2: pengarsipan dan pembersihan
- Saya bisa memisahkan retensi, pengarsipan, dan pembersihan, dan menetapkannya di awal proyek. (Penghapusan Tak Terhindarkan)
- Saya memasang cadangan sebelum apa pun dihapus, dan tahu cadangan dan arsip adalah kemampuan yang berbeda (Salesforce Backup & Recover, Archive). (Cadangkan Sebelum Menghapus)
- 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) ⟲
- Saya tahu arsip tiga langkah (salin dan tandai, verifikasi, hapus dan balik status), dan bahwa ia harus bisa dimulai ulang. (Arsip Tiga Langkah)
- Saya tahu data arsip harus tetap bisa ditemukan dan menjaga keamanannya. (Arsip yang Tidak Bisa Ditemukan Siapa Pun Hampir Sama dengan Penghapusan, Arsip Tetap Harus Aman)
Di Luar Ujian
Section titled “Di Luar Ujian ”Ujian adalah batas bawah, bukan batas atas. Inilah kebiasaan dari bab ini yang dibutuhkan seorang arsitek, entah ada pertanyaan ujian tentangnya atau tidak.
- 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. ⟲
- Kadang perbaikan terbaik adalah tidak menciptakan masalahnya: jauhkan GPS, foto, dan riwayat status dari core.
- Angkanya memberi tahu saya ke mana harus melihat; perilakunya memberi tahu seberapa khawatir saya harus.
- Pada skala ini, perubahan organisasi menjadi operasi data.
- Perbaikan skala tetap harus menjaga makna.
- Temukan titik panas di diagram: lihat panah-panahnya dan tanyakan berapa banyak rekaman yang menumpuk di setiap sisi.
- Uji Jumlah Nol yang benar-benar Anda rancang.
- AI akan menambah lebih banyak nol. Modelkan volume yang dihasilkan agen secara eksplisit.
- 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?) ⟲
- Jika Anda tidak mengarsipkan hari ini, apakah Anda akan pernah mengarsipkan?
- Rancang pintu keluar ketika Anda merancang pintu masuk. Lima jawaban per objek: kapan berhenti aktif, ke mana pergi, bagaimana kita membuktikannya, bagaimana seseorang menemukannya, kapan dihapus.
- Apakah agen bisa menjangkau data arsip adalah keputusan bisnis.
Istilah Penting
Section titled “Istilah Penting ”| Istilah | Dalam satu baris |
|---|---|
| Volume data besar (LDV) | Rekaman yang cukup banyak sehingga perilaku platform, bukan hanya jumlahnya, membentuk desain |
| Data skew | Terlalu banyak rekaman yang terpusat pada satu induk, pemilik, atau nilai lookup |
| Skew induk-anak | Terlalu banyak anak di bawah satu rekaman induk |
| Skew kepemilikan | Satu pengguna memiliki lebih dari sekitar 10.000 rekaman sebuah objek |
| Skew lookup | Banyak rekaman aktif mereferensikan satu rekaman, sehingga terjadi perebutan kunci |
| Pool akun | Beberapa induk pengganti yang berbagi anak-anak dari satu induk buatan |
| 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 |
| Penghitungan ulang berbagi | Platform menghitung ulang akses setelah perubahan pada pemilik, peran, grup, atau aturan |
| Perhitungan berbagi yang ditunda | Menahan penghitungan ulang sampai sekumpulan perubahan selesai, lalu menjalankannya sekali |
| Penguncian granular | Hanya mengunci bagian tabel keanggotaan grup yang dibutuhkan sebuah operasi |
| Retensi | Berapa lama data disimpan, dan mengapa |
| Pengarsipan | Memindahkan data keluar dari beban kerja aktif sambil mempertahankan akses yang dibutuhkan bisnis |
| Pembersihan | Menghapus data secara permanen di akhir masa retensinya |
| Arsip tiga langkah | Salin dan tandai, verifikasi, lalu hapus dan balik status |
Uji Diri
Section titled “Uji Diri ”Skenario singkat dengan gaya kursus ini. Tentukan jawaban Anda sebelum membukanya.
1. Sebuah perusahaan melakukan satu juta pengiriman setahun, tumbuh 30 persen, dan menyimpan lima tahun. Volume berapa yang Anda rancang?
Sekitar 9 juta pengiriman yang disimpan selama lima tahun, bukan satu juta, lalu anak-anaknya: sekitar 14,5 juta item baris dengan 1,6 per pengiriman, dan 72 juta event status dengan delapan per pengiriman. Baca lagi Jangan Tanya Seberapa Besar Hari Ini.
2. 300.000 kontak berada di bawah satu akun bernama "Unassigned Contacts". Apa yang Anda lakukan?
Itu skew induk-anak buatan. Sebar kontaknya ke pool akun berisi induk pengganti, masing-masing di bawah ambang, dan sembunyikan induk pengganti itu dari tampilan bisnis normal. Atau tanyakan apakah kontak-kontak itu memang butuh akun. Baca lagi Akun “Unassigned” dan Pool Akun.
3. Satu Mitra Ritel akan memiliki 3,6 juta perintah kerja. Seseorang mengusulkan akun Redrock 001, 002, dan 003. Pendapat Anda?
Tidak: itu merusak entitas bisnis yang nyata. Cari pemisahan yang dikenali bisnis, seperti akun anak per pusat distribusi, dan arsipkan pengiriman yang selesai agar anak aktifnya tetap rendah. Baca lagi Steve Trucking: Di Mana Titik Panasnya?.
4. Seorang pengguna integrasi memiliki 2 juta rekaman dan berada di peran regional yang akan dipindahkan dalam reorganisasi. Apa risikonya, dan perbaikannya?
Memindahkannya memaksa penghitungan ulang akses di 2 juta rekaman. Jangan beri pemilik bervolume tinggi peran, atau beri peran tersendiri yang stabil di puncak, jauhkan dari grup aturan berbagi, dan putuskan apakah kepemilikan memang harus menggerakkan akses untuk rekaman ini. Baca lagi Skew Kepemilikan.
5. Sebuah reorganisasi akan mengubah ratusan peran, grup, dan aturan berbagi dalam satu akhir pekan. Bagaimana Anda menjalankannya?
Sebagai operasi data: uji pada volume nyata di sandbox salinan penuh, tunda perhitungan berbagi, lakukan semua perubahan, hitung ulang sekali dalam jendela pemeliharaan yang disepakati, lalu verifikasi, dengan rencana cadangan. Baca lagi Penghitungan Ulang Berbagi Adalah Pekerjaan Nyata.
6. Tim berencana mengarsipkan 20 juta rekaman dengan satu job yang menyalin sekaligus menghapus. Apa yang akan Anda ubah?
Tiga langkah: salin dan tandai sebagai menunggu, verifikasi arsipnya (jumlah, pengenal, hubungan, pengambilan), lalu hapus dan balik status, dengan status-status agar kegagalan di rekaman ke-14 juta bisa dimulai ulang dengan aman. Dan cadangan sebelum apa pun dihapus. Baca lagi Arsip Tiga Langkah.
7. Pelanggan tidak ingin data disimpan di luar Salesforce, tetapi perlu menyimpan riwayat janji temu bertahun-tahun. Di mana arsipnya bisa tinggal?
Di dalam platform: big object, atau Archive dari Salesforce. Dengan big object, rencanakan jalur aksesnya dulu: tanpa UI atau pelaporan standar, dikueri lewat indeks. Dan buat tetap bisa ditemukan, misalnya dengan menampilkan janji temu yang diarsipkan di bawah yang aktif. Baca lagi Di Mana Arsip Sebaiknya Tinggal?.
Jelajahi
Section titled “Jelajahi ”- Salesforce Certified Platform Data Architect Exam Guide (terbuka di tab baru), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Bagian Jelajahi di setiap modul mencantumkan dokumentasi Salesforce di balik fakta-faktanya.