Πώς κάνετε import 100 εκατομμύρια CSV records σε μια βάση γρήγορα;

Question

IT Interview Practice · Accepted Answer

Χρησιμοποιήστε το **native bulk-load path** της βάσης (Postgres `COPY`, MySQL `LOAD DATA`), σπάστε το αρχείο σε chunks που φορτώνονται **παράλληλα** σε έναν **staging table** με indexes και constraints **απενεργοποιημένα**, μετά ξαναχτίστε τα indexes μία φορά και κάντε merge — και κάντε ολόκληρο το job **idempotent** ώστε ένα crash να μπορεί να κάνει resume χωρίς να διπλασιάζει rows.

```text
100M-row CSV
     │ split by byte offset
     ▼
[chunk 1] [chunk 2] ... [chunk N]     N parallel workers
     │        │             │
     └──── COPY / LOAD DATA (no indexes) ────▶ staging_table (UNLOGGED)
                                                    │
                                          rebuild indexes + validate
                                                    │
                                    INSERT ... SELECT (upsert) into target
```

## Γιατί το row-by-row INSERT είναι το λάθος εργαλείο

Ένα αφελές `INSERT` ανά row πληρώνει ένα round-trip, ένα parse, ένα WAL/redo write και ένα index update **100 εκατομμύρια φορές**. Ακόμα και σε 1ms το καθένα αυτό είναι πάνω από μια μέρα. Τα bulk paths κερδίζουν αποσβένοντας όλα αυτά: το `COPY` κάνει stream τα rows σε ένα protocol message, κάνει batch το WAL, και παρακάμπτει το per-statement planning. Σε πραγματικό hardware ένα μοναδικό `COPY` κάνει 100k–500k rows/s έναντι λίγων χιλιάδων για INSERT.

## Τα κινούμενα μέρη

- **Staging table πρώτα.** Φορτώστε σε έναν αναλώσιμο πίνακα (`UNLOGGED` στην Postgres παρακάμπτει το WAL εντελώς), ποτέ κατευθείαν στον live πίνακα. Αυτό απομονώνει το load από τους readers και σας αφήνει να κάνετε validate πριν το publish.
- **Απενεργοποιήστε indexes και constraints κατά το load.** Κάθε secondary index και FK check ξανα-αξιολογείται ανά row. Κάντε drop τα, φορτώστε, μετά `CREATE INDEX` μία φορά — το χτίσιμο ενός index σε bulk (ταξινομημένο) είναι πολύ φθηνότερο από 100M incremental updates.
- **Chunk + parallelise.** Σπάστε το αρχείο κατά byte offset σε N κομμάτια και τρέξτε N `COPY` streams. Το throughput κάνει scale με I/O και CPU μέχρι να κορεσίσετε τον δίσκο ή το WAL. Ταιριάξτε το N στα cores/IOPS, όχι "όσα το δυνατόν περισσότερα".
- **Idempotent + resumable.** Ταγκάρετε κάθε chunk με ένα id· καταγράψτε ποια chunks έκαναν commit. Στο restart, παραλείψτε τα ολοκληρωμένα chunks. Κάντε publish με `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) ώστε το ξανατρέξιμο να μη διπλο-εισάγει ποτέ.

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

Ο συνεντευκτής ελέγχει αν ξέρετε ότι το **bulk path υπάρχει** και *γιατί* είναι τάξεις μεγέθους ταχύτερο — όχι το syntax του COPY. Καλό: "χρησιμοποίησε COPY". Εξαιρετικό: "COPY σε έναν UNLOGGED staging table, indexes dropped, parallel chunks, rebuild μετά, upsert για publish, resumable κατά chunk id." Η κλασική παγίδα είναι το loop-άρισμα INSERTs (ή ένα ORM `saveAll`) και η έκπληξη ότι παίρνει ώρες· η δεύτερη παγίδα είναι το φόρτωμα κατευθείαν στον live πίνακα και το μπλοκάρισμα της παραγωγής.

## Trade-offs & τρόποι αποτυχίας

- **UNLOGGED / no-WAL σημαίνει καμία crash recovery** για τον staging table — εντάξει γιατί είναι αναλώσιμος, μοιραίο αν το κάνατε στον πραγματικό πίνακα.
- **Πολύ υψηλό parallel** θρασάρει δίσκο και WAL· πέρα από τον κορεσμό το throughput *πέφτει*. Κάντε benchmark το sweet spot.
- **Το ξαναχτίσιμο indexes χρειάζεται `maintenance_work_mem`/temp space**· ένα index build 100M-row μπορεί να χυθεί στον δίσκο.
- **Βρώμικο CSV** (κακό encoding, embedded delimiters) αποτυγχάνει ένα ολόκληρο chunk — κάντε validate τους τύπους στο staging, βάλτε σε καραντίνα τα rejects, κρατήστε το load να κινείται.

Γιατί το row-by-row INSERT είναι το λάθος εργαλείο

Τα κινούμενα μέρη

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

Trade-offs & τρόποι αποτυχίας

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