คุณจะ export dataset ขนาดมหึมาโดยไม่กระทบระบบ live อย่างไร?

Question

IT Interview Practice · Accepted Answer

**อ่านจาก replica หรือ snapshot (ห้ามจาก primary), เลื่อนหน้าด้วย keyset pagination แทน `OFFSET`, throttle อัตราการอ่าน และ stream ผลลัพธ์ตรงไปยัง object storage** เป้าหมายคือ export 500M row โดยไม่ถือ lock นาน, ไม่ทำให้ CPU ของ primary พุ่ง หรือ memory ระเบิด

## Export pipeline

```text
  Primary DB ──async replication──▶ Read replica / snapshot
                                          │  (isolated from live traffic)
                                          ▼
                                   Export worker
                              keyset page: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## ทำไมแต่ละชิ้น

- **Read replica หรือ snapshot** ชี้งานไปที่ follower เพื่อให้การอ่านหนักไม่แข่งกับการเขียนใน production บน primary **snapshot** ให้มุมมองที่คงที่ ณ จุดเวลาหนึ่ง เพื่อให้ export สอดคล้องกันแม้ข้อมูล live เปลี่ยนแปลงต่อไป
- **Keyset pagination ไม่ใช่ `OFFSET`** `OFFSET 10000000` ทำให้ DB สแกนแล้วทิ้ง 10M row ทุกหน้า — O(n²) ตลอด export keyset จำ key สุดท้ายและทำ `WHERE id > :last ORDER BY id LIMIT 5000` ซึ่งวิ่งบน index ใน O(1) ต่อหน้า
- **Throttle** sleep ระหว่าง batch หรือจำกัด row/วินาที เพื่อให้ replica ไม่อิ่มตัวและ replication lag มีขอบเขต
- **Stream ไปยัง object store** เขียนแต่ละ batch ไปยัง S3/GCS เป็น NDJSON หรือ Parquet อย่าโหลด result set ทั้งหมดเข้า memory ใช้ cursor/server-side cursor เพื่อให้ driver stream row

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์ตรวจว่าคุณปกป้องระบบ live หรือไม่ การระบุ **replica** เป็นพื้นฐาน สัญญาณระดับ senior คือ **keyset เหนือ OFFSET** (และอธิบายกับดัก O(n²) ได้) บวก **backpressure/throttling** และ **consistency** ผ่าน snapshot กับดักที่พบบ่อย: `SELECT *` เดียวใน transaction เดียว — มันถือ read view เปิดไว้หลายชั่วโมง, ทำให้ DB บวม (Postgres vacuum ล้าง row ที่ snapshot ยาวยังเห็นไม่ได้) และ buffer ทุกอย่างใน memory

**ข้อแลกเปลี่ยน:** replica อาจล่าช้า ดังนั้น export สะท้อนช่วงเวลาที่เก่าเล็กน้อย — มักโอเคสำหรับ analytics ไม่โอเคสำหรับการกระทบยอดทางการเงินที่ต้องการข้อมูล ณ ตอนนี้เป๊ะ keyset ต้องการ sort key ที่คงที่, unique และ index ไว้ มันงุ่มง่ามสำหรับ sort order ตามอำเภอใจ เมื่อตารางใหญ่มหึมาและคุณเป็นเจ้าของ storage layer เครื่องมือ native (`pg_dump`, snapshot export ไปยัง S3, `COPY`) มักเอาชนะการ page แบบเขียนเอง

Export pipeline

ทำไมแต่ละชิ้น

มุมมองการสัมภาษณ์

คำถามที่เกี่ยวข้อง