როგორ იმპორტირებთ 100M CSV ჩანაწერს DB-ში სწრაფად?

Question

IT Interview Practice · Accepted Answer

გამოიყენეთ მონაცემთა ბაზის **მშობლიური bulk-load path** (Postgres `COPY`, MySQL `LOAD DATA`), დაყავით ფაილი ნაწილებად, ჩატვირთეთ **პარალელურად** **staging ცხრილში** გამორთული index-ებითა და constraint-ებით, შემდეგ ერთხელ ხელახლა ააგეთ index-ები და merge — და გახადეთ მთელი job **idempotent**, რომ crash-მა განაახლოს მწკრივების დუბლირების გარეშე.

```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` თითო მწკრივზე იხდის round-trip-ს, parse-ს, WAL/redo write-ს და index update-ს **100 მილიონჯერ**. თუნდაც 1ms-ზე თითოზე, ეს ერთ დღეზე მეტია. bulk path-ები იმარჯვებენ ამ ყველაფრის ამორტიზებით: `COPY` მწკრივებს ერთ protocol შეტყობინებაში stream-ავს, WAL-ს batch-ავს და per-statement planning-ს გამოტოვებს. რეალურ hardware-ზე ერთი `COPY` 100k–500k მწკრივს/წამში აკეთებს, INSERT-ის რამდენიმე ათასის წინააღმდეგ.

## მოძრავი ნაწილები

- **Staging ცხრილი ჯერ.** ჩატვირთეთ ერთჯერად ცხრილში (`UNLOGGED` Postgres-ში WAL-ს მთლიანად გამოტოვებს), არასდროს პირდაპირ ცოცხალ ცხრილში. ეს ლოდვას read-ერებისგან იზოლირებს და საშუალებას გაძლევთ, გამოქვეყნებამდე validate გააკეთოთ.
- **გამორთეთ index-ები და constraint-ები ჩატვირთვისას.** ყოველი secondary index და FK check თითო მწკრივზე ხელახლა ფასდება. ჩამოაგდეთ, ჩატვირთეთ, შემდეგ `CREATE INDEX` ერთხელ — index-ის bulk-ად აგება (დახარისხებული) ბევრად იაფია, ვიდრე 100M ინკრემენტული update.
- **Chunk + parallelise.** დაყავით ფაილი byte offset-ით N ნაწილად და გაუშვით N `COPY` stream. throughput I/O-სა და CPU-ს მიხედვით მასშტაბირდება, სანამ დისკს ან WAL-ს გააჯერებთ. N-ი core-ებს/IOPS-ს მიუსადაგეთ, არა "რაც შეიძლება მეტს".
- **Idempotent + resumable.** მონიშნეთ თითო chunk id-ით; აღრიცხეთ, რომელი chunk commit-და. restart-ზე გამოტოვეთ დასრულებული chunk-ები. გამოაქვეყნეთ `INSERT ... ON CONFLICT DO NOTHING/UPDATE`-ით (upsert), რომ ხელახალი გაშვება არასდროს ორმაგად ჩასვამდეს.

## ინტერვიუს პერსპექტივა

ინტერვიუერი ამოწმებს, იცით თუ არა, რომ **bulk path არსებობს** და *რატომ* არის ის რიგებით უფრო სწრაფი — არა COPY syntax. კარგი: "გამოიყენე COPY". შესანიშნავი: "COPY UNLOGGED staging ცხრილში, index-ები ჩამოგდებული, პარალელური chunk-ები, ხელახლა აგება შემდეგ, upsert გამოსაქვეყნებლად, resumable chunk id-ით." კლასიკური ხაფანგი არის INSERT-ების ციკლი (ან ORM `saveAll`) და გაკვირვება, რომ საათებს იღებს; მეორე ხაფანგი — პირდაპირ ცოცხალ ცხრილში ჩატვირთვა და production-ის დაბლოკვა.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **UNLOGGED / no-WAL ნიშნავს crash recovery-ს გარეშე** staging ცხრილისთვის — კარგია, რადგან ის ერთჯერადია, ფატალურია, თუ ეს ნამდვილ ცხრილს გაუკეთეთ.
- **ზედმეტად მაღალი parallel** დისკსა და WAL-ს ტანჯავს; გაჯერების მიღმა throughput *ეცემა*. Benchmark გააკეთეთ ტკბილი წერტილისთვის.
- **Index-ების ხელახლა აგებას სჭირდება `maintenance_work_mem`/temp სივრცე**; 100M-მწკრივიანი index-ის აგება შეიძლება დისკზე გადავიდეს.
- **ბინძური CSV** (ცუდი encoding, ჩაშენებული delimiter-ები) მთელ chunk-ს აფუჭებს — validate გააკეთეთ ტიპებს staging-ში, quarantine გააკეთეთ უარყოფილებს, შეინახეთ ლოდვა მოძრავი.

რატომ არის row-by-row INSERT არასწორი იარაღი

მოძრავი ნაწილები

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები