Ölçek İçin Tasarlamak
19 dilde daha mevcut
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect kursunun 7. bölümünün çalışma rehberi. Önce dört modülü okuyun; bu sayfa aklınızda neyin kaldığını kontrol etmenize yardım eder.
Bu çalışma rehberi hakkında. Yalnızca bu kursun kendi içeriğinden ve Salesforce’un yayımladığı sınav rehberindeki hedefler listesinden hazırlanmıştır. Hiçbir zaman gerçek sınav sorularına dayanmaz ve sınavda ne olduğunu bildiğini iddia etmez. Sınava girdiyseniz lütfen bana sınavdan soru göndermeyin: sertifika sözleşmesi bunları paylaşmayı yasaklar ve zaten yanıt ezberlemek mimar olmanın yanlış yoludur.
Bu bölüm 2. Kısım’ı ve sınavın Büyük Veri Hacimleri kısmını (%20) açar, Veri Modelleme’den veri çarpıklığıyla birlikte. Sorgu tasarımı bir sonraki bölümde; bu bölüm hacim, sıcak noktalar, ölçekte paylaşım ve yaşam döngüsü hakkında. Platform rakamları değişir, bu yüzden onlara güvenmeden önce güncel olanları kontrol edin.
Sınav İçin
Bölüm başlığı “Sınav İçin ”İlerledikçe işaretleyin. Her madde öğretildiği yere bağlanır.
LDV-1: ölçeklenen bir model
- Bir tasarımı bugünkü hacme göre değil, saklama süresi boyunca büyümeye göre boyutlandırırım ve alt kayıtları da çarparım. (Bugün Ne Kadar Büyük Olduğunu Sormayın, Şimdi Alt Kayıtları Çarpın)
- Hacmin sorgulardan fazlasını etkilediğini bilirim: paylaşım, sahiplik, kilitleme, liste görünümleri, raporlar, toplu işler, yüklemeler, silmeler ve kurtarma. (Yavaşlayan Yalnızca Sorgular Değil)
- Kontrollü denormalizasyonun ölçekle ne zaman haklı çıktığını ve maliyetini bilirim. (Temiz Modeller Pahalı Modellere Dönüşebilir)
- Operasyonel CRM’i bir veri ambarına dönüştürmemeyi ve raporlama anlık görüntülerinin bir veri ambarı stratejisi olmadığını bilirim. (Çekirdek CRM’i Veri Ambarınıza Dönüştürmeyin)
- Hacmin bir biçimi olduğunu bilirim: ne yapan yirmi milyon kayıt? (Hacmin Bir Biçimi Vardır)
DM-5: veri çarpıklığı
- 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) ⟲
- Yapay bir üst kayıt için hesap havuzu düzeltmesini ve yer tutucu üst kayıtları kullanıcılardan gizlemeyi bilirim. (“Atanmamış” Hesap ve Hesap Havuzları)
- 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) ⟲
- Arama çarpıklığını bilirim: tek bir kayda işaret eden çok sayıda aktif kayıt ve bunun yol açabileceği kayıt kilitleme. (Arama Çarpıklığı)
- Tehlikeli bir çarpıklığı zararsız olandan yalnızca sayısıyla değil, etkinliğiyle ayırt edebilirim. (Her Çarpıklık Aynı Derecede Tehlikeli Değildir)
- Gerçek bir iş varlığındaki çarpıklığı anlamlı bir bölmeyle (dağıtım merkezi başına bir alt hesap) düzeltirim, asla sahte kopyalarıyla değil. (Steve Trucking: Sıcak Noktalar Nerede?)
DM-2: ölçekte paylaşım
- Erişim yapılarının (sahipler, roller, gruplar, paylaşımlar) da veri olduğunu ve ölçeklendiğini bilirim. (Paylaşım da Veridir)
- 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) ⟲ - Hacimde bir rol hiyerarşisi değişikliğinin bir veri operasyonu olduğunu, bu yüzden istikrarın bir tasarım özelliği olduğunu bilirim. (Rol Hiyerarşisi Bir Organizasyon Şeması Değildir)
- 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) ⟲
- Performansın, özel olması gereken veriyi herkese açık yapmanın bahanesi olmadığını bilirim. (Güvenliği Optimizasyona Kurban Etmeyin)
LDV-2: arşivleme ve temizleme
- Saklama, arşivleme ve temizlemeyi ayrı tutabilir ve bunları projenin başında belirleyebilirim. (Silme Kaçınılmazdır)
- Hiçbir şey silinmeden önce yedekleri devreye alırım ve yedekleme ile arşivin farklı yetenekler olduğunu bilirim (Salesforce Backup & Recover, Archive). (Silmeden Önce Yedekleyin)
- 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) ⟲
- Üç adımlı arşivi (kopyala ve işaretle, doğrula, sil ve durumu çevir) ve yeniden başlatılabilir olması gerektiğini bilirim. (Üç Adımlı Arşiv)
- Arşivlenmiş verinin bulunabilir kalması ve güvenliğini koruması gerektiğini bilirim. (Kimsenin Bulamadığı Bir Arşiv Neredeyse Bir Silmedir, Arşiv Yine de Güvenli Olmalıdır)
Sınavın Ötesinde
Bölüm başlığı “Sınavın Ötesinde ”Sınav taban, tavan değil. Bunlar bu bölümden, bir soru onları hiç sorsun ya da sormasın, bir mimarın ihtiyaç duyduğu alışkanlıklardır.
- 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. ⟲
- Bazen en iyi düzeltme sorunu yaratmamaktır: GPS’i, fotoğrafları ve durum geçmişini çekirdeğin dışında tutun.
- Sayı bana nereye bakacağımı söyler; davranış ne kadar endişelenmem gerektiğini söyler.
- Bu ölçekte organizasyonel değişiklikler veri operasyonlarına dönüşür.
- Ölçek düzeltmeleri yine de anlamı korumalıdır.
- Diyagramdaki sıcak noktaları bulun: oklara bakın ve her tarafta kaç kaydın biriktiğini sorun.
- Gerçekten tasarladığınız Sıfır Sayısı’nı test edin.
- Yapay zekâ daha fazla sıfır ekleyecek. Ajanların ürettiği hacmi açıkça modelleyin.
- 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?) ⟲
- Bugün arşivlemiyorsanız, hiç arşivleyecek misiniz?
- Girişi tasarlarken çıkışı da tasarlayın. Nesne başına beş yanıt: ne zaman aktif olmayı bırakır, nereye gider, bunu nasıl kanıtlarız, biri onu nasıl bulur, ne zaman silinir.
- Ajanların arşivlenmiş veriye ulaşıp ulaşamayacağı işin kararıdır.
Bilinmesi Gereken Terimler
Bölüm başlığı “Bilinmesi Gereken Terimler ”| Terim | Tek satırda |
|---|---|
| Büyük veri hacmi (LDV) | Yalnızca sayının değil, platformun davranışının da tasarımı şekillendirdiği kadar çok kayıt |
| Veri çarpıklığı | Tek bir üst kayıtta, sahipte veya arama değerinde yoğunlaşan çok fazla kayıt |
| Üst-alt çarpıklığı | Tek bir üst kaydın altında çok fazla alt kayıt |
| Sahiplik çarpıklığı | Bir kullanıcının bir nesnenin yaklaşık 10.000’den fazla kaydına sahip olması |
| Arama çarpıklığı | Tek bir kayda başvuran çok sayıda aktif kayıt; kilit çekişmesine yol açar |
| Hesap havuzu | Yapay bir üst kaydın alt kayıtlarını paylaşan birkaç yer tutucu üst kayıt |
| 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 |
| Paylaşımın yeniden hesaplanması | Sahiplerde, rollerde, gruplarda veya kurallarda bir değişiklikten sonra platformun erişimi yeniden hesaplaması |
| Ertelenmiş paylaşım hesaplaması | Yeniden hesaplamayı bir dizi değişiklik bitene kadar bekletip sonra bir kez çalıştırmak |
| Ayrıntılı kilitleme | Grup üyeliği tablolarının yalnızca bir işlemin ihtiyaç duyduğu kısımlarını kilitlemek |
| Saklama | Verinin ne kadar süre ve neden tutulduğu |
| Arşivleme | Verinin işin ihtiyaç duyduğu erişim korunarak aktif iş yükünden çıkarılması |
| Temizleme | Verinin saklama süresinin sonunda kalıcı olarak kaldırılması |
| Üç adımlı arşiv | Kopyala ve işaretle, doğrula, sonra sil ve durumu çevir |
Kendinizi Sınayın
Bölüm başlığı “Kendinizi Sınayın ”Kursun tarzında kısa senaryolar. Açmadan önce yanıtınıza karar verin.
1. Bir şirket yılda bir milyon teslimat yapıyor, yüzde 30 büyüyor ve beş yıl saklıyor. Hangi hacim için tasarlarsınız?
Beş yıl boyunca saklanan yaklaşık 9 milyon teslimat için, bir milyon için değil; sonra da alt kayıtları için: teslimat başına 1,6 ile yaklaşık 14,5 milyon satır kalemi ve teslimat başına sekiz ile 72 milyon durum olayı. Bugün Ne Kadar Büyük Olduğunu Sormayın bölümünü yeniden okuyun.
2. "Unassigned Contacts" adlı tek bir hesabın altında 300.000 ilgili kişi var. Ne yaparsınız?
Bu yapay bir üst-alt çarpıklığıdır. İlgili kişileri, her biri eşiğin altında kalan yer tutucu üst kayıtlardan oluşan bir hesap havuzuna dağıtın ve bu yer tutucuları normal iş görünümlerinden gizleyin. Ya da ilgili kişilerin bir hesaba ihtiyacı olup olmadığını sorun. “Atanmamış” Hesap ve Hesap Havuzları bölümünü yeniden okuyun.
3. Bir Perakende Ortağı'nın 3,6 milyon iş emri olacak. Biri Redrock 001, 002 ve 003 hesaplarını öneriyor. Görüşünüz?
Hayır: bu gerçek bir iş varlığını bozar. İşin tanıyacağı bir bölme arayın, örneğin dağıtım merkezi başına bir alt hesap, ve aktif alt kayıtları düşük tutmak için tamamlanan teslimatları arşivleyin. Steve Trucking: Sıcak Noktalar Nerede? bölümünü yeniden okuyun.
4. Bir entegrasyon kullanıcısı 2 milyon kaydın sahibi ve bir yeniden yapılanmada taşınmak üzere olan bölgesel bir rolde. Risk nedir, düzeltme nedir?
Onu taşımak 2 milyon kayıtta erişimin yeniden hesaplanmasını zorlar. Yüksek hacimli sahiplere rol vermeyin ya da en üstte ayrı, sabit bir rol verin, onları paylaşım kuralı gruplarının dışında tutun ve bu kayıtlar için sahipliğin erişimi yönlendirmesi gerekip gerekmediğine karar verin. Sahiplik Çarpıklığı bölümünü yeniden okuyun.
5. Bir yeniden yapılanma, bir hafta sonunda yüzlerce rolü, grubu ve paylaşım kuralını değiştirecek. Bunu nasıl yürütürsünüz?
Bir veri operasyonu olarak: tam kopya sandbox’ta gerçek hacimde test edin, paylaşım hesaplamalarını erteleyin, tüm değişiklikleri yapın, üzerinde anlaşılan bir bakım penceresinde bir kez yeniden hesaplayın, sonra bir geri dönüş planıyla doğrulayın. Paylaşımın Yeniden Hesaplanması Gerçek Bir İştir bölümünü yeniden okuyun.
6. Ekip 20 milyon kaydı hem kopyalayan hem silen tek bir işle arşivlemeyi planlıyor. Neyi değiştirirsiniz?
Üç adım: kopyala ve bekliyor olarak işaretle, arşivi doğrula (sayılar, tanımlayıcılar, ilişkiler, getirme), sonra sil ve durumu çevir; 14 milyonuncu kayıtta bir hatanın güvenle yeniden başlayabilmesi için durumlarla. Ve hiçbir şey silinmeden önce bir yedek. Üç Adımlı Arşiv bölümünü yeniden okuyun.
7. Müşteri verinin Salesforce dışında saklanmasını istemiyor, ama yıllarca randevu geçmişini saklaması gerekiyor. Arşiv nerede durabilir?
Platform üzerinde: big object ya da Salesforce’un Archive’ı. Big object ile önce erişim yolunu planlayın: standart arayüz veya raporlama yok, dizin üzerinden sorgulanır. Ve bulunabilir tutun, örneğin arşivlenmiş randevuları canlı olanların altında göstererek. Arşiv Nerede Durmalı? bölümünü yeniden okuyun.
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Salesforce Certified Platform Data Architect Exam Guide (yeni sekmede açılır), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Her modülün kendi Daha Fazlası kısmı, olgularının arkasındaki Salesforce belgelerini listeler.