Bugün Arşivlemiyorsanız…

🌐 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)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku Bu bölüm İngilizcede değişti ve henüz yeniden çevrilmedi. (42)

Data Architect kursunun 7. bölümü olan Ölçek İçin Tasarlamak bölümündeki 4 modülden 4.‘sü. Her modül kendi başına okunabilir. Önceki: Hacim Paylaşım Modeliyle Buluştuğunda · Sonraki: bir sonraki bölüm, Sorgulama ve Getirme Mimarisi

Bu modülün yanıtladığı soru: Arşivlemeyi ve temizlemeyi nasıl planlarsınız?

When somebody tells me “we’ll archive the old records later,” I ask one question: if you’re not archiving today, are you ever going to archive? “Later” often becomes after the next release, after the migration, after the reorganization, after we fix performance, after we run out of storage. Then five years on, someone finally asks why there are 80 million records in this object. I don’t want to discover archiving after large data volume has become the problem. If I know the data will grow, I decide its lifecycle when I design it. Salesforce’s own guide says the same: “if your volume of data is increasing, performance can degrade as time goes by. A policy of archiving or discarding data at the same rate at which it comes into the system can prevent this effect” (Best Practices for Deployments with Large Data Volumes (yeni sekmede açılır), Winter ‘27). ⟲

Her Kaydın Bir Yaşam Döngüsü Vardır

Bir kaydın nasıl oluşturulduğunu, sahibinin kim olduğunu, onu kimin değiştirebileceğini, neyin esas olduğunu sorduk. Şimdi bir tane daha: nasıl çıkıyor? Bir kayıt aktiften pasife, arşivlenmişe ve temizlenmişe geçebilir. Her kaydın her aşamaya ihtiyacı yoktur, ama her yüksek hacimli nesnenin bir yaşam döngüsüne ihtiyacı vardır. Bir Steve Trucking teslimatı canlıyken sürekli gereklidir: ekip, koordinatör, müşteri hizmetleri, ortak, otomasyon. Bittikten bir hafta sonra hâlâ yararlıdır. Altı ay sonra çoğunlukla hizmet geçmişidir. Üç yıl sonra çoğunlukla analitik, denetim ya da ara sıra bir anlaşmazlık için. On yıl sonra belki kimsenin onu saklamak için meşru bir nedeni yoktur. Verinin değeri zamanla değişir; mimari de onunla birlikte değişmelidir.

Silme Kaçınılmazdır, O Yüzden İlk Gün Karar Verin

Bir gün veriyi gerçekten silmeniz gerekecek. Bu yüzden saklama ve temizleme politikalarının depolama pahalılaştığında değil, projenin başında belirlenmesini isterim. Saklama, iş ve mevzuat gereksinimleriyle yönlendirilir: ne kadar süre operasyonel kalmalı, ne kadar süre saklamak zorundayız, neden, kimin ihtiyacı olabilir, ne kadar hızlı ulaşmaları gerekir, sonunda gidebilir mi ve gizlilik daha erken gitmesini gerektiriyor mu? 5. bölüm her şeyi sonsuza kadar saklamanın otomatik olarak daha güvenli olmadığını gösterdi; bazen veriyi daha uzun saklamak riskin ta kendisidir.

Üç kararı ayrı tutun. Saklama: onu ne kadar süre tutuyoruz? Arşivleme: artık aktif iş yüküne ait olmayanı nerede ve nasıl tutuyoruz? Temizleme: ne zaman ve nasıl kalıcı olarak kaldırılıyor? Yedi yıllık veriye ihtiyaç duymak yedi yıl aktif kalmak anlamına gelmez. Belki on sekiz ay aktif, sonra sürenin geri kalanında arşivde, sonra temizleniyor. Artık yaşam döngüsü açıktır.

Purging at volume has its own mechanics, and Salesforce spells them out. Deleting a record doesn’t remove it at once: it goes to the Recycle Bin for 15 days, and while it’s there it “still affects database performance because the data is still resident, and deleted records have to be excluded from any queries.” For a purge of a million records or more, Salesforce’s advice is the hard delete option of Bulk API 2.0, which skips the Recycle Bin, and when records have many children, to delete the children first (Deleting Data (yeni sekmede açılır); Best Practices: Deleting Data (yeni sekmede açılır)). A purge is a data operation like any other at scale: plan it, run it in batches, and check it. ⟲

Test knowledge. 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, use Bulk API 2.0 hard delete; delete children before parents. ⟲

Büyütmek için tıklayın

Retain for seven years doesn’t mean keep active for seven years. ⟲

Silmeden Önce Yedekleyin

Arşivleme sonunda kayıtları aktif sistemden kaldırmak demektir, bu yüzden silmeyi tasarlamadan önce kurtarma hikâyesini isterim: kurtarabilir miyiz, ne kadar hızlı, tam olarak neyin gittiğini biliyor muyuz, ilişkileri geri yükleyebilir miyiz, test ettik mi? Hiçbir şey silinmeden önce yedekler devreye girer. Yedekleme ve arşiv farklı yeteneklerdir: yedekleme kayba karşı korur; arşiv veriyi bilinçli olarak aktif kitleden çıkarırken işin hâlâ ihtiyaç duyduğu erişimi korur. Yanlışlıkla on kayıt silmek can sıkıcıdır. On milyon silmek bir olaydır. Sıfır Sayısı hatalar için de geçerlidir.

Artık ikisi de Salesforce’un kendisinden geliyor. OwnBackup’ın arkasındaki şirket Own, Salesforce Platform’un bir parçası: Own Recover artık Salesforce Backup & Recover (veri ve meta verinin günlük ve isteğe bağlı yedekleri, alan, kayıt veya nesne düzeyinde geri yükleme, belirli bir zamana dönme) ve Archive seyrek kullanılan veriyi arşivleme ve saklama politikaları altında düşük maliyetli depolamaya taşırken Salesforce içinden erişilebilir tutar (Own From Salesforce Product Suite FAQ (yeni sekmede açılır); Own’s tools, now part of Salesforce (yeni sekmede açılır)).

Kimsenin Bulamadığı Bir Arşiv Neredeyse Bir Silmedir

Bir ekip eski veriyi daha ucuz bir yere taşır. Arşiv tamam. Sonra bir müşteri arar: “Dört yıl önce bir teslimatım vardı ve teslimat kanıtına ihtiyacım var.” Temsilci Salesforce’ta arar: hiçbir şey. Şimdi başka bir sisteme, doğru tabloya, bir tanımlayıcıya, bir yöneticiye, bir talebe ve iki güne ihtiyaçları var. Bu pek bir arşiv sayılmaz. Arşivlenmiş verinin aktif veri gibi davranması gerekmez. Daha yavaş, salt okunur olabilir, farklı bir bileşende gösterilebilir. Ama arşivlenmiş veri, işin gerektirdiği şekilde bulunabilir kalmalıdır.

I’ve seen this done well at a service chain. At the very beginning of the project they told me, “We only do a hundred appointments a day at a store.” A hundred, no big deal. But they had a thousand stores, open six days a week. Do the quick math: that’s about 31 million appointments a year. Then they created two appointment records for every visit, one at the front office and one at the back, so 62 million. And they needed five years: over 300 million records. I could see large data volume coming before we’d even gone live. So right from the beginning we said: there has to be archiving before we collect a single appointment. We put the archive in big objects and built it in from the ground up. When a user searched a customer, the live appointments came first, and below them, the archived ones. The archive didn’t pretend to be active data, and nobody had to become a database administrator to find history. Active data where the operational system needs it; archived data somewhere suited to its volume; a path from the business context to both. Much better than either extreme: everything active forever, or moved somewhere nobody can find. ⟲

Arşiv Nerede Durmalı?

Keeping data in core is like keeping it at the front of the office, where it’s in the way of today’s work. Somewhere in the future of any object with tens of millions of records there’s a move to the back: a box in an archive, the shed (big objects), or a hologram (virtualization, the data shown in Salesforce but living elsewhere). There’s no single answer; I choose the destination by constraint. When the customer doesn’t want an external store, I’ve used big objects: on-platform, built for very large volumes, but with no standard UI or reporting, Apex-only access and querying through the index, so plan the access path before you choose them (chapter 3’s “shed out back”). Plan the storage too: most editions are allocated storage for 1 million big object records per org, and more has to be arranged with Salesforce (Data and File Storage Allocations (yeni sekmede açılır)). Two more facts matter for an archive. Big objects support only object and field permissions, not sharing rules, and triggers and flows don’t run on them. And inserting an identical record twice creates only one, so writes can be idempotent, which helps when an archive run has to restart (Big Objects (yeni sekmede açılır)). ⟲

Büyütmek için tıklayın

A big object: the archive stays inside Salesforce, and you build the window users see it through. ⟲

When an external store is fine, I’ve used an off-platform database surfaced through Salesforce Connect, so archived records appear in Salesforce without being copied back. Precisely: Salesforce Connect reaches external data through OData services, other Salesforce orgs, a custom adapter built with the Apex Connector Framework, or specific adapters for Amazon DynamoDB, GraphQL and SQL (the SQL adapter supports Snowflake and Amazon Athena), so a general database usually needs an OData layer or a custom adapter in front of it (Choose Which Salesforce Connect Adapter to Use (yeni sekmede açılır)). ⟲

Büyütmek için tıklayın

An external store: the archive leaves Salesforce, and Salesforce Connect brings it back into view. ⟲

The archive doesn’t have to be a database. It can be files in low-cost file storage, such as Amazon S3, and Salesforce Connect’s SQL adapter for Amazon Athena lets users “analyze data directly in Amazon Simple Storage Service (Amazon S3)” from Salesforce. One catch for an archive: that adapter is available “not for high-data-volume external objects,” so check what your volume needs before you choose it (Salesforce Connect SQL Adapter for Amazon Athena (yeni sekmede açılır)). ⟲

Büyütmek için tıklayın

File storage: the same move, with files in place of a database. ⟲

And now Salesforce’s Archive is the built-in option, keeping archived records reachable from Salesforce. Third-party tools such as GRAX are in the market too. ⟲

Test knowledge. Know the archive destinations and 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. Know the alternatives: an external store through Salesforce Connect, and Salesforce’s Archive. ⟲

Ders ürün değil. Ders özelliklerdir: ne kadar veri, ne sıklıkla getiriliyor, ne kadar hızlı görünmeli, ilişkisel erişim gerekiyor mu, kullanıcılar onu Salesforce’tan bulmalı mı, salt okunur olabilir mi, kimler görebilir, ne kadar saklanır, maliyeti ne ve sonunda nasıl temizlenecek. Bu yanıtlar teknolojiyi seçer. Ve unutmayın: verinin fiziksel olarak nerede durduğu ile bir kullanıcının onu nerede keşfedebildiği farklı sorulardır. Beş yıllık teslimat aktif nesneye ait değildir. Bu, temsilcinin onu bulamaması gerektiği anlamına gelmez.

Üç Adımlı Arşiv

When I’m moving large volumes out of an operational system, I don’t like copy, then delete in one step. There’s too much trust in it. And before the first real run, I rehearse it: a dry run that shows which records would move, ideally in a full copy sandbox, deleting nothing. Salesforce’s Archive app lets you preview an archive policy before you publish it (Archive App (yeni sekmede açılır)), and other archiving tools offer a dry-run mode for the same reason. Then I use three steps: ⟲

1. Copy and flag. Copy the records to the archive and mark them in the source as pending archive. Don’t delete anything yet. Now both copies exist. On the service chain, this was a batch that ran on the weekend. ⟲
2. Verify. Re-query the source and the archive and prove the archive is right: counts, identifiers, relationships, totals or other reconciliation; can we retrieve them? For extra assurance, add checksums, or restore a sample back and compare it. Then flag them as validated. Trust but verify. Users still find the records in the source, because they aren’t archived yet. ⟲
3. Delete and flip. Only after verification, and only for records that aren’t under a legal hold, delete the active records and mark the archive complete, so the search screens now pull them from the archive. The deletion doesn’t have to follow at once; it could happen a week later. ⟲

What could go wrong with one pass, copy and delete? It didn’t copy, and you’ve deleted the records. The point is that you don’t cross the destructive boundary until you’ve proved the copy. And with the states, you can report on every archive run. ⟲

This isn’t just my habit; it’s how the serious archiving tools work. Oracle’s archive and purge, for example, validates the records, copies them to archive tables, and then purges from what it archived, with a restart program for when a run fails partway (Archive and Purge (yeni sekmede açılır)). Tools that copy and delete in a single pass come with a warning to test with a dry run first (AWS Prescriptive Guidance: Archiving data from unpartitioned tables (yeni sekmede açılır)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

Büyütmek için tıklayın

Don’t cross the destructive boundary until you’ve proved the copy. ⟲

Ve yeniden başlatılabilir tasarlayın. 20 milyon kaydı arşivlerken iş 14.382.711. kayıtta başarısız oluyor. Yanıt “baştan başla” ise tasarımı sevmem. Büyük işlemler başarısız olur: bağlantılar kopar, işler zaman aşımına uğrar, tuhaf bir kayıt hata fırlatır. Süreç neyin zaten başarılı olduğunu bilmelidir; arşiv durumları (bekliyor, doğrulandı, arşivlendi, başarısız) bunun içindir; böylece veriyi çoğaltmadan, kaybetmeden ya da güvenle arşivlenmemiş bir şeyi silmeden yeniden başlayabilir. Ölçekte yeniden başlatılabilirlik güvenilirliğin bir parçasıdır.

One more thing to know before you call a purge done: deleting the active records isn’t the same as erasing the data. Backups, caches, replicas and analytics copies may still hold it. That’s fine for an archive, and it’s exactly what chapter 5 asks you to account for when privacy law says the data must go. ⟲

Don’t Archive Everything Forever

Arşivleme, silmeye karar vermekten kaçınmanın bahanesine dönüşebilir. “Bir gün lazım olabilir.” Belki olmaz. 5. bölüm onu saklamamıza izin var mı? diye sorar. Bu bölüm ekler: onu aktif tutmanın bir değeri var mı? Bazı kayıtlar arşive gider; bazıları özetlenir, bazıları anonimleştirilir, bazıları silinir. Amaç her baytı korumak değil. Amaç, işin meşru olarak ihtiyaç duyduğunu, meşru olarak ihtiyaç duyduğu süre boyunca tutmaktır.

Dosyalar Sıfır Sayısı’nı Değiştirir

Unstructured data is a different scale problem. Steve Trucking expects four to five million photos a year. Purely for magnitude, at about 4 MB a photo, five million is about 20 TB in one year, before growth. The real size will vary; the zeros tell you the binary content needs its own architecture. That’s why Checkpoint 1 separated the business record about a photo from the photo itself. Salesforce may need the photo’s type, its delivery, when and by whom it was taken, where it’s stored and its retention state, or even just a count and a “required photos complete” flag. The image belongs in storage built for millions of large objects. It’s the same principle as FleetLink’s GPS: keep in core what the operational process needs, and don’t copy every high-volume artifact into core because Salesforce takes part in the process. ⟲

Arşiv Yine de Güvenli Olmalıdır

Data leaving the active object doesn’t leave its security requirements behind. Redrock saw only Redrock’s deliveries while they were active; archive them, and Redrock still doesn’t get Keystone’s history. The archive needs an authorization model too, for Recipient personal data, photos, financial data, service history and agent access. A big-object archive doesn’t help on its own here: big objects don’t support sharing rules, so the access path you build has to carry the partner boundary. One design question for every archive: how do the original security requirements survive the move? The implementation may change; the requirement doesn’t. ⟲

Ajanlar ve Arşivlenmiş Veri

Bir Alıcı bir ajana soruyor: “Dört yıl önce buzdolabım nereye teslim edildi?” Yanıt var, ama arşivlenmiş. Ajan ona ulaşabilmeli mi? Görüşüm: bu önemli bir karardır ve işe aittir. Mimar seçenekleri ve her birinin maliyetini ortaya koyar: hangi arşiv, ajan ona nasıl ulaşır, gecikme, tüketim, ajanın eski veri hakkında ne söyleyebileceği ve saklama ile gizlilik sınırları. Sonra iş karar verir. Arşivlenmiş veri erişilebilir kalmalıysa, yetkilendirilmiş bir getirme yolu kurun. Kalmamalıysa, arşiv sınırının bunu uygulamasına izin verin. İstemediğim şey, teknolojinin bu kararı kazara vermesidir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Arşivleme artık bir bağlam kararını da içeriyor: geçmişin ajanlar için erişilebilir kalıp kalmayacağı. Bir arşiv, veri hâlâ var olduğu için otomatik olarak bir ajanın bağlamının parçası olmaz. Kararı işe bırakın, sonra insan erişimiyle aynı yetkilendirme ve saklama kurallarını uygulayın.

Steve Trucking: Yaşam Döngüsüne İhtiyacımız Olmadan Karar Verin

Beş yılda: yaklaşık 9 milyon iş emri, 14,5 milyon satır kalemi, milyonlarca fotoğraf ve bilinçli olarak çekirdeğin dışında tuttuğumuz durum geçmişi ve GPS. Steve Trucking’in “eski”nin ne demek olduğuna karar vermek için beşinci yılı beklemesini istemem. Kesin süreler henüz belirlenmemiş olabilir; bu sorun değil. Ama mimari şimdiden sormalı: tamamlanmış bir teslimat ne kadar süre operasyonel kalır? Müşteri hizmetlerinin hangi ayrıntıları hemen görmesi gerekir? İş emirleri ve satır kalemleri ne zaman arşive geçer ve nereye? Hangi geçmiş Snowflake’e aittir? Eski fotoğraflar nerede durur ve ne zaman silinir? Perakende Ortakları hangi arşivlenmiş kayıtları hâlâ görür? Bir ajan arşivlenmiş teslimatlara ulaşabilir mi? Bunlar temizlik soruları değil. Mimari sorulardır.

Her yüksek hacimli nesne için beş yanıt isterim. Ne zaman aktif olmayı bırakır? Nereye gider? Oraya ulaştığını nasıl kanıtlarız? Sonrasında biri onu nasıl bulur? Sonunda ne zaman silinir? Bunları yanıtlayamıyorsanız bir arşiv stratejiniz yok. Bir umudunuz var.

Büyütmek için tıklayın

Five answers, or you have a hope. ⟲

Mimarın Burada Karar Verdikleri

• Her yüksek hacimli nesnenin aktif, arşivlenmiş, saklanan ve temizlenen yaşam döngüsü; depolama veya performans zorlamadan önce kararlaştırılmış.
• Herhangi bir yıkıcı arşivleme veya temizlemeden önce hangi yedekleme ve kurtarmanın yerinde olması gerektiği.
• Arşivlenmiş verinin nerede durduğu (big object, Salesforce Connect üzerinden harici depo, Salesforce’un Archive’ı); hacme, getirmeye, gecikmeye, güvenliğe, maliyete ve silmeye göre.
• Kayıtlar silme sınırını geçmeden önce arşiv çalışmalarının nasıl doğrulandığı ve yeniden başlatılabilir yapıldığı.
• Hangi yapılandırılmamış içeriğin çekirdeğin dışında durduğu, iş kaydı ise Salesforce’ta kalırken; ve arşivlenmiş verinin ajanlar için erişilebilir kalıp kalmadığı.

Verinin bir sisteme nasıl girdiğine çok zaman harcarız: API’ler, içe aktarmalar, entegrasyonlar, taşımalar, kullanıcılar, ajanlar. Nasıl çıktığına da o kadar zaman harcayın, çünkü bugün oluşturduğumuz veri yarının büyük veri hacmi sorunudur. Arşiv üç yıl sonra başlayabilir. Yaşam döngüsü şimdi var olmalı. Girişi tasarlarken çıkışı da tasarlayın.

Daha Fazlası

• Trailhead, Explore Archival Versus Purge in Data Cleanup (yeni sekmede açılır): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (yeni sekmede açılır): archive policies and preview, job sessions, Log Failures and Continue, purge policies, legal holds, Archive Search and the Archive component, checked 2026-11-01. ⟲
• ISO, ISO 15489-1:2016, Records management: Concepts and principles (yeni sekmede açılır) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (yeni sekmede açılır) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (yeni sekmede açılır) (a one-pass archiver; test with a dry run first), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27): Best Practices (yeni sekmede açılır), Deleting Data (yeni sekmede açılır) and Best Practices: Deleting Data (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (yeni sekmede açılır), and Salesforce, Own’s tools, now part of Salesforce (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (yeni sekmede açılır), checked 2026-11-01. ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲