ライブシステムに影響を与えずに巨大なデータセットをエクスポートするにはどうしますか？

Question

IT Interview Practice · Accepted Answer

**レプリカまたはスナップショットから読み（決してプライマリからではなく）、`OFFSET` ではなくキーセットページネーションでページングし、読み取りレートをスロットリングし、結果をオブジェクトストレージへ直接ストリームします。** 目標は、長いロックを保持せず、プライマリのCPUをスパイクさせず、メモリを爆発させずに5億行をエクスポートすることです。

## エクスポートパイプライン

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

## 各部品の理由

- **リードレプリカまたはスナップショット。** ジョブをフォロワーに向け、重い読み取りがプライマリで本番の書き込みと競合しないようにします。**スナップショット**は安定したポイントインタイムのビューを与え、ライブデータが変化し続けてもエクスポートが一貫します。
- **`OFFSET` ではなくキーセットページネーション。** `OFFSET 10000000` はページごとにDBに1000万行をスキャンして破棄させます。エクスポート全体でO(n²)です。キーセットは最後のキーを覚えて `WHERE id > :last ORDER BY id LIMIT 5000` を行い、ページあたりO(1)でインデックスに乗ります。
- **スロットリング。** バッチ間にsleepするか行/秒を上限化し、レプリカが飽和せずレプリケーションラグが境界内に留まるようにします。
- **オブジェクトストアへストリーム。** 各バッチをS3/GCSにNDJSONまたはParquetとして書き、結果セット全体を決してメモリにロードしません。カーソル/サーバーサイドカーソルを使ってドライバに行をストリームさせます。

## 面接での観点

面接官は、あなたがライブシステムを保護するかを確認します。**レプリカ**を挙げるのは最低限です。シニアのシグナルは**OFFSETに対するキーセット**（とO(n²)の罠を説明できること）に加え、**バックプレッシャー/スロットリング**とスナップショットによる**一貫性**です。よくある罠：1つのトランザクション内の単一の `SELECT *`。読み取りビューを何時間も開いたままにし、DBを肥大させ（Postgresのvacuumが長いスナップショットが見ている行を掃除できない）、すべてをメモリにバッファリングします。

**トレードオフ：** レプリカは遅れることがあるので、エクスポートはやや陳腐な瞬間を反映します。分析には通常問題ないが、正確な現時点データを要する財務照合には不可です。キーセットは安定した一意のインデックス付きソートキーが必要で、任意のソート順には扱いにくいです。テーブルが巨大でストレージ層を自分で所有する場合、ネイティブツール（`pg_dump`、スナップショットのS3エクスポート、`COPY`）が手作りのページングにしばしば勝ります。

エクスポートパイプライン

各部品の理由

面接での観点

関連する質問