როგორ ექსპორტირებთ უზარმაზარ dataset-ს ცოცხალ სისტემაზე ზემოქმედების გარეშე?

Question

IT Interview Practice · Accepted Answer

**წაიკითხეთ replica-დან ან snapshot-იდან (არასდროს primary-დან), გადაფურცლეთ keyset pagination-ით `OFFSET`-ის ნაცვლად, throttle გაუკეთეთ read rate-ს და stream გააკეთეთ შედეგები პირდაპირ object storage-ში.** მიზანია 500M მწკრივის ექსპორტი გრძელი lock-ების დაჭერის, primary CPU-ს spike-ის ან მეხსიერების აფეთქების გარეშე.

## 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-ს, რომ მძიმე read-ები production write-ებს primary-ზე არასდროს ეცილებოდნენ. **Snapshot** სტაბილურ, point-in-time ხედს იძლევა, ასე რომ ექსპორტი თანმიმდევრულია მაშინაც კი, როცა ცოცხალი მონაცემი იცვლება.
- **Keyset pagination, არა `OFFSET`.** `OFFSET 10000000` DB-ს აიძულებს ყოველ გვერდზე 10M მწკრივი დაასკანიროს და გადააგდოს — O(n²) ექსპორტზე. keyset ბოლო გასაღებს იმახსოვრებს და აკეთებს `WHERE id > :last ORDER BY id LIMIT 5000`-ს, რომელიც index-ს მიჰყვება O(1)-ში თითო გვერდზე.
- **Throttle.** დაიძინეთ batch-ებს შორის ან შემოსაზღვრეთ მწკრივი/წამი, რომ replica არ გაჯერდეს და replication lag შემოსაზღვრული დარჩეს.
- **Stream object store-ში.** ჩაწერეთ თითო batch S3/GCS-ში NDJSON ან Parquet-ად; არასდროს ჩატვირთოთ მთელი შედეგი მეხსიერებაში. გამოიყენეთ cursor/server-side cursor, რომ driver მწკრივებს stream-ავდეს.

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

ინტერვიუერი ამოწმებს, იცავთ თუ არა ცოცხალ სისტემას. **replica**-ს დასახელება მინიმუმია; senior სიგნალი არის **keyset over OFFSET** (და O(n²) ხაფანგის ახსნის უნარი) პლუს **backpressure/throttling** და **consistency** snapshot-ით. გავრცელებული ხაფანგი: ერთი `SELECT *` ერთ transaction-ში — ის read view-ს საათებით ღიად ტოვებს, DB-ს ბერავს (Postgres vacuum-ს არ შეუძლია იმ მწკრივების გაწმენდა, რომლებსაც გრძელი snapshot ჯერ ხედავს) და ყველაფერს მეხსიერებაში ბუფერავს.

**ტრეიდ-ოფები:** replica შეიძლება ჩამორჩეს, ამიტომ ექსპორტი ოდნავ ძველ მომენტს ასახავს — ჩვეულებრივ კარგია ანალიტიკისთვის, არა ფინანსური შეჯერებისთვის, რომელსაც ზუსტ-ახლა მონაცემი სჭირდება. keyset-ს სჭირდება სტაბილური, უნიკალური, დაინდექსებული sort key; ის უხერხულია თვითნებური sort წესრიგებისთვის. როცა ცხრილი უზარმაზარია და storage layer-ს ფლობთ, მშობლიური ხელსაწყო (`pg_dump`, snapshot export S3-ში, `COPY`) ხშირად ხელით აწყობილ paging-ს სჯობს.

Export pipeline

რატომ თითო ნაწილი

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

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