(CS/컴퓨터공학) RDB vs NoSQL - 스키마·확장성·일관성·운영
✨ 개요
“사용자가 빠르게 늘면 스키마를 어떻게 가져가야 할까?”
“쓰기 폭주에서 확장성은 누가 더 유리할까?”
이 글은 RDB(Relational DB) 와 NoSQL을 스키마/확장성/일관성/운영/비용 관점으로 깔끔히 비교합니다.
1. 한 장 요약
| 항목 | RDB (관계형) | NoSQL (문서/키값/컬럼/그래프) |
|---|---|---|
| 스키마 | 고정 스키마(DDL 선행), 강한 제약 | 유연 스키마(스키마-온-리드/쓰기) |
| 트랜잭션 | 강력한 ACID, JOIN/참조 무결성 | 엔진별 상이: 단일 문서 원자성↑, 분산 다키 ACID 제한적 |
| 확장성 | 수직 확장(Scale-up) 기본, 샤딩은 복잡 | 수평 확장(Scale-out) 기본, 샤딩/리플리카 내장 |
| 일관성 | 기본 강한 일관성(엔진/옵션에 따라 다양한 격리수준) | 최종 일관성 중심(선택적 강/약 조절 가능) |
| 질의 | SQL, JOIN/집계/인덱스 풍부 | 모델별 쿼리 제약(문서/키값/컬럼/그래프에 특화) |
| 사용 사례 | 결제/주문/ERP/재고/리포팅 | 대규모 이벤트 수집, 세션, 캐시, 피드, 카탈로그, IoT |
| 운영/가시성 | 운영 성숙, 표준화↑ | 제품별 상이, 모니터링/튜닝 다양 |
2 스키마 관점: “변화”를 누가 더 잘 버티나?
2.1 RDB
- DDL 중심 고정 스키마: 열 타입/제약(UNIQUE/FOREIGN KEY/NOT NULL)로 데이터 품질 보장.
- 스키마 변경(마이그레이션)은 버전 관리 + 트랜잭션으로 안전히 수행하지만, 대용량 테이블에선 락/다운타임 리스크 → 온라인 마이그레이션 도구 사용(Online DDL, 파티셔닝).
2.2 NoSQL
- 스키마 유연: 문서에 필드가 달라도 수용(스키마 온 리드).
- 장점: 기능 롤아웃/실험에 유리.
- 주의: 애플리케이션이 스키마를 책임 → 유효성 검증/마이그레이션 스크립트는 코드 레벨에서 관리.
결론: 데이터 품질·무결성 우선 → RDB. 빠른 필드 변화/실험 우선 → 문서지향 NoSQL.
3 확장성: 쓰기·읽기·핫파티션
3.1 RDB
- 기본은 Scale-up(CPU/RAM/스토리지 증가).
- 수평 확장(샤딩)은 가능하지만 키 선정·조인 제약·트랜잭션 범위 분리 등 복잡.
- 리드 레플리카로 읽기 확장은 비교적 간단.
3.2 NoSQL
- 샤딩·리플리케이션이 내장(자동/반자동).
- 키 설계가 핵심: 시간·사용자·리전으로 고르게 분산.
- 핫파티션(인기 키에 집중) 방지: 랜덤 접두사, 버킷, 타임버킷(예: yyyyMMDDHH) 등을 사용.
4. 일관성 모델과 CAP 감각
- RDB: 대부분 단일 노드/동기 리플리케이션에서 강한 일관성. 분산 구성(멀티 리전)에서는 지연↑/합의 비용.
- NoSQL: 기본 가용성/파티션 내성을 선호하여 최종 일관성. 필요 시 R/W 보장 레벨(quorum, read-your-writes 등) 선택.
트래픽 특성: 읽기 다수 + 약간의 근실시간성 → 최종 일관성 OK.
금융/권한/재고처럼 정합성 파손이 치명적 → 강한 일관성/RDB(또는 분산 트랜잭션 가능한 엔진) 고려.
5. 데이터 모델별 NoSQL 선택 가이드
| 모델 | 강점 | 예 |
|---|---|---|
| 키-값 | 초고속 조회/캐시/세션 | Redis, DynamoDB(Key-Value) |
| 문서 | 유연 스키마, 중첩 구조, API 백엔드 | MongoDB, Couchbase |
| 와이드컬럼 | 시간축/로그/IoT/분석 파티션 | Cassandra, HBase |
| 그래프 | 관계/연결 중심 질의 | Neo4j, JanusGraph |
쿼리 패턴에서 모델이 결정됩니다. 먼저 “어떤 조회가 가장 많나?”를 쓰고 모델을 고르세요.
6. 인덱스·조인·집계
- RDB: 조인/서브쿼리/윈도 함수 등 강력한 질의. 인덱스는 B+Tree, 파셜/복합/커버링 인덱스 활용.
- NoSQL: 모델별 제약. 문서는 단일 컬렉션 중심, 중첩 구조로 조인 회피(denormalization).
- 보조 인덱스는 가능하지만 쓰기 성능/일관성 비용이 증가 → 읽기 최적화 vs 쓰기 비용의 트레이드오프.
7. 비용·운영·관찰성
- RDB: 백업/리스토어/이중화/장애조치 성숙. 스토리지 IOPS·버퍼풀·쿼리 플랜 튜닝이 핵심.
- NoSQL: 관리형 서비스(서버리스 포함)로 운영 부담↓, 단 워크로드 특성(핫키/파티션) 설계 실패 시 비용 폭증.
- 관찰성: 슬로우 쿼리/핫 파티션/GC/백그라운드 컴팩션을 메트릭으로 모니터링.
8. 스키마 설계 패턴 (요약)
8.1 RDB – 정규화 + 필요한 곳만 비정규화
- 3NF/BCNF로 중복 최소화 → 쓰기 안전성↑
- 조회 빈도가 높은 조인은 뷰/머티리얼라이즈드 뷰/캐시로 완화
8.2 NoSQL – 읽기패턴 기반 드노멀라이제이션
- “한 화면/엔드포인트 = 한 문서”를 목표
- 중첩·배열로 조인 제거, 대신 원천 업데이트 팬아웃(여러 컬렉션/문서 동기화) 전략 필요
9. 마이그레이션 전략 (둘 사이 이동)
- RDB → NoSQL: 1) 액세스 패턴 분석(Top-N 쿼리) → 2) 문서 설계(한 문서로 응답) → 3) 이벤트 소싱/Change Data Capture로 양방향 동기화 → 4) 점진 절체
- NoSQL → RDB: 1) 스키마 추출(샘플링/유효성 스키마 정의) → 2) 정규화 설계 → 3) 배치 변환 + API 이중쓰기 →
10. 하이브리드(폴리글랏 퍼시스턴스)
하나로 끝내려 하지 말 것. 보통은 조합이 정답:
- RDB: 트랜잭션 데이터(주문/결제/정산)
- NoSQL(문서): 사용자 프로필/피드/설정
- NoSQL(키-값): 세션/캐시/레이트리밋
- 검색엔진: 전문검색/추천(Elasticsearch/OpenSearch)
- 변경은 CDC로 검색/캐시/분석에 흘려보내기
11. 안티패턴 빠르게
- RDB에 거대 JSON만 저장(인덱싱/질의 불가)
- NoSQL에 JOIN처럼 쓰기(컬렉션 난립·N+1 네트워크)
- 샤딩키 없이 랜덤 쓰기(핫파티션) 또는 타임스탬프 단일 파티션에 집중
- TTL/보존주기 없이 무한 성장(스토리지/비용 폭탄)
- 스키마 유효성 검증 없이 필드 남발 → 데이터 스웜프