ถ้าคุณไม่จัดเก็บถาวรวันนี้…

🌐 มีให้อ่านอีก 19 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ ส่วนนี้มีการเปลี่ยนแปลงในฉบับภาษาอังกฤษและยังไม่ได้แปลใหม่ (42)

โมดูลที่ 4 จาก 4 ในบท การออกแบบเพื่อรองรับขนาด บทที่ 7 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: เมื่อปริมาณพบกับโมเดลการแชร์ · ถัดไป: บทถัดไป สถาปัตยกรรม Query และการดึงข้อมูล

คำถามที่โมดูลนี้ตอบ: คุณวางแผนการจัดเก็บถาวรและการลบทิ้งอย่างไร?

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 (เปิดในแท็บใหม่), Winter ‘27). ⟲

ทุกเรกคอร์ดมีวงจรชีวิต

เราเคยถามแล้วว่าเรกคอร์ดถูกสร้างอย่างไร ใครเป็นเจ้าของ ใครเปลี่ยนได้ อะไรมีอำนาจชี้ขาด ทีนี้อีกข้อหนึ่ง: มันออกไปอย่างไร? เรกคอร์ดหนึ่งอาจเดินทางจากใช้งานอยู่ ไปไม่ใช้งาน ไปจัดเก็บถาวร ไปถูกลบทิ้ง ไม่ใช่ทุกเรกคอร์ดที่ต้องผ่านทุกขั้น แต่ทุกออบเจกต์ปริมาณมากต้องมีวงจรชีวิต การจัดส่งของ Steve Trucking ถูกใช้ตลอดเวลาขณะที่ยังดำเนินอยู่: โดยทีมงาน ผู้ประสานงาน ฝ่ายดูแลลูกค้า พาร์ทเนอร์ ระบบอัตโนมัติ หนึ่งสัปดาห์หลังเสร็จ มันยังมีประโยชน์ หกเดือนต่อมา ส่วนใหญ่เป็นประวัติการบริการ สามปีต่อมา ส่วนใหญ่ใช้เพื่อการวิเคราะห์ การตรวจสอบ หรือข้อพิพาทเป็นครั้งคราว สิบปีต่อมา อาจไม่มีใครมีเหตุผลที่ชอบธรรมที่จะเก็บมันไว้เลย คุณค่าของข้อมูลเปลี่ยนไปตามเวลา สถาปัตยกรรมก็ควรเปลี่ยนตาม

การลบหลีกเลี่ยงไม่ได้ จึงต้องตัดสินใจตั้งแต่วันแรก

สักวันหนึ่งคุณต้องลบข้อมูล ดังนั้นผมต้องการให้นโยบายการเก็บรักษาและการลบทิ้งถูกกำหนดตั้งแต่เริ่มโครงการ ไม่ใช่ตอนที่พื้นที่จัดเก็บแพงขึ้น การเก็บรักษาถูกกำหนดโดยความต้องการทางธุรกิจและกฎระเบียบ: มันต้องอยู่ในการปฏิบัติงานนานแค่ไหน เราต้องเก็บไว้นานแค่ไหน ทำไม ใครอาจต้องใช้ ต้องได้มันเร็วแค่ไหน สุดท้ายลบได้ไหม และความเป็นส่วนตัวบอกให้ลบเร็วกว่านั้นหรือเปล่า? บทที่ 5 แสดงให้เห็นว่าการเก็บทุกอย่างไว้ตลอดไปไม่ได้ปลอดภัยกว่าโดยอัตโนมัติ บางครั้งการเก็บข้อมูลนานขึ้นนั่นแหละคือความเสี่ยง

แยกการตัดสินใจสามเรื่องออกจากกัน การเก็บรักษา: เราเก็บไว้นานแค่ไหน? การจัดเก็บถาวร: เราเก็บสิ่งที่ไม่อยู่ในภาระงานที่ใช้งานอยู่แล้วไว้ที่ไหน และอย่างไร? การลบทิ้ง: มันถูกนำออกอย่างถาวรเมื่อไหร่และอย่างไร? การต้องการข้อมูลเจ็ดปีไม่ได้แปลว่าต้องใช้งานอยู่เจ็ดปี อาจใช้งานอยู่สิบแปดเดือน แล้วจัดเก็บถาวรตลอดช่วงที่เหลือ แล้วจึงลบทิ้ง ตอนนี้วงจรชีวิตก็ชัดเจน

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 (เปิดในแท็บใหม่); Best Practices: Deleting Data (เปิดในแท็บใหม่)). 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. ⟲

คลิกเพื่อขยาย

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

สำรองข้อมูลก่อนลบ

การจัดเก็บถาวรท้ายที่สุดหมายถึงการนำเรกคอร์ดออกจากระบบที่ใช้งานอยู่ ดังนั้นก่อนออกแบบการลบ ผมต้องการเรื่องราวของการกู้คืน: เรากู้คืนได้ไหม เร็วแค่ไหน เรารู้แน่ชัดไหมว่าอะไรหายไป เรากู้คืนความสัมพันธ์ได้ไหม เราทดสอบมันแล้วหรือยัง? การสำรองข้อมูลต้องมีก่อนที่จะลบอะไรก็ตาม การสำรองข้อมูลกับการจัดเก็บถาวรเป็นความสามารถคนละอย่าง: การสำรองข้อมูลปกป้องจากการสูญหาย การจัดเก็บถาวรจงใจย้ายข้อมูลออกจากกลุ่มที่ใช้งานอยู่ ขณะที่ยังรักษาสิทธิ์เข้าถึงที่ธุรกิจยังต้องการ การลบผิดสิบเรกคอร์ดน่ารำคาญ การลบผิดสิบล้านคือเหตุการณ์ร้ายแรง จำนวนเลขศูนย์ใช้กับความผิดพลาดด้วย

ตอนนี้ทั้งสองอย่างมาจาก Salesforce เอง Own บริษัทที่อยู่เบื้องหลัง OwnBackup เป็นส่วนหนึ่งของ Salesforce Platform แล้ว: Own Recover ตอนนี้คือ Salesforce Backup & Recover (สำรองข้อมูลและเมตาดาต้ารายวันและตามต้องการ กู้คืนระดับฟิลด์ เรกคอร์ด หรือออบเจกต์ กู้คืนแบบ ณ จุดเวลา) และ Archive ย้ายข้อมูลที่ใช้น้อยไปยังที่จัดเก็บต้นทุนต่ำ ขณะที่ยังเข้าถึงได้จากภายใน Salesforce ภายใต้นโยบายการจัดเก็บถาวรและการเก็บรักษา (Own From Salesforce Product Suite FAQ (เปิดในแท็บใหม่); Own’s tools, now part of Salesforce (เปิดในแท็บใหม่))

ที่จัดเก็บถาวรที่ไม่มีใครหาเจอ เกือบเท่ากับการลบ

ทีมหนึ่งย้ายข้อมูลเก่าไปไว้ที่ที่ถูกกว่า จัดเก็บถาวรเสร็จ แล้วลูกค้าโทรมา: “ฉันมีการจัดส่งเมื่อสี่ปีก่อน และฉันต้องการหลักฐานการจัดส่ง” เจ้าหน้าที่ค้นใน Salesforce: ไม่มีอะไรเลย ตอนนี้พวกเขาต้องใช้อีกระบบหนึ่ง ตารางที่ถูกต้อง ตัวระบุ ผู้ดูแลระบบ คำขอ และสองวัน นั่นไม่ค่อยเป็นที่จัดเก็บถาวรเท่าไร ข้อมูลที่จัดเก็บถาวรไม่จำเป็นต้องทำงานเหมือนข้อมูลที่ใช้งานอยู่ มันอาจช้ากว่า อ่านได้อย่างเดียว แสดงในคอมโพเนนต์อื่น แต่ข้อมูลที่จัดเก็บถาวรต้องยังค้นหาได้ ตามที่ธุรกิจต้องการ

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. ⟲

ที่จัดเก็บถาวรควรอยู่ที่ไหน?

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 (เปิดในแท็บใหม่)). 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 (เปิดในแท็บใหม่)). ⟲

คลิกเพื่อขยาย

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 (เปิดในแท็บใหม่)). ⟲

คลิกเพื่อขยาย

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 (เปิดในแท็บใหม่)). ⟲

คลิกเพื่อขยาย

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. ⟲

ผลิตภัณฑ์ไม่ใช่บทเรียน คุณลักษณะต่างหาก: ข้อมูลมากแค่ไหน ถูกดึงบ่อยแค่ไหน ต้องปรากฏเร็วแค่ไหน ต้องการการเข้าถึงแบบเชิงสัมพันธ์ไหม ผู้ใช้ต้องหามันเจอจาก Salesforce ไหม อ่านได้อย่างเดียวได้ไหม ใครเห็นได้ เก็บไว้นานแค่ไหน มีต้นทุนเท่าไร และสุดท้ายจะถูกลบทิ้งอย่างไร คำตอบเหล่านั้นเป็นตัวเลือกเทคโนโลยี และจำไว้ว่า ข้อมูลอยู่ที่ไหนทางกายภาพ กับผู้ใช้ค้นพบมันได้ที่ไหน เป็นคำถามคนละข้อ การจัดส่งอายุห้าปีไม่ควรอยู่ในออบเจกต์ที่ใช้งานอยู่ นั่นไม่ได้แปลว่าเจ้าหน้าที่ดูแลลูกค้าไม่ควรหามันเจอ

การจัดเก็บถาวรสามขั้นตอน

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 (เปิดในแท็บใหม่)), 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 (เปิดในแท็บใหม่)). 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 (เปิดในแท็บใหม่)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲

คลิกเพื่อขยาย

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

และออกแบบให้เริ่มใหม่ได้ จัดเก็บถาวร 20 ล้านเรกคอร์ด งานล้มเหลวที่เรกคอร์ด 14,382,711 ถ้าคำตอบคือ “เริ่มใหม่ทั้งหมด” ผมไม่ชอบการออกแบบนั้น การดำเนินการขนาดใหญ่ล้มเหลวได้: การเชื่อมต่อหลุด งานหมดเวลา เรกคอร์ดแปลกๆ ตัวเดียวทำให้เกิดข้อผิดพลาด กระบวนการต้องรู้ว่าอะไรสำเร็จไปแล้ว ซึ่งก็คือหน้าที่ของสถานะการจัดเก็บถาวร (รอดำเนินการ ตรวจยืนยันแล้ว จัดเก็บถาวรแล้ว ล้มเหลว) เพื่อให้เริ่มใหม่ได้โดยไม่ทำข้อมูลซ้ำ ไม่ทำข้อมูลหาย และไม่ลบสิ่งที่ยังไม่ได้จัดเก็บถาวรอย่างปลอดภัย ในระดับขนาดใหญ่ การเริ่มใหม่ได้เป็นส่วนหนึ่งของความน่าเชื่อถือ

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

การจัดเก็บถาวรอาจกลายเป็นข้ออ้างเพื่อเลี่ยงการตัดสินใจลบ “เผื่อสักวันเราต้องใช้” อาจไม่ต้อง บทที่ 5 ถามว่า เราได้รับอนุญาตให้เก็บมันไว้ไหม? บทนี้เพิ่มว่า การเก็บมันไว้ในสถานะใช้งานมีคุณค่าไหม? บางเรกคอร์ดย้ายไปที่จัดเก็บถาวร บางส่วนถูกสรุป บางส่วนถูกทำให้เป็นนิรนาม บางส่วนถูกลบ เป้าหมายไม่ใช่การรักษาทุกไบต์ แต่คือการเก็บสิ่งที่ธุรกิจต้องการอย่างชอบธรรม ตราบเท่าที่ต้องการอย่างชอบธรรม

ไฟล์เปลี่ยนจำนวนเลขศูนย์

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. ⟲

ที่จัดเก็บถาวรยังต้องปลอดภัย

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. ⟲

เอเจนต์กับข้อมูลที่จัดเก็บถาวร

ผู้รับคนหนึ่งถามเอเจนต์ว่า “ตู้เย็นของฉันถูกส่งไปที่ไหนเมื่อสี่ปีก่อน?” คำตอบมีอยู่ แต่ถูกจัดเก็บถาวรไปแล้ว เอเจนต์ควรเข้าถึงมันได้ไหม? จุดยืนของผม: นั่นเป็นการตัดสินใจที่สำคัญ และเป็นของธุรกิจที่จะตัดสิน สถาปนิกวางตัวเลือกและต้นทุนของแต่ละตัวเลือก: ที่จัดเก็บถาวรไหน เอเจนต์เข้าถึงอย่างไร ความหน่วง การใช้ทรัพยากร เอเจนต์พูดอะไรได้บ้างเกี่ยวกับข้อมูลเก่า และขีดจำกัดด้านการเก็บรักษาและความเป็นส่วนตัว แล้วธุรกิจตัดสินใจ ถ้าข้อมูลที่จัดเก็บถาวรควรยังเข้าถึงได้ ให้สร้างเส้นทางการดึงข้อมูลที่ได้รับอนุญาต ถ้าไม่ควร ให้ขอบเขตของที่จัดเก็บถาวรบังคับใช้สิ่งนั้น สิ่งที่ผมไม่ต้องการคือเทคโนโลยีเป็นผู้ตัดสินใจโดยบังเอิญ

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร ตอนนี้การจัดเก็บถาวรรวมถึงการตัดสินใจเรื่องบริบทด้วย: ประวัติยังอยู่ในระยะที่เอเจนต์เข้าถึงได้หรือไม่ ที่จัดเก็บถาวรไม่ได้กลายเป็นส่วนหนึ่งของบริบทของเอเจนต์โดยอัตโนมัติเพียงเพราะข้อมูลยังอยู่ จงนำการตัดสินใจไปให้ธุรกิจ แล้วใช้กฎการอนุญาตและการเก็บรักษาแบบเดียวกับการเข้าถึงของมนุษย์

Steve Trucking: ตัดสินใจเรื่องวงจรชีวิตก่อนที่เราจะต้องใช้

ที่ห้าปี: ประมาณ 9 ล้านใบสั่งงาน 14.5 ล้านรายการ ภาพถ่ายหลายล้านภาพ รวมถึงประวัติสถานะและ GPS ที่เราจงใจเก็บไว้นอกระบบหลัก ผมไม่อยากให้ Steve Trucking รอจนถึงปีที่ห้าถึงจะตัดสินใจว่า “เก่า” หมายถึงอะไร ช่วงเวลาที่แน่นอนอาจยังไม่ได้กำหนด ไม่เป็นไร แต่สถาปัตยกรรมควรเริ่มถามแล้ว: การจัดส่งที่เสร็จแล้วอยู่ในการปฏิบัติงานนานแค่ไหน? เจ้าหน้าที่ดูแลลูกค้าต้องเห็นรายละเอียดไหนทันที? ใบสั่งงานและรายการของมันย้ายไปที่จัดเก็บถาวรเมื่อไหร่ และไปที่ไหน? ประวัติไหนควรอยู่ใน Snowflake? ภาพถ่ายเก่าอยู่ที่ไหน และถูกลบเมื่อไหร่? พาร์ทเนอร์ค้าปลีกยังเห็นเรกคอร์ดที่จัดเก็บถาวรไหนบ้าง? เอเจนต์เข้าถึงการจัดส่งที่จัดเก็บถาวรได้ไหม? นั่นไม่ใช่คำถามเรื่องการเก็บกวาด มันเป็นคำถามเชิงสถาปัตยกรรม

สำหรับออบเจกต์ปริมาณมากทุกตัว ผมต้องการห้าคำตอบ มันเลิกใช้งานเมื่อไหร่? มันไปที่ไหน? เราพิสูจน์อย่างไรว่ามันไปถึง? หลังจากนั้นคนจะหามันเจอได้อย่างไร? สุดท้ายมันถูกลบเมื่อไหร่? ถ้าคุณตอบไม่ได้ คุณไม่ได้มีกลยุทธ์การจัดเก็บถาวร คุณมีแค่ความหวัง

คลิกเพื่อขยาย

Five answers, or you have a hope. ⟲

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• วงจรชีวิตแบบใช้งานอยู่ จัดเก็บถาวร เก็บรักษา และลบทิ้งของออบเจกต์ปริมาณมากทุกตัว ที่ตัดสินใจก่อนที่พื้นที่จัดเก็บหรือประสิทธิภาพจะบังคับ
• การสำรองข้อมูลและการกู้คืนแบบไหนต้องพร้อมก่อนการจัดเก็บถาวรหรือการลบทิ้งที่ทำลายข้อมูลใดๆ
• ข้อมูลที่จัดเก็บถาวรอยู่ที่ไหน (big object ที่จัดเก็บภายนอกผ่าน Salesforce Connect หรือ Archive ของ Salesforce) โดยพิจารณาจากปริมาณ การดึงข้อมูล ความหน่วง ความปลอดภัย ต้นทุน และการลบ
• การรันการจัดเก็บถาวรถูกตรวจยืนยันและทำให้เริ่มใหม่ได้อย่างไร ก่อนที่เรกคอร์ดจะข้ามเส้นของการลบ
• เนื้อหาไม่มีโครงสร้างไหนอยู่นอกระบบหลัก ขณะที่เรกคอร์ดทางธุรกิจของมันยังอยู่ใน Salesforce และข้อมูลที่จัดเก็บถาวรยังอยู่ในระยะที่เอเจนต์เข้าถึงได้หรือไม่

เราใช้เวลามากกับการที่ข้อมูลเข้าสู่ระบบ: API การนำเข้า การผสานรวม การย้ายข้อมูล ผู้ใช้ เอเจนต์ จงใช้เวลามากเท่ากันกับการที่มันออกไป เพราะข้อมูลที่เราสร้างวันนี้คือปัญหาข้อมูลปริมาณมากของวันพรุ่งนี้ การจัดเก็บถาวรอาจยังไม่เริ่มอีกสามปี แต่วงจรชีวิตควรมีอยู่ตอนนี้ ออกแบบทางออกตอนที่คุณออกแบบทางเข้า

ศึกษาเพิ่มเติม

• Trailhead, Explore Archival Versus Purge in Data Cleanup (เปิดในแท็บใหม่): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
• Salesforce Help, Archive App (เปิดในแท็บใหม่): 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 (เปิดในแท็บใหม่) (current; confirmed 2021), checked 2026-11-01. ⟲
• Industry examples of the same pattern: Oracle, Archive and Purge (เปิดในแท็บใหม่) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (เปิดในแท็บใหม่) (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 (เปิดในแท็บใหม่), Deleting Data (เปิดในแท็บใหม่) and Best Practices: Deleting Data (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Help, Data and File Storage Allocations (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Help, Own From Salesforce Product Suite FAQ (เปิดในแท็บใหม่), and Salesforce, Own’s tools, now part of Salesforce (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Help, Choose Which Salesforce Connect Adapter to Use (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Developers, Big Objects Implementation Guide (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲