การโหลดในปริมาณมาก

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ ส่วนนี้มีการเปลี่ยนแปลงในฉบับภาษาอังกฤษและยังไม่ได้แปลใหม่ (52)

โมดูลที่ 2 จาก 5 ในบท การย้ายข้อมูลและการซิงก์ บทที่ 10 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: การย้ายข้อมูลเป็นโครงการด้านคุณภาพก่อนอื่นใด · ถัดไป: ระบบอัตโนมัติระหว่างการโหลด

คำถามที่โมดูลนี้ตอบ: จำนวนเลขศูนย์เปลี่ยนวิธีที่คุณโหลดข้อมูลเข้า Salesforce อย่างไร?

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

Start With the Picture

Same landscape, same amber arrow as module 1: RouteDesk’s open work coming into Salesforce the weekend RouteDesk retires. ⟲

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

Module 1 decided what moves on this arrow. This module is about how it moves. ⟲

Module 1 decided what comes in: the deliveries not yet made and the ones still inside the 60-day claim window, about 196,400 deliveries. Each one becomes a Work Order, with its line items (about 1.6 per delivery, so about 314,000) and its Service Appointment (about 196,400 more). That’s roughly 707,000 records, prepared in the preparation data store and ready to go. Not millions, but well past anything I’d send one record at a time. So, how do they get in? ⟲

ลานขนถ่ายสินค้าหลังธนาคาร

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

The 200 is still real. A REST sObject Collections request takes “up to 200 records” (Create Records Using sObject Collections (เปิดในแท็บใหม่), REST API Developer Guide), and a SOAP create() call the same: “If a create request exceeds 200 records, then the entire operation fails” (create() (เปิดในแท็บใหม่), SOAP API Developer Guide; both checked 2026-10-27). Every 200 more records is another call. RouteDesk’s 707,000 records would be over 3,500 trips to the teller. ⟲

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

Same records, different door. ⟲

ลานขนถ่ายมีห้าขั้นตอน:

1. เปิดงาน กดกริ่งสีแดงแล้วรับบัตรคิว: job ID
2. อัปโหลด ลานเปิด และคุณขนไฟล์ CSV ของคุณขึ้นตามบัตรคิวนั้น ไฟล์เดียวหรือร้อยไฟล์ก็ได้
3. ปิดงาน Salesforce ไม่รู้ว่าคุณเสร็จแล้วจนกว่าคุณจะกดปุ่มสีน้ำเงินอันใหญ่: อัปโหลดเสร็จ ตอนนี้มันเริ่มประมวลผล
4. “ถึงหรือยัง?” เหมือนลูกๆ ของผมที่เบาะหลัง: คุณถามด้วย job ID ว่ามันเสร็จหรือยัง เสร็จหรือยัง? เสร็จหรือยัง?
5. รับผลลัพธ์ ดาวน์โหลดเรกคอร์ดที่สำเร็จ (พร้อม Salesforce ID ใหม่) หรือที่ล้มเหลว (พร้อมข้อผิดพลาด)

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

Submit, wait, collect. ⟲

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

ลานขนถ่ายสองแห่ง: Bulk API 2.0 และ Bulk API

มีสองเวอร์ชัน และสำคัญว่าคุณใช้เวอร์ชันไหน

• Bulk API 2.0 is the one to start with. You upload the data for a job and Salesforce splits it into batches for you, retries for you and runs them in parallel. A job can take 150 MB, measured after Salesforce encodes it, so Salesforce advises uploading no more than 100 MB of CSV per job. ⟲
• Bulk API (1.0) makes you create the batches yourself, up to 10,000 records each. It’s older, but it still has two levers 2.0 doesn’t give you: serial mode for loads, and PK chunking for very large exports (module 5). ⟲

Both share a rolling 24-hour allowance of 15,000 batches, and either can load up to 150 million records in 24 hours. Job results are kept for seven days after the job completes (Bulk API and Bulk API 2.0 Limits and Allocations (เปิดในแท็บใหม่), checked 2026-10-27). Salesforce’s line between the doors: “Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0”; below that, “bulkified” synchronous calls are fine (Loading Data from the API (เปิดในแท็บใหม่), Best Practices for Deployments with Large Data Volumes, Winter ‘27, checked 2026-10-27). Those are today’s numbers: check them before you plan around them. ⟲

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

Test knowledge. Know when the Bulk API is the answer: more than about 2,000 records, asynchronous, a job you submit and collect. Know the two versions apart: Bulk API 2.0 splits the batches for you and runs them in parallel; Bulk API (1.0) has you build batches of up to 10,000 records, and only it offers serial mode and PK chunking. Both share 15,000 batches in a rolling 24 hours. ⟲

เครื่องมือไม่ได้ลบสถาปัตยกรรมทิ้ง

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

The order comes from the model, and module 1 drew it for RouteDesk: reference data first, then the Work Orders, then their line items and appointments, then the claim Cases that point at them (Preserve the Source Identity, and Load by Keys). Each wave is its own job, and the next one doesn’t start until the last one’s results are in. Junction objects depend on two parents, self-referencing hierarchies may need several passes, and circular relationships may need records first and relationships second. Don’t discover these on cutover weekend. ⟲

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

Insert, update หรือ upsert

Insert says create this as new. Update says I already know the Salesforce record I’m changing. Upsert says use this key to find out whether the record exists; update it if it does, create it if it doesn’t. With stable External IDs, upsert makes rehearsals far easier: load, find a transformation problem, fix it, rerun, without the run assuming everything is a first-time insert. Keys are architecture, not just integration plumbing. RouteDesk’s Work Orders upsert on the partner key, the same field the integration uses, so a manifest Redrock resends on cutover weekend updates the migrated record instead of duplicating it. ⟲

Upsert has a price, though. Salesforce’s own Large Data Volumes guide ranks the operations: “insert() is fastest, update() is next, and upsert() is next after that. If possible, also break upsert() into two operations: create() and update()” (Loading Data from the API (เปิดในแท็บใหม่), checked 2026-10-27). How do you know which records are new and which already exist? The preparation data store knows, because it pulled down what Salesforce already has and keeps the IDs that came back (module 1). So the 190,000 delivered Work Orders that nothing in Salesforce has touched can go in as a plain insert, and only the open ones the integration may already have created need the upsert. ⟲

Two more lines from the same guide. Load clean data: “Errors in batches trigger single-row processing for that batch, and that processing heavily impacts performance.” That’s module 1 paying off at the loading dock. And when you update, “send only fields that have changed.” A reload that resends every field of 196,400 Work Orders does work nobody asked for. ⟲

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

Test knowledge. Insert is the fastest operation, then update, then upsert; Salesforce suggests splitting an upsert into creates and updates where you can. Upsert needs an External ID, and it’s what makes reruns safe. Load clean data, because errors in a Bulk API batch push that batch into slow single-row processing, and send only the fields that changed. ⟲

แบบขนานเร็วกว่า จนกว่ามันจะไม่เร็ว

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

RouteDesk is exactly that shape. Almost 196,400 Work Orders, and nearly every one points at one of three Retail Partner Accounts. Load them in parallel in the order RouteDesk exported them, and every batch holds Work Orders for all three partners. ⟲

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

In export order, every batch needs every parent. One locks, the others wait. ⟲

Two levers. First, sort the files by parent, so the children of one parent travel together in the same batch instead of being spread across batches that collide. Salesforce gives the same advice: “When changing child records, group them by parent—group records by the field ParentId in the same batch to minimize locking conflicts” (Loading Data from the API (เปิดในแท็บใหม่), checked 2026-10-27). ⟲

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

Sorted by partner, each batch works on its own parent. ⟲

Second, on Bulk API 1.0, serial mode processes one batch at a time: slower, but it removes the contention. I reach for serial mode when the data is complex and we’re running into collisions and timeouts. Salesforce’s own guide is more cautious: serial mode “is used only when previously submitted asynchronous jobs have accidentally produced contention because of locks. Use only when advised by Salesforce” (Limits (เปิดในแท็บใหม่), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-27). So sort first, and treat serial as the fallback. And it’s only on the older dock: Bulk API 2.0’s job reference says “Currently only parallel mode is supported,” and if other modes ever arrive, “the mode will be chosen automatically by the API and will not be user configurable” (Create a Job (เปิดในแท็บใหม่), Bulk API 2.0, checked 2026-10-27). A load that needs serial processing is a reason to use Bulk API 1.0. ⟲

Serial mode is a setting on the job, chosen when you create it. On Bulk API 1.0, RouteDesk’s Work Orders would be: ⟲

POST /services/async/68.0/job
{
  "operation": "upsert",
  "object": "WorkOrder",
  "externalIdFieldName": "Partner_Delivery_Key__c",
  "contentType": "CSV",
  "concurrencyMode": "Serial"
}

Leave concurrencyMode out and you get Parallel, the default. Salesforce’s job reference says when to change it: “If parallel mode results in too many failed records or failed jobs, submit the job with Serial concurrency mode,” and adds that it “can significantly increase the processing time” (JobInfo (เปิดในแท็บใหม่), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-31). ⟲

And if three parents are too few for any sorting to help, look at the model. Checkpoint 1 already offered a way to spread them: link Work Orders to a child Account per distribution center, so nine parents share the load instead of three. That’s a design decision, made before the migration, not a loader setting. ⟲

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

Test knowledge. Parallel loads lock parent records. When many children share a few parents, expect “unable to lock row” errors: sort the load file by parent so each batch touches as few parents as possible. Serial mode (Bulk API 1.0 only) removes the contention at the cost of speed; Salesforce reserves it for lock contention the sorting didn’t solve. ⟲

ขนาด batch คือการตัดสินใจเรื่องการปรับแต่ง

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

And the rehearsal data needs the same shape as production. Twenty million records in production, ten thousand in the test, and everything flies: what did we prove? Not much about scale. The test doesn’t need every record, but it must expose the architecture: heavy concentration on a few parents, millions of children, large text fields, complex relationships, historical skew, automation triggered by particular values. The Number of Zeros matters, and so does the shape behind the zeros. For RouteDesk that means a rehearsal set where a third of the Work Orders still point at Redrock. ⟲

ผู้ใช้สำหรับการโหลด และใครเป็นเจ้าของเรกคอร์ด

For a substantial migration I want a dedicated migration identity, not someone’s personal admin account: for traceability, controlled permissions, automation decisions (module 3), monitoring and troubleshooting. A million records created by the migration user during cutover tells me something. A million created by Daniel Reyes because Daniel ran Data Loader on Saturday night mixes human identity with system activity. Give it the permissions the job needs, and don’t let it become a permanent mystery superuser nobody dares disable. ⟲

Then don’t confuse who loaded a record with who should own it. Created By is provenance; Owner is architecture, with sharing and business consequences. Set business ownership deliberately. Sometimes there’s no good answer in the source: the record’s owner left years ago, or never existed. It can be hard to assign records to active users, and I’ve created a dedicated “data load” user to own them. That’s sound practice with one condition from chapter 7: a user who owns more than 10,000 records of an object is ownership skew, so that owner should have no role, or a role of its own at the top of the hierarchy (Ownership Data Skew (เปิดในแท็บใหม่)), and the records should have a path to real owners. Who owns the records, and where that owner sits in the role hierarchy, is an important decision the team makes for any bulk import, not something the loader defaults. For RouteDesk’s Work Orders, chapter 7’s question decides it: does ownership drive who sees a delivery? At Steve Trucking it doesn’t (partners see their own deliveries through the partner on the record), so one owner with no role is fine. ⟲

เครื่องมือ: เลือกเพื่อความสามารถในการทำซ้ำ

There are many ways to load data, and the tool matters less than how you use it. Salesforce’s Data Loader has been tried and true, but it’s aged: a desktop tool that works CSV by CSV. Its command-line version can be scripted and pointed at your preparation data store, which is how I’ve run repeated loads. Some tools connect a SQL database straight to Salesforce, copying data down and sending changes back with SQL. ETL and integration platforms do the same job at enterprise scale. And with the APIs you can drive the Bulk API directly: the Salesforce CLI’s sf data upsert bulk loads a CSV through Bulk API 2.0 with an External ID from one command (data upsert bulk (เปิดในแท็บใหม่), Salesforce CLI Command Reference, checked 2026-10-27). You can even have AI write the small scripts that run each complex step. ⟲

ไม่ว่าเครื่องมือไหน นี่คือสิ่งที่ผมยืนยันหนักแน่นที่สุด: ผมไม่ต้องการให้การย้ายข้อมูลบน production เป็นครั้งแรกที่เราทำการย้ายข้อมูล และผมไม่ต้องการให้การซ้อมแต่ละครั้งเป็นการผจญภัยทำมือ ถ้าขั้นตอนที่ 17 บอกว่า “เปิด CSV นี้ เรียงตามคอลัมน์ G ลบแถวว่าง คัดลอกสูตรนี้ลงมา แล้วรัน Data Loader ด้วยการตั้งค่าเหล่านี้” ผมกังวล ทุกขั้นตอนที่ทำด้วยมือคือโอกาสของไฟล์ผิด แถวหาย เวอร์ชันเก่า การเรียงผิด ตัวกรองที่ลืม การตั้งค่าที่ต่างจากตอนซ้อม บางอย่างอาจเลี่ยงไม่ได้: บันทึกไว้และทดสอบ แต่เป้าหมายคือความสามารถในการทำซ้ำ ดังนั้นการดึง การแปลง การตรวจสอบ การโหลด การเก็บผล และการกระทบยอด ควรรันแบบเดียวกันทุกครั้ง

ถ้าคุณตั้งเวลาการโหลด อย่าตั้งให้ถี่เกินกว่าที่มันจะรันเสร็จ งานรายชั่วโมงที่บางครั้งใช้เก้าสิบนาทีจะเริ่มซ้อนทับตัวเอง ตรวจว่ารอบก่อนหน้าเสร็จแล้วก่อนรอบถัดไปจะเริ่ม

Keep Every Result, and Bring the Keys Back

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

Then bring the keys back. The success results carry each record’s new Salesforce ID next to the key you sent. Write them back into the preparation data store, on the row that produced the record: that’s the last frame of module 1’s three sets of keys. On the Zendesk migration I described in module 1, that’s what made everything else possible. With the Salesforce IDs back on every row, I could load in phases (accounts and contacts first, then the cases, then the comments and files that hang off them), and each phase found its parents by the IDs the last one returned. I could do a partial load: just the rows that failed, or just one group. And I could reload: fix a transformation, regenerate the affected rows, and send only those, knowing exactly which Salesforce records they’d update. Without the keys back, every rerun is a guess. ⟲

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

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

Test knowledge. The Bulk API’s success results return each record’s new Salesforce ID with the data you sent, and its failure results return each error; both are kept for seven days. Capture them, write the IDs back to the source or staging data, and you can load in phases, retry only the failures, and reconcile what landed. ⟲

ทดสอบทั้งรอบ

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

If the rehearsal includes a performance or scale test, put Salesforce’s lead time in the plan. “All tests must be pre-approved. Unapproved testing is subject to throttling or blocking,” and for tests at 120 requests a second or below, the request goes in “at least one week before the testing date” (Salesforce Performance and Scale Test FAQs (เปิดในแท็บใหม่), Salesforce Help, checked 2026-10-27). A rehearsal that gets throttled proves nothing about cutover weekend. ⟲

AI เขียนสคริปต์ได้ คุณยังเป็นเจ้าของการรัน

AI is very good at generating transformation scripts, load orchestration, error parsers, reconciliation queries and retry logic. Use it. But generated code can be wrong at enormous speed: a wrong transformation on ten records is ten fixes; on ten million, the Number of Zeros applies to the mistake too. The way I use it is step by step: clean, transform and migrate steps, with every generated command and action tracked. That’s deterministic, auditable automation, not unattended judgment. Test it at realistic scale before you trust it with production data. ⟲

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร AI ลดแรงที่ต้องใช้สร้างเครื่องมือการย้ายข้อมูล และทำให้สร้างและรันการดำเนินการ bulk ได้รวดเร็วขึ้น การดำเนินการยิ่งใหญ่ ความจำเป็นของการแปลงแบบ deterministic ขั้นตอนที่ติดตามได้ การซ้อม การควบคุม และการกระทบยอดก็ยิ่งมาก

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

• กลไกการโหลดและเวอร์ชัน API ไหนเหมาะกับปริมาณและรูปร่างของงาน แทนการปฏิบัติต่อการย้ายข้อมูลเหมือนปริมาณงานเชิงธุรกรรม
• ลำดับของออบเจกต์และความสัมพันธ์ตามการพึ่งพา รวมถึงเมื่อไหร่ที่เรกคอร์ดกับความสัมพันธ์ต้องแยกรอบ
• Which operation each set of records gets (insert, update or upsert), based on what the preparation data store knows already exists. ⟲
• Where parallel processing is safe, and where concentration, locking or automation justify sorting by parent, a model change, or serial processing. ⟲
• คีย์ที่คงที่ ตัวตนสำหรับการย้ายข้อมูล ความเป็นเจ้าของเรกคอร์ด และเครื่องมือที่ทำซ้ำได้แบบไหน ที่ทำให้การซ้อมและการโหลด production เป็นแบบ deterministic
• How results and new IDs come back, so loads can run in phases, retry only failures, and reload safely. ⟲
• หลักฐาน การจัดประเภทความล้มเหลว และการซ้อมเต็มรอบแบบไหนที่จำเป็น ก่อนไว้ใจกระบวนการที่ขนาด production

ลานขนถ่ายยังต้องมีแผน

The loading dock moves enormous amounts of data. It doesn’t decide which truck unloads first, where the pallets go, which shipment belongs to which customer, what happens to a damaged pallet, whether two forklifts are using the same aisle, or whether everything that should have arrived did. That’s architecture. Know the Number of Zeros and the shape behind them. Load in dependency order, use stable keys, control concurrency, bring the keys back, make the process repeatable, keep the evidence, and rehearse the whole thing. Then use the loading dock as fast as the architecture safely allows. ⟲

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

• Salesforce, Bulk API and Bulk API 2.0 Limits and Allocations (เปิดในแท็บใหม่), Developer Limits and Allocations Quick Reference, checked 2026-11-01. ⟲
• Salesforce, General Guidelines for Data Loads (เปิดในแท็บใหม่) and Limits (เปิดในแท็บใหม่), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes, Loading Data from the API (เปิดในแท็บใหม่), Winter ‘27, checked 2026-11-01. ⟲
• Salesforce, REST API Developer Guide, Create Records Using sObject Collections (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce, SOAP API Developer Guide, create() (เปิดในแท็บใหม่), and Bulk API 2.0, Create a Job (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce, Bulk API 2.0 and Bulk API Developer Guide, JobInfo (เปิดในแท็บใหม่) (the Bulk API 1.0 job fields, concurrencyMode), API version 68.0 (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Performance and Scale Test FAQs (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• หลักสูตร Integration Architect: Bulk (coming soon) มีเรื่อง Bulk API อย่างลงลึก
• ในหลักสูตรนี้: การออกแบบเพื่อรองรับขนาด (จุดร้อนและข้อมูลกระจุกตัวด้านความเป็นเจ้าของ)
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (เปิดในแท็บใหม่), checked 2026-11-01. ⟲
• Salesforce Developers, Salesforce CLI Command Reference, data upsert bulk (เปิดในแท็บใหม่), checked 2026-11-01. ⟲