Как экспортировать огромный датасет без влияния на живую систему?

Question

IT Interview Practice · Accepted Answer

**Читайте с реплики или снапшота (никогда с primary), листайте через keyset-пагинацию вместо `OFFSET`, троттлите темп чтения и стримьте результаты прямо в объектное хранилище.** Цель — экспортировать 500 млн строк без долгих блокировок, всплеска CPU на primary или взрыва памяти.

## Пайплайн экспорта

```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-реплика или снапшот.** Направьте джоб на follower, чтобы тяжёлые чтения никогда не конкурировали с продовыми записями на primary. **Снапшот** даёт стабильный point-in-time вид, так что экспорт консистентен, даже пока живые данные меняются.
- **Keyset-пагинация, не `OFFSET`.** `OFFSET 10000000` заставляет БД сканировать и отбрасывать 10 млн строк на каждой странице — O(n²) по всему экспорту. Keyset запоминает последний ключ и делает `WHERE id > :last ORDER BY id LIMIT 5000`, что едет по индексу за O(1) на страницу.
- **Троттлинг.** Спите между батчами или ограничивайте строк/с, чтобы реплика не насыщалась, а replication lag оставался ограниченным.
- **Стриминг в объектное хранилище.** Пишите каждый батч в S3/GCS как NDJSON или Parquet; никогда не грузите весь результат в память. Используйте курсор/server-side cursor, чтобы драйвер стримил строки.

## Взгляд с точки зрения интервью

Интервьюер проверяет, защищаете ли вы живую систему. Назвать **реплику** — это база; senior-сигнал — **keyset вместо OFFSET** (и умение объяснить ловушку O(n²)) плюс **backpressure/троттлинг** и **консистентность** через снапшот. Частая ловушка: одиночный `SELECT *` в одной транзакции — он держит read-view открытым часами, раздувает БД (vacuum в Postgres не может вычистить строки, которые всё ещё видит длинный снапшот) и буферизует всё в памяти.

**Компромиссы:** реплика может отставать, так что экспорт отражает слегка устаревший момент — обычно нормально для аналитики, но не для финансовой сверки, которой нужны точные данные на сейчас. Keyset требует стабильного, уникального, индексированного ключа сортировки; он неудобен для произвольных порядков сортировки. Когда таблица огромна и вы владеете слоем хранилища, нативный инструмент (`pg_dump`, экспорт снапшота в S3, `COPY`) часто побеждает самописную пагинацию.

Пайплайн экспорта

Зачем каждая часть

Взгляд с точки зрения интервью

Похожие вопросы