¿Cómo exportas un dataset enorme sin impactar el sistema en producción?

Question

IT Interview Practice · Accepted Answer

**Lee de una réplica o snapshot (nunca del primary), pagina con keyset pagination en lugar de `OFFSET`, throttlea el ritmo de lectura, y transmite los resultados directamente a object storage.** El objetivo es exportar 500M de filas sin mantener locks largos, sin picar la CPU del primary, ni reventar la memoria.

## Pipeline de exportación

```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 qué cada pieza

- **Read replica o snapshot.** Apunta el job a un follower para que las lecturas pesadas nunca compitan con las escrituras de producción en el primary. Un **snapshot** da una vista estable, point-in-time, para que la exportación sea consistente incluso mientras los datos vivos siguen cambiando.
- **Keyset pagination, no `OFFSET`.** `OFFSET 10000000` hace que la DB escanee y descarte 10M de filas en cada página — O(n²) sobre la exportación. Keyset recuerda la última clave y hace `WHERE id > :last ORDER BY id LIMIT 5000`, que cabalga el índice en O(1) por página.
- **Throttle.** Duerme entre lotes o topa las filas/seg para que la réplica no se sature y el replication lag quede acotado.
- **Transmite al object store.** Escribe cada lote a S3/GCS como NDJSON o Parquet; nunca cargues todo el result set en memoria. Usa un cursor/server-side cursor para que el driver transmita las filas.

## Perspectiva de la entrevista

El entrevistador comprueba si proteges el sistema vivo. Nombrar una **réplica** es lo mínimo; la señal de senior es **keyset sobre OFFSET** (y poder explicar la trampa O(n²)) más **backpressure/throttling** y **consistencia** vía un snapshot. Una trampa común: un único `SELECT *` en una transacción — mantiene una vista de lectura abierta durante horas, infla la DB (el vacuum de Postgres no puede limpiar las filas que el snapshot largo aún ve), y bufferiza todo en memoria.

**Compensaciones:** una réplica puede ir con lag, así que la exportación refleja un momento ligeramente obsoleto — normalmente bien para analítica, no para conciliación financiera que necesita datos exactos-de-ahora. Keyset necesita una sort key estable, única e indexada; es incómodo para órdenes de sort arbitrarios. Cuando la tabla es enorme y eres dueño de la capa de almacenamiento, una herramienta nativa (`pg_dump`, export de snapshot a S3, `COPY`) a menudo le gana al paginado hecho a mano.

Pipeline de exportación

Por qué cada pieza

Perspectiva de la entrevista

Preguntas relacionadas