Πώς κάνετε export ένα τεράστιο dataset χωρίς να επηρεάσετε το live σύστημα;

Question

IT Interview Practice · Accepted Answer

**Διαβάστε από ένα replica ή snapshot (ποτέ από το primary), σελιδοποιήστε με keyset pagination αντί για `OFFSET`, κάντε throttle τον ρυθμό ανάγνωσης, και κάντε stream τα αποτελέσματα κατευθείαν σε object storage.** Ο στόχος είναι να κάνετε export 500M rows χωρίς να κρατάτε long locks, να τινάζετε το primary CPU, ή να ανατινάζετε τη μνήμη.

## 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.** Στρέψτε το job σε έναν follower ώστε τα βαριά reads να μην ανταγωνίζονται ποτέ τα production writes στο primary. Ένα **snapshot** δίνει μια σταθερή, point-in-time όψη ώστε το export να είναι consistent ακόμα κι όσο τα live δεδομένα αλλάζουν.
- **Keyset pagination, όχι `OFFSET`.** Το `OFFSET 10000000` κάνει τη βάση να κάνει scan και να πετάξει 10M rows κάθε σελίδα — O(n²) πάνω από το export. Το keyset θυμάται το τελευταίο key και κάνει `WHERE id > :last ORDER BY id LIMIT 5000`, που καβαλάει το index σε O(1) ανά σελίδα.
- **Throttle.** Κοιμηθείτε μεταξύ batches ή βάλτε πλαφόν rows/sec ώστε το replica να μην κορεστεί και το replication lag να μένει φραγμένο.
- **Stream σε object store.** Γράψτε κάθε batch στο S3/GCS ως NDJSON ή Parquet· ποτέ μη φορτώνετε ολόκληρο το result set στη μνήμη. Χρησιμοποιήστε ένα cursor/server-side cursor ώστε ο driver να κάνει stream τα rows.

## Οπτική συνέντευξης

Ο συνεντευκτής ελέγχει αν προστατεύετε το live σύστημα. Το να κατονομάζετε ένα **replica** είναι το ελάχιστο· το senior signal είναι το **keyset over OFFSET** (και το να μπορείτε να εξηγήσετε την παγίδα O(n²)) συν **backpressure/throttling** και **consistency** μέσω ενός snapshot. Μια συνηθισμένη παγίδα: ένα μοναδικό `SELECT *` σε ένα transaction — κρατά ένα read view ανοιχτό για ώρες, φουσκώνει τη βάση (το Postgres vacuum δεν μπορεί να καθαρίσει rows που το long snapshot ακόμα βλέπει), και κάνει buffer τα πάντα στη μνήμη.

**Trade-offs:** ένα replica μπορεί να υστερεί, οπότε το export αντικατοπτρίζει μια ελαφρώς stale στιγμή — συνήθως εντάξει για analytics, όχι για financial reconciliation που χρειάζεται exact-now δεδομένα. Το keyset χρειάζεται ένα σταθερό, unique, indexed sort key· είναι άβολο για αυθαίρετα sort orders. Όταν ο πίνακας είναι τεράστιος και κατέχετε το storage layer, ένα native εργαλείο (`pg_dump`, snapshot export σε S3, `COPY`) συχνά κερδίζει το hand-rolled paging.

Export pipeline

Γιατί κάθε κομμάτι

Οπτική συνέντευξης

Σχετικές ερωτήσεις