Como você exporta um dataset enorme sem impactar o sistema em produção?

Question

IT Interview Practice · Accepted Answer

**Leia de uma réplica ou snapshot (nunca do primário), pagine com keyset pagination em vez de `OFFSET`, faça throttle da taxa de leitura, e faça streaming dos resultados direto para object storage.** O objetivo é exportar 500M de linhas sem segurar locks longos, sem picar a CPU do primário ou estourar a memória.

## Pipeline de export

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

## Por que cada peça

- **Read replica ou snapshot.** Aponte o job para um follower para que leituras pesadas nunca compitam com escritas de produção no primário. Um **snapshot** dá uma visão estável e point-in-time para que o export seja consistente mesmo enquanto os dados vivos continuam mudando.
- **Keyset pagination, não `OFFSET`.** `OFFSET 10000000` faz o DB escanear e descartar 10M de linhas a cada página — O(n²) sobre o export. Keyset lembra a última chave e faz `WHERE id > :last ORDER BY id LIMIT 5000`, que percorre o índice em O(1) por página.
- **Throttle.** Faça sleep entre lotes ou limite linhas/seg para que a réplica não sature e o replication lag fique limitado.
- **Stream para object store.** Escreva cada lote no S3/GCS como NDJSON ou Parquet; nunca carregue o result set inteiro na memória. Use um cursor/server-side cursor para que o driver faça streaming das linhas.

## Perspectiva de entrevista

O entrevistador verifica se você protege o sistema em produção. Nomear uma **réplica** é o mínimo; o sinal de senioridade é **keyset em vez de OFFSET** (e conseguir explicar a armadilha O(n²)) mais **backpressure/throttling** e **consistência** via um snapshot. Uma armadilha comum: um único `SELECT *` em uma transação — segura uma read view aberta por horas, incha o DB (o vacuum do Postgres não consegue limpar linhas que o snapshot longo ainda vê) e bufferiza tudo na memória.

**Trade-offs:** uma réplica pode atrasar, então o export reflete um momento levemente stale — geralmente ok para analytics, não para reconciliação financeira que precisa de dados exatos-agora. Keyset precisa de uma chave de ordenação estável, única e indexada; é desajeitado para ordenações arbitrárias. Quando a tabela é enorme e você é dono da camada de armazenamento, uma ferramenta nativa (`pg_dump`, export de snapshot para o S3, `COPY`) frequentemente supera a paginação feita à mão.

Pipeline de export

Por que cada peça

Perspectiva de entrevista

Perguntas relacionadas