100M CSV records ను ఒక DB లోకి వేగంగా ఎలా import చేస్తారు?

Question

IT Interview Practice · Accepted Answer

database యొక్క **native bulk-load path** (Postgres `COPY`, MySQL `LOAD DATA`) ను వాడండి, file ను chunks గా split చేసి indexes మరియు constraints **disabled** ఉన్న ఒక **staging table** లోకి **parallel గా** load చేయండి, తర్వాత indexes ను ఒకసారి rebuild చేసి merge చేయండి — మరియు ఒక crash duplicate rows లేకుండా resume చేయగలిగేలా మొత్తం job ను **idempotent** చేయండి.

```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 ఎందుకు తప్పు tool

ఒక naive ఒక్కో row కి `INSERT` ఒక round-trip, ఒక parse, ఒక WAL/redo write మరియు ఒక index update ను **100 million సార్లు** pay చేస్తుంది. ఒక్కో దానికి 1ms అయినా అది ఒక రోజు దాటుతుంది. Bulk paths వీటన్నింటినీ amortise చేయడం ద్వారా గెలుస్తాయి: `COPY` rows ను ఒక protocol message లో stream చేస్తుంది, WAL ను batch చేస్తుంది, మరియు per-statement planning ను skip చేస్తుంది. నిజమైన hardware పై ఒక్క `COPY` 100k–500k rows/s చేస్తుంది, INSERT కి కొన్ని వేలతో పోలిస్తే.

## moving parts

- **ముందుగా Staging table.** ఒక throwaway table లోకి load చేయండి (Postgres లో `UNLOGGED` WAL ను పూర్తిగా skip చేస్తుంది), ఎప్పుడూ నేరుగా live table లోకి కాదు. ఇది load ను readers నుండి isolate చేసి publish చేయడానికి ముందు validate చేయనిస్తుంది.
- **load సమయంలో indexes మరియు constraints ను disable చేయండి.** ప్రతి secondary index మరియు FK check ఒక్కో row కి re-evaluate అవుతుంది. వాటిని drop చేసి, load చేసి, తర్వాత `CREATE INDEX` ను ఒకసారి — bulk లో (sorted) ఒక index నిర్మించడం 100M incremental updates కంటే చాలా చవక.
- **Chunk + parallelise.** file ను byte offset ద్వారా N pieces గా split చేసి N `COPY` streams ను run చేయండి. Throughput I/O మరియు CPU తో scale అవుతుంది disk లేదా WAL saturate అయ్యేవరకు. N ను "వీలైనన్ని" కాదు, cores/IOPS కి match చేయండి.
- **Idempotent + resumable.** ప్రతి chunk ను ఒక id తో tag చేయండి; ఏ chunks commit అయ్యాయో record చేయండి. restart పై, done chunks ను skip చేయండి. re-running ఎప్పుడూ double-insert చేయకుండా `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) తో publish చేయండి.

## ఇంటర్వ్యూ దృక్కోణం

ఇంటర్వ్యూయర్ మీకు **bulk path ఉందని** మరియు *ఎందుకు* అది అనేక రెట్లు వేగవంతమో తెలుసా అని check చేస్తారు — COPY syntax కాదు. మంచిది: "COPY వాడండి". గొప్పది: "COPY ను ఒక UNLOGGED staging table లోకి, indexes dropped, parallel chunks, తర్వాత rebuild, publish కోసం upsert, chunk id ద్వారా resumable." Classic ఉచ్చు INSERTs ను loop చేయడం (లేదా ఒక ORM `saveAll`) మరియు అది గంటలు పడుతుందని ఆశ్చర్యపోవడం; రెండవ ఉచ్చు నేరుగా live table లోకి load చేసి production ను block చేయడం.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **UNLOGGED / no-WAL అంటే staging table కి crash recovery లేదు** — అది disposable కాబట్టి పర్వాలేదు, మీరు దాన్ని real table కి చేస్తే ప్రాణాంతకం.
- **Parallel చాలా ఎక్కువ** disk మరియు WAL ను thrash చేస్తుంది; saturation దాటి throughput *పడుతుంది*. sweet spot ను benchmark చేయండి.
- **Indexes ను rebuild చేయడానికి `maintenance_work_mem`/temp space అవసరం**; ఒక 100M-row index build disk కి spill కావచ్చు.
- **Dirty CSV** (bad encoding, embedded delimiters) ఒక మొత్తం chunk ను fail చేస్తుంది — staging లో types ను validate చేయండి, rejects ను quarantine చేయండి, load ను కొనసాగించండి.

row-by-row INSERT ఎందుకు తప్పు tool

moving parts

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు