Si i importoni 100M regjistra CSV në një DB shpejt?

Question

IT Interview Practice · Accepted Answer

Përdorni **native bulk-load path** e bazës (Postgres `COPY`, MySQL `LOAD DATA`), ndani skedarin në chunks të ngarkuara **paralelisht** në një **staging table** me indexes dhe constraints **të çaktivizuara**, pastaj rindërtoni indexes një herë dhe bëni merge — dhe bëjeni gjithë job-in **idempotent** që një crash të mund të rifillojë pa dublikuar rreshta.

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

## Pse INSERT rresht-për-rresht është vegla e gabuar

Një `INSERT` naiv për çdo rresht paguan një round-trip, një parse, një shkrim WAL/redo dhe një update index-i **100 milionë herë**. Edhe me 1ms secili kjo është mbi një ditë. Bulk paths fitojnë duke amortizuar gjithë këtë: `COPY` bën stream të rreshtave në një mesazh protokolli, batch-on WAL, dhe kapërcen planifikimin për çdo statement. Në hardware real një `COPY` i vetëm bën 100k–500k rreshta/s kundrejt disa mijë për INSERT.

## Pjesët lëvizëse

- **Staging table së pari.** Ngarkoni në një tabelë të hedhshme (`UNLOGGED` në Postgres kapërcen WAL fare), kurrë drejt e në tabelën live. Kjo izolon ngarkesën nga lexuesit dhe ju lejon të validoni para publikimit.
- **Çaktivizoni indexes dhe constraints gjatë ngarkesës.** Çdo secondary index dhe FK check ri-vlerësohet për çdo rresht. Hidhini, ngarkoni, pastaj `CREATE INDEX` një herë — ndërtimi i një index-i në bulk (i renditur) është shumë më i lirë se 100M update-e inkrementale.
- **Chunk + paralelizoni.** Ndani skedarin sipas byte offset në N copë dhe ekzekutoni N `COPY` streams. Throughput-i shkallëzohet me I/O dhe CPU derisa të ngopni disk-un ose WAL. Përputhni N me cores/IOPS, jo "sa më shumë të jetë e mundur".
- **Idempotent + resumable.** Etiketoni çdo chunk me një id; regjistroni cilat chunks u committuan. Në restart, kapërceni chunks e kryer. Publikoni me `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) që ri-ekzekutimi të mos bëjë kurrë insert të dyfishtë.

## Këndvështrimi i intervistës

Intervistuesi po kontrollon nëse dini se **bulk path ekziston** dhe *pse* është rendë të tëra madhësie më i shpejtë — jo sintaksën e COPY. Mirë: "përdor COPY". E shkëlqyer: "COPY në një UNLOGGED staging table, indexes të hedhur, chunks paralele, rindërtim pas, upsert për të publikuar, resumable sipas chunk id." Kurthi klasik është loop-imi i INSERT-eve (ose një ORM `saveAll`) dhe të habitesh që merr orë; kurthi i dytë është ngarkimi drejt e në tabelën live dhe bllokimi i production.

## Kompromiset & mënyrat e dështimit

- **UNLOGGED / pa-WAL do të thotë pa crash recovery** për staging table — në rregull sepse është e hedhshme, fatale nëse e bëtë te tabela reale.
- **Paralelizëm shumë i lartë** rreh disk-un dhe WAL; përtej ngopjes throughput-i *bie*. Benchmark-oni pikën e ëmbël.
- **Rindërtimi i indexes ka nevojë për `maintenance_work_mem`/hapësirë temp**; një index build me 100M rreshta mund të derdhet në disk.
- **CSV i pistë** (encoding i keq, delimiters të futur) dështon një chunk të tërë — validoni tipat në staging, karantinoni refuzimet, mbajeni ngarkesën në lëvizje.

Pse INSERT rresht-për-rresht është vegla e gabuar

Pjesët lëvizëse

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme