Bu Veri Nerede Yaşıyor?

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 4.‘sü. Her modül kendi başına okunabilir. Önceki: Kendinizinkini Oluşturun: Özel Nesneler · Sonraki: Doğru Nesneyi Seçin

Bu modülün yanıtladığı soru: bir nesne oluşturmadan önce, bu veri gerçekte nerede yaşamalı: Salesforce’ta çekirdekte mi, zaten bulunduğu yerde başvurulan olarak mı, yoksa arşivde mi?

Size bir soru sorayım. Masanıza yeni bir gereksinim geliyor. İlk ne yaparsınız?

Çoğumuz gibiyseniz Kurulum’u açar ve özel bir nesne oluşturursunuz. Anlıyorum. On dakikada bir sekmeniz, bir sayfa düzeniniz ve bir liste görünümünüz olur. Ve her derste söylediğim şey şu: o yeni nesneyi oluşturduğunuz anda, niyetiniz bu olsun ya da olmasın, zaten bir mimar gibi düşünüyorsunuz. Çünkü oluşturduğunuz her nesne bir taahhüttür. Depolama alanı kaplar. Sınırlara takılır. Siz tasarlasanız da tasarlamasanız da bir paylaşım modeli edinir. Ona dokunan herkes için bir lisans gerektirir. Ve insanlar ve entegrasyonlar ona bağımlı hale geldiğinde onu kaldırmakta bol şans.

Dolayısıyla ilk mimari karar hangi nesne olduğu değildir. Bu veri nerede yaşamalı? sorusudur. Bunu doğru yapın, nesne türü neredeyse kendiliğinden belirlenir.

Çekirdekte ve Çekirdek Dışında

Önce çok kullanacağım bir sözcük: çekirdek (core). Çekirdek, org’unuzun üzerinde çalıştığı Salesforce platformudur: 1. modüldeki meta veri odaklı, çok kiracılı platform; 2. modüldeki Satış ve Hizmet nesnelerinin ve 3. modülde inşa ettiğiniz her özel nesnenin yaşadığı yer. Bir veri çekirdekte dediğimde, org’unuzda, onun nesnelerinde saklandığını kastediyorum.

Her veri orada yaşamaz. Data 360 verisini org’unuzun nesnelerinin dışında, kendi deposunda tutar (çekirdeğe yakındır (near-core): çekirdekte yönetilir, verisi çekirdek dışında barındırılır; ayrıntılar 4. bölümde). Bir de şirketinizin çalıştırdığı ve hiç Salesforce olmayan her şey var: ERP, ambar, sipariş sistemi, iş ortağının platformu. Bunların hepsi çekirdek dışındadır. Salesforce onlara ulaşabilir, onları gösterebilir ve kullanabilir, ama org’unuz onları saklamaz.

Çekirdekte, kayıtlarınızı gerçekten tutan iki tür nesne vardır: standart ve özel (__c) sObject’ler ve büyük nesneler (__b). Çekirdek dışında ise veriye harici nesneler (__x) ve diğer entegrasyon araçları üzerinden ulaşırsınız. 3. modüldeki o sonekleri aklınızda tutun; bir verinin nerede yaşadığını yalnızca adından söylerler.

Ben bunu bir ofis gibi düşünürüm. Bazı şeyler her gün kullandığınız masanızın üzerinde durmalıdır. Bazı şeylere yalnızca başka birinin dosya dolabında bakmanız gerekir. Ve bazı şeyler arka bahçedeki kulübede kutulara girer. Bu bana üç yanıt verir.

1. Çekirdekte: Masanızda Yaşar

Veri her gün Salesforce’ta oluşturulur, değiştirilir ve kullanılır: hesaplar, vakalar, fırsatlar, iş emirleri. Onu sObject’lerde tutmak, ofisinizin ön tarafında tutmak gibidir. Standart ve özel nesneler bunun içindir ve her şeyi elde edersiniz: sayfa düzenleri, paylaşım, otomasyon, raporlama, arama ve artık veri modeli üzerine kurulu yapay zekâ özellikleri.

Ama masanız bedava değildir. Çekirdekteki veri depolamaya mal olur; Salesforce’un saydığı şekilde, sütun sütun değil kayıt kayıt sayılarak; belgeler ise ayrıca dosya depolamasından düşer. İkisini de 2. modülde ele aldık. Büyük hacimli fotoğraflar ve taramalar çoğu zaman çekirdek dışında yer almalı, Salesforce’ta yalnızca bir bağlantı kalmalıdır.

2. Başvurulan: Başka Birinin Dosya Dolabında Yaşar

Veri başka bir sisteme aittir (ERP, bir veri ambarı, bir sipariş platformu) ve o sistem gerçeğin kaynağı olarak kalır. Kullanıcıların onu Salesforce’ta görmesi, belki bir kayıtla ilişkilendirmesi gerekir, ama Salesforce’un kendi kopyasına ihtiyacı yoktur. Buna sanal veri dendiğini de duyarsınız: hiç orada saklanmadan Salesforce’ta sanal olarak görünür.

Bu, Salesforce Connect aracılığıyla harici nesnelerdir. Ben şöyle derim: ördek gibi görünür, ördek gibi yürür, ama ördek değildir. Bir sObject gibi görünür: onu sayfa düzenlerine ve ilgili listelere koyabilir, harici ve dolaylı arama ilişkileriyle kendi kayıtlarınıza bağlayabilirsiniz. Ama veri çekirdekte saklanmaz. Ona her dokunduğunuzda bir dış çağrı (callout) yapar. Bir kaydı açın, bir ilgili listeyi yükleyin, bir rapor çalıştırın; Salesforce gidip diğer sisteme sorar. Bu gecikme demektir ve sayfanız yalnızca arkasındaki sistem kadar erişilebilirdir.

İnsanlar lisans maliyetine itiraz eder; o halde hesabı benim derste yaptığım gibi yapın. Connect uç nokta başına lisanslanır ve tek bir uç nokta çok sayıda nesne getirebilir. Şimdi alternatifi inşa etmenin ve bakımını yapmanın maliyetini sorun: özel bir bileşen, arkasındaki dış çağrı kodu ve bozulduğunda nöbetçi bir geliştirici. Çoğu zaman lisans daha ucuzdur ve yöneticileriniz tek satır kod yazmadan onu yapılandırabilir. Yetersiz kaldığı yer: kullanıcılarınızın bütün gün düzenlediği ya da yoğun biçimde raporladığı veri.

Belgelere de başvurulabilir. Bir sözleşme zaten SharePoint Online, OneDrive, Google Drive ya da Box’ta yaşıyorsa, Files Connect kullanıcıların onu içeri kopyalamadan Salesforce’tan erişmesini sağlar.

Salesforce Connect veriye başvurmanın tek yolu değil. Bazen bu özel mantıktır: diğer sistemi gerçek zamanlı çağıran ve hiçbir kopya tutmadan onun verisini sayfada gösteren kod. Bu size tam kontrol verir; dış çağrının, hataların ve bakımın tam sorumluluğunu da. Ve Data 360 da kopyalamadan federasyon yapabilir. Bu seçimin kendi bölümü var (Sanallaştırma, Federasyon ve Sıfır Kopya). Burada önemli olan kararın kendisi: kopyalamayın, başvurun.

3. Arşivlenen: Arka Bahçedeki Kulübeye Gider

Geçmiş, denetim izleri, eski işlemler. Onu, bazen yıllarca saklamanız gerekir, ama neredeyse kimse açmaz. Ve ekiplerin ertelediği de budur. Bir sınıf bana 50 milyon kayıtlı bir nesneleri olduğunu söyleyip neden arşivleyeceklerini sorduğunda onlara geri sorarım: bugün arşivlemiyorsanız, hiç arşivleyecek misiniz? Bugün 50 milyondaysanız 100, 150, 200 milyona doğru gidiyorsunuz.

İki kulübe var. Biri çekirdekte: büyük nesneler. Onları veriyi garajda saklamak gibi düşünün. Çok büyük sayıda kayıt saklayabilirsiniz, ama onları bir sayfa düzenine koyamazsınız, standart arayüz ya da raporlama yoktur ve büyük nesnenin dizini üzerinden, tam eşleşmeyle ya da aralıkla sorgularsınız (Big Objects Best Practices (opens in a new tab)). Güvenlik yalnızca nesne ve alan izinleridir, kayıt paylaşımı yoktur ve otomasyon onlar üzerinde çalışmaz. Salesforce Connect’i onlarca kez kullandım, büyük nesneleri ise yalnızca bir iki kez. Çalışırlar ama kullanışsızdırlar ve veriye ulaşmak için epey geçici çözüm yazdım. Bu yüzden tavsiyem: önermeden önce prototipini yapın ve onu seçmeden önce insanların veriyi nasıl bulacağını planlayın.

Diğer kulübe çekirdek dışındadır: başka bir yerde bir ambar ya da veritabanı (Ölçek İçin Tasarlamak). Çoğu zaman bu daha iyi kulübedir ve gözden uzak olmak zorunda değildir. Çekirdek dışında arşivlenen veri Tableau gibi araçlarla raporlarda yine görünebilir ve biri geriye bakmak istediğinde Salesforce Connect ya da onu sanallaştırmanın başka bir yoluyla Salesforce’tan yine erişilebilir olabilir.

Size baştan doğru yaptığımız bir projeden bahsedeyim. Bir perakende müşterinin 1.200’den fazla noktası vardı. Bana “Bir mağazada günde yalnızca yüz randevu yapıyoruz. Önemli bir şey değil” dediler. Sonra hesabı yaptım: günde yüz, haftada altı gün (yılda yaklaşık 305 gün), 1.200 noktada, yılda 36 milyonun üzerinde randevu eder. Sonra her ziyaretin iki randevu oluşturduğunu söylediler: biri ön tezgâhta, biri de dükkânın arka tarafı için; yılda 73 milyonun üzerinde kayıt. Sonra beş yıllık geçmiş istediler: daha hiç büyüme olmadan 360 milyondan fazla kayıt. Henüz canlıya geçmemiştik ve trenin doğruca büyük veri hacmi istasyonuna gittiğini şimdiden görebiliyordum. Bu yüzden arşiv, tek bir randevu toplamadan önce inşa edildi: eski randevular büyük nesnelere taşındı ve arama ekranı güncel randevuları, arşivlenenler de hemen altında olacak şekilde gösterdi. Yıllar sonra hâlâ sorunsuz çalışıyor.

Click to enlarge

Uygulamaya Koymak: Steve Trucking

Steve Trucking süregelen senaryomuz: büyük perakendecilerin dağıtım merkezlerinden beyaz eşya ve elektronik ürünleri alıp müşterilerin evlerine teslim eden ve kuran, son kilometre teslimatı yapan bir aile şirketi. Verisinin dört türü, üç yanıt:

Veri	Nerede yaşar	Neden
Bugünün teslimatları, ekipleri ve randevuları	Çekirdekte	Sevk görevlileri ve ekipler bütün gün onunla çalışır
Perakendecinin sipariş ayrıntıları	Başvurulan (ya da çekirdekte ince bir kopya)	Gerçeğin kaynağı perakendecinin sistemidir
Üç yıl önceki teslimat geçmişi	Arşivlenen	Talepler ve eğilimler için saklanır; neredeyse kimse açmaz
Teslimat fotoğrafları	Çekirdek dışında, bağlantılı	Günde binlerce; teslimatta bir bağlantıyla Salesforce dışında saklanır

İşte aynı şey bir veri modeli olarak. Teslimat, insanların bütün gün onunla çalıştığı çekirdekte durur. Üç yıl sonra bir büyük nesne olan Teslimat Geçmişi’ne (Delivery History) taşınır: hâlâ çekirdekte, ama kulübede. İş ortağının siparişi bir harici nesne olarak, __x, görünür: Salesforce teslimatı onunla ilişkilendirir, ama veri perakendecinin sisteminde kalır. Fotoğraflar ise tamamen çekirdek dışında, teslimattan bir bağlantıyla yaşar. Tek model, üç ev.

Click to enlarge

Her gerçek org’da üçü de vardır. Başı derde girenler her şeyi çekirdeğe koyanlardır, çünkü bir nesne oluşturmak varsayılan düğmeydi.

Mimarın Burada Karar Verdikleri

• Her tür verinin evi, herhangi bir nesne tasarlanmadan önce: çekirdekte, başvurulan ya da arşivlenen.
• Gerçeğin kaynağı. Veriye başka bir sistem sahipse Salesforce sessizce ikinci bir ana kaynak haline gelmemelidir.
• Çekirdek dışındaki her şey için erişim yolu. Başvurulan veri erişilebilir bir kaynağa ve kabul edilebilir bir gecikmeye ihtiyaç duyar; arşivlenen veri ise insanların onu bulabileceği bir yola.
• Depolama büyümesi. Hesabı şimdi yapın (günlük kayıt sayısı çarpı büyüme çarpı saklama süresi), depolama uyarısı geldiğinde değil.

Sınavın ötesinde: yapay zekâ “çekirdekte” olmanın önemini artırıyor. Yapay zekâ özellikleri ve ajanlar en iyi, platformun anladığı veri üzerinde çalışır: standart ve özel nesnelerdeki, iyi adlandırılmış ve iyi tanımlanmış veri. Bu, daha fazlasını çekirdeğe koyma yönünde bir çekim yaratır. Yanlış veri için buna direnin. ERP verisinin bayat bir kopyasıyla temellendirilmiş bir ajan kendinden emin ama yanlış yanıtlar verir. Çoğu zaman daha iyi hamle canlı kaynağa başvurmak ya da çekirdekte küçük, iyi tanımlanmış bir kesit tutmaktır. Yapay zekânın veriyi nerede okuduğu artık verinin nerede yaşayacağına karar vermenin bir parçası.

Daha Fazlası

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (İngilizce, kontrol tarihi 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-09-25)
• Bu kursta: Sanallaştırma, Federasyon ve Sıfır Kopya ve Ölçek İçin Tasarlamak