Wie exportierst du einen riesigen Datensatz, ohne das Live-System zu beeinträchtigen?

Question

IT Interview Practice · Accepted Answer

**Lies von einer Replica oder einem Snapshot (nie vom Primary), blättere mit Keyset-Pagination statt `OFFSET`, drossle die Leserate und streame die Ergebnisse direkt in Object Storage.** Das Ziel ist, 500M Rows zu exportieren, ohne lange Locks zu halten, die Primary-CPU zu spiken oder den Speicher zu sprengen.

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

## Warum jedes Teil

- **Read Replica oder Snapshot.** Richte den Job auf einen Follower, sodass schwere Reads nie mit Produktions-Writes auf dem Primary konkurrieren. Ein **Snapshot** gibt eine stabile, Point-in-time-Sicht, sodass der Export konsistent ist, selbst während sich Live-Daten weiter ändern.
- **Keyset-Pagination, nicht `OFFSET`.** `OFFSET 10000000` lässt die DB pro Seite 10M Rows scannen und verwerfen - O(n²) über den Export. Keyset merkt sich den letzten Key und macht `WHERE id > :last ORDER BY id LIMIT 5000`, was auf dem Index in O(1) pro Seite reitet.
- **Throttle.** Schlafe zwischen Batches oder deckele Rows/Sek., damit die Replica nicht gesättigt wird und der Replication Lag begrenzt bleibt.
- **Stream in Object Store.** Schreibe jeden Batch als NDJSON oder Parquet nach S3/GCS; lade nie das gesamte Result Set in den Speicher. Nutze einen Cursor/Server-side Cursor, damit der Treiber Rows streamt.

## Interview-Perspektive

Der Interviewer prüft, ob du das Live-System schützt. Eine **Replica** zu benennen ist Grundvoraussetzung; das Senior-Signal ist **Keyset über OFFSET** (und erklären zu können, warum das die O(n²)-Falle ist) plus **Backpressure/Throttling** und **Consistency** über einen Snapshot. Eine häufige Falle: ein einzelnes `SELECT *` in einer Transaktion - es hält eine Read-Sicht stundenlang offen, bläht die DB auf (Postgres Vacuum kann Rows nicht bereinigen, die der lange Snapshot noch sieht) und puffert alles im Speicher.

**Trade-offs:** Eine Replica kann hinterherhinken, sodass der Export einen leicht veralteten Moment widerspiegelt - meist okay für Analytics, nicht für Finanzabgleiche, die exakt-jetzt-Daten brauchen. Keyset braucht einen stabilen, eindeutigen, indexierten Sort Key; es ist unbequem für beliebige Sortierreihenfolgen. Wenn die Tabelle enorm ist und du die Storage-Schicht besitzt, schlägt ein natives Tool (`pg_dump`, Snapshot-Export nach S3, `COPY`) oft handgeschriebenes Paging.

Export-Pipeline

Warum jedes Teil

Interview-Perspektive

Ähnliche Fragen