라이브 시스템에 영향을 주지 않고 거대한 데이터셋을 어떻게 export하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**replica나 snapshot에서 읽고(primary는 절대 안 됨), `OFFSET` 대신 keyset 페이지네이션으로 페이징하며, read 속도를 throttle하고, 결과를 object storage로 곧장 스트리밍하십시오.** 목표는 긴 lock을 잡거나 primary CPU를 튀기거나 메모리를 터뜨리지 않고 5억 row를 export하는 것입니다.

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

## 각 구성 요소의 이유

- **Read replica 또는 snapshot.** job을 follower로 향하게 하여 무거운 read가 primary에서 프로덕션 write와 절대 경쟁하지 않게 하십시오. **snapshot**은 안정적인 point-in-time 뷰를 제공하여 라이브 데이터가 계속 변해도 export가 일관됩니다.
- **`OFFSET`이 아니라 keyset 페이지네이션.** `OFFSET 10000000`은 페이지마다 DB가 1천만 row를 스캔하고 버리게 합니다 — export 전체에 걸쳐 O(n²). keyset은 마지막 key를 기억하고 `WHERE id > :last ORDER BY id LIMIT 5000`을 수행하여 페이지당 O(1)로 인덱스를 탑니다.
- **Throttle.** batch 사이에 sleep하거나 초당 row를 제한하여 replica가 포화되지 않고 복제 지연이 제한되게 하십시오.
- **object store로 스트리밍.** 각 batch를 S3/GCS에 NDJSON이나 Parquet로 write하고, 전체 결과셋을 메모리에 절대 로드하지 마십시오. 드라이버가 row를 스트리밍하도록 cursor/server-side cursor를 쓰십시오.

## 면접 관점

면접관은 당신이 라이브 시스템을 보호하는지 확인합니다. **replica**를 짚는 것은 기본이고, 시니어 신호는 **OFFSET 대신 keyset**(그리고 O(n²) 함정을 설명할 수 있는 것)에 더해 **백프레셔/throttling**과 snapshot을 통한 **일관성**입니다. 흔한 함정: 하나의 트랜잭션 안의 단일 `SELECT *` — read 뷰를 몇 시간 열어두고, DB를 부풀리며(Postgres vacuum이 긴 snapshot이 여전히 보는 row를 정리할 수 없음), 모든 것을 메모리에 버퍼링합니다.

**트레이드오프:** replica는 지연될 수 있으므로 export는 약간 stale한 순간을 반영합니다 — 보통 분석에는 괜찮지만, 정확한 지금 데이터가 필요한 금융 대사(reconciliation)에는 안 됩니다. keyset은 안정적이고 고유하며 인덱싱된 sort key가 필요합니다. 임의의 정렬 순서에는 어색합니다. 테이블이 거대하고 저장소 계층을 당신이 소유할 때는, 네이티브 도구(`pg_dump`, S3로의 snapshot export, `COPY`)가 손으로 만든 페이징보다 흔히 낫습니다.

Export 파이프라인

각 구성 요소의 이유

면접 관점

관련 질문