Jak wyeksportować ogromny zbiór danych bez wpływu na działający system?

Question

IT Interview Practice · Accepted Answer

**Czytaj z repliki lub snapshotu (nigdy z primary), stronicuj przez keyset pagination zamiast `OFFSET`, throttluj tempo odczytu i strumieniuj wyniki wprost do object storage.** Celem jest eksport 500 mln wierszy bez trzymania długich blokad, skoku CPU na primary czy wysadzenia pamięci.

## Pipeline eksportu

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

## Dlaczego każdy element

- **Read replika lub snapshot.** Skieruj zadanie na follower, aby ciężkie odczyty nigdy nie konkurowały z zapisami produkcyjnymi na primary. **Snapshot** daje stabilny, point-in-time widok, więc eksport jest spójny, nawet gdy żywe dane się zmieniają.
- **Keyset pagination, nie `OFFSET`.** `OFFSET 10000000` sprawia, że DB skanuje i odrzuca 10 mln wierszy na każdą stronę — O(n²) przez cały eksport. Keyset pamięta ostatni klucz i robi `WHERE id > :last ORDER BY id LIMIT 5000`, co jedzie po indeksie w O(1) na stronę.
- **Throttle.** Śpij między partiami lub ogranicz wiersze/s, aby replika nie była wysycona, a replication lag pozostał ograniczony.
- **Strumieniuj do object store.** Zapisuj każdą partię do S3/GCS jako NDJSON lub Parquet; nigdy nie ładuj całego wyniku do pamięci. Użyj kursora/kursora po stronie serwera, aby sterownik strumieniował wiersze.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sprawdza, czy chronisz działający system. Nazwanie **repliki** to podstawa; sygnałem seniorskim jest **keyset zamiast OFFSET** (i umiejętność wyjaśnienia pułapki O(n²)) plus **backpressure/throttling** oraz **spójność** przez snapshot. Częsta pułapka: pojedynczy `SELECT *` w jednej transakcji — trzyma widok odczytu otwarty godzinami, rozdmuchuje DB (vacuum Postgres nie może posprzątać wierszy, które długi snapshot wciąż widzi) i buforuje wszystko w pamięci.

**Kompromisy:** replika może być opóźniona, więc eksport odzwierciedla lekko nieświeży moment — zwykle OK dla analityki, nie dla uzgodnień finansowych wymagających danych dokładnie-teraz. Keyset potrzebuje stabilnego, unikatowego, indeksowanego klucza sortowania; jest niewygodny dla dowolnych porządków sortowania. Gdy tabela jest ogromna i posiadasz warstwę magazynu, natywne narzędzie (`pg_dump`, eksport snapshotu do S3, `COPY`) często bije ręcznie klecone stronicowanie.

Pipeline eksportu

Dlaczego każdy element

Perspektywa rozmowy kwalifikacyjnej

Powiązane pytania