Bagaimana Anda mengekspor dataset raksasa tanpa memengaruhi sistem live?

Question

IT Interview Practice · Accepted Answer

**Baca dari replica atau snapshot (jangan pernah primary), page melalui keyset pagination alih-alih `OFFSET`, throttle laju baca, dan stream hasil langsung ke object storage.** Tujuannya adalah mengekspor 500 juta baris tanpa menahan lock lama, melonjakkan CPU primary, atau meledakkan memori.

## Pipeline ekspor

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

## Mengapa tiap bagian

- **Read replica atau snapshot.** Arahkan job ke follower agar baca berat tidak pernah bersaing dengan write produksi di primary. Sebuah **snapshot** memberi tampilan point-in-time yang stabil sehingga ekspor konsisten bahkan saat data live terus berubah.
- **Keyset pagination, bukan `OFFSET`.** `OFFSET 10000000` membuat DB men-scan dan membuang 10 juta baris setiap halaman — O(n²) atas keseluruhan ekspor. Keyset mengingat key terakhir dan melakukan `WHERE id > :last ORDER BY id LIMIT 5000`, yang menunggangi index dalam O(1) per halaman.
- **Throttle.** Sleep di antara batch atau batasi baris/detik agar replica tidak jenuh dan replication lag tetap terbatas.
- **Stream ke object store.** Tulis setiap batch ke S3/GCS sebagai NDJSON atau Parquet; jangan pernah memuat seluruh result set ke memori. Gunakan cursor/server-side cursor agar driver men-stream baris.

## Perspektif wawancara

Pewawancara memeriksa apakah Anda melindungi sistem live. Menyebut **replica** adalah standar minimum; sinyal senior adalah **keyset alih-alih OFFSET** (dan mampu menjelaskan jebakan O(n²)) plus **backpressure/throttling** dan **consistency** via snapshot. Jebakan umum: satu `SELECT *` dalam satu transaksi — ia menahan read view terbuka berjam-jam, menggembungkan DB (vacuum Postgres tak bisa membersihkan baris yang masih dilihat snapshot panjang), dan mem-buffer semuanya di memori.

**Trade-off:** sebuah replica bisa tertinggal, jadi ekspor mencerminkan momen yang sedikit basi — biasanya baik untuk analitik, tidak untuk rekonsiliasi finansial yang butuh data eksak-sekarang. Keyset butuh sort key yang stabil, unik, dan terindeks; ia canggung untuk urutan sortir arbitrer. Ketika tabel sangat besar dan Anda memiliki storage layer-nya, tool native (`pg_dump`, ekspor snapshot ke S3, `COPY`) sering mengalahkan paging buatan sendiri.

Pipeline ekspor

Mengapa tiap bagian

Perspektif wawancara

Pertanyaan terkait