단일 DB vs 샤딩 5개 DB
문제 인식
5년 데이터를 수집하는 도중 DuckDB에 데이터가 들어가지 않는 현상을 발견했습니다. 생각했던 해결책: DB를 5개로 샤딩하면 적재 성능이 향상되지 않을까?
아키텍처 비교
단일 DB 구조
Producer → Kafka → Consumer → [단일 PostgreSQL]
↓
모든 종목 데이터
(AAPL, MSFT, TSLA...)
단일 테이블 or 파티션
- 모든 종목 데이터를 하나의 DB 인스턴스에 저장
- 쿼리 시 JOIN이 자유롭고 트랜잭션 관리가 단순
- 커넥션 풀 하나로 관리 가능
- 소~중규모에서 운영 부담이 적음
샤딩 DB 구조 (검토안)
Producer → Kafka → Consumer → [샤딩 라우터]
↙ ↓ ↘
DB1 DB2 DB3
(AAPL) (MSFT)(TSLA)
DB4 DB5
(NVDA)(AMZN)
- 종목(또는 날짜 범위)을 기준으로 DB를 분리
- 각 DB 인스턴스에 독립적인 커넥션 풀 필요
- 쓰기 작업은 병렬화되지만 샤드 간 JOIN 불가
- 라우팅 로직, 장애 격리, 데이터 리밸런싱 등 운영 복잡도 증가
핵심 차이 요약
| 항목 | 단일 DB | 샤딩 DB |
|---|---|---|
| 구조 복잡도 | 낮음 | 높음 |
| 쓰기 병렬성 | 낮음 | 높음 |
| 쿼리 유연성 | 높음 (자유로운 JOIN) | 낮음 (샤드 내부만) |
| 커넥션 수 | 1개 풀 | 샤드 수만큼 풀 필요 |
| 장애 영향 범위 | 전체 | 해당 샤드만 |
| 적합한 규모 | ~수백만 rows | 수억 rows 이상 |
결론: 단일 DB 유지
이유
- API 호출 자체가 병목 — 현재 yfinance로 일일 데이터를 수집 중이며, 호출 횟수에 제한이 있음
- DB를 여러 개로 쪼개도 API 병목이 먼저 발생하여 DB 분산의 성능 이점이 없음
- 종목 수나 기간이 비약적으로 증가하지 않는다면 단일 DB가 더 효율적
성능 테스트 (종목당 5년치 데이터)
| 종목 | 단일 DB | 샤딩 DB | 차이 |
|---|---|---|---|
| AAPL | 9.41s | 14.38s | +4.97s — 단일 승리 |
| MSFT | 8.27s | 14.03s | +5.76s — 단일 승리 |
| GOOGL | 8.46s | 14.45s | +5.99s — 단일 승리 |
| AMZN | 9.32s | 14.10s | +4.78s — 단일 승리 |
| TSLA | 9.06s | 13.92s | +4.86s — 단일 승리 |
| NVDA | 9.51s | 13.93s | +4.42s — 단일 승리 |
| AMD | 9.24s | 17.36s | +8.13s — 단일 승리 |
| AVGO | 8.67s | 17.80s | +9.13s — 단일 승리 |
단일 DB 최고속: 8.27s vs 샤딩 DB 최저속: 13.92s
결론
샤딩 오버헤드(커넥션 관리, 분산 쿼리)가 성능 향상보다 크게 작용했습니다. **현재 규모에서는 단일 DB 유지.
향후 데이터가 20년치 이상으로 증가하거나 종목 수가 크게 늘어날 경우 샤딩 전환 검토 필요