RDB vs NoSQL 선택 기준

데이터 구조가 자주 변하는가?
├── Yes → Document DB (MongoDB)
└── No
    ├── 복잡한 조인이 많은가?
    │   ├── Yes → RDB (Oracle, MySQL, PostgreSQL)
    │   └── No
    │       ├── 초고속 읽기/쓰기가 필요한가?
    │       │   ├── Yes → Key-Value (Redis)
    │       │   └── No
    │       │       ├── 관계 탐색이 핵심인가?
    │       │       │   ├── Yes → Graph DB (Neo4j)
    │       │       │   └── No → Wide-Column (Cassandra)
    │       │       └──
    │       └──
    └──

클라이언트
┌──────────┐
│ 요청 시작│
└────┬─────┘
     ▼
┌────────────┐
│ 캐시(Redis)│
└────┬───────┘
     ├─ 캐시 히트 → 응답 < 1ms
     └─ 캐시 미스 → RDB 조회
                    ┌─────────┐
                    │   RDB   │
                    └─────────┘
                    응답 5~50ms

전략
  1차: 인메모리 캐시 (Redis) → 자주 조회되는 데이터
  2차: 읽기 레플리카 → 읽기 부하 분산
  3차: CDN → 정적 데이터 (이미지, 파일)

1. 금융 거래
   A계좌 출금과 B계좌 입금이 원자적으로 처리되어야 함
   중간 상태(A만 출금됨)가 관찰되면 안 됨
   → RDB의 ACID 트랜잭션 필수

2. 재고 관리
   마지막 1개 상품을 두 사람이 동시에 주문할 수 없음
   재고가 음수가 되면 안 됨
   → 강한 일관성과 동시성 제어 필요

3. 예약 시스템
   같은 좌석을 두 사람에게 배정하면 안 됨
   → 유니크 제약과 트랜잭션 필요

┌─────────────────────────────────────────────────────┐
│ 스케일 업 (Scale Up): 더 강력한 서버 사용           │
│  * CPU, 메모리, 디스크 업그레이드                   │
│  * 하드웨어 한계가 있음 (물리적 제약)               │
│  * RDB에 적합 (아키텍처가 단일 서버에 최적화)       │
│  * 비용: 고성능 서버일수록 기하급수적으로 비싸짐    │
├─────────────────────────────────────────────────────┤
│ 스케일 아웃 (Scale Out): 서버를 여러 대 추가        │
│  * 수평적 확장, 이론상 무한                         │
│  * 범용 서버로 구성 가능 (비용 효율적)              │
│  * NoSQL에 적합 (분산 아키텍처 설계)                │
│  * 복잡도: 데이터 분산과 동기화 로직 필요           │
└─────────────────────────────────────────────────────┘

┌────────────────┬─────────────┬───────────────────┐
│ 데이터 규모    │    권장     │       이유        │
├────────────────┼─────────────┼───────────────────┤
│ 수 GB ~ 수 TB  │     RDB     │ 단일 서버로 충분  │
│ 수 TB ~ 수십 TB│ RDB + 샤딩  │ 파티셔닝으로 분산 │
│ 수백 TB 이상   │ NoSQL       │ 네이티브 분산 필요│
│ PB 이상        │Hadoop 생태계│ 배치 처리 중심    │
└────────────────┴─────────────┴───────────────────┘

대부분의 서비스는 수 TB 이내이므로 RDB로 충분합니다.
"우리 서비스가 페이스북 규모가 될 것이다"라고
미리 예측하여 NoSQL을 선택하는 것은 위험합니다.

┌───────────────────────────────────────────┐
│              이커머스 플랫폼              │
├──────────────┬───────────┬────────────────┤
│ 상품 카탈로그│ 주문/결제 │ 추천 엔진      │
│ MongoDB      │ PostgreSQL│ Neo4j          │
│(유연한 스키마)│(ACID 필수)│ (관계 탐색)   │
├──────────────┼───────────┼────────────────┤
│ 세션/캐시    │   검색    │ 로그/분석      │
│ Redis        │ Elastic   │   Cassandra    │
│ (초고속)     │(전문 검색)│ (대량 쓰기)    │
└──────────────┴───────────┴────────────────┘

1. 데이터 변환
   정규화된 테이블 → 비정규화된 문서로 변환
   조인 관계를 임베딩(embedding)으로 재설계
   기존 데이터 이관 스크립트 작성
   NULL 처리 방식 차이 대응

2. 애플리케이션 코드 변경
   SQL 쿼리 → 각 NoSQL API로 변환
   ORM 코드 전면 수정
   트랜잭션 로직 재설계
   에러 핸들링 패턴 변경

3. 운영 체계 변경
   백업/복구 절차 재수립
   모니터링 도구 변경
   DBA 재교육 또는 새 인력 필요
   장애 대응 매뉴얼 재작성

4. 테스트
   데이터 정합성 검증
   성능 벤치마크
   장애 시나리오 테스트
   부하 테스트로 실제 워크로드 시뮬레이션

1. 듀얼 라이트 (Dual Write)
   RDB와 NoSQL에 동시에 쓰기
   → 읽기는 점진적으로 NoSQL로 전환
   → 데이터 일관성 검증 기간 확보

2. CDC (Change Data Capture)
   RDB의 변경 로그를 NoSQL로 실시간 동기화
   → 애플리케이션 코드 수정 최소화
   → Debezium 같은 도구 활용

3. 스트랭글러 패턴 (Strangler Pattern)
   새로운 기능부터 NoSQL로 개발
   기존 기능은 점진적으로 마이그레이션
   → 위험 최소화, 점진적 전환

┌──────────────┬─────────────────┬─────────────────────┐
│     항목     │       RDB       │ NoSQL               │
├──────────────┼─────────────────┼─────────────────────┤
│   라이선스   │ 상용: 비쌈      │ 대부분 오픈소스     │
│              │ 오픈소스: 무료  │ (엔터프라이즈 유료) │
├──────────────┼─────────────────┼─────────────────────┤
│   하드웨어   │ 고성능 단일 서버│ 범용 서버 여러 대   │
│              │ (비싸지만 단순) │ (저렴하지만 수량 多)│
├──────────────┼─────────────────┼─────────────────────┤
│     인력     │ DBA 풍부        │ NoSQL 전문가 부족   │
│              │ SQL 숙련자 많음 │ 기술별 전문성 필요  │
├──────────────┼─────────────────┼─────────────────────┤
│   클라우드   │ RDS, Cloud SQL  │ DynamoDB, Cosmos    │
│   매니지드   │ Aurora          │ Atlas (MongoDB)     │
│              │ (관리 부담 최소)│ (관리 부담 최소)    │
└──────────────┴─────────────────┴─────────────────────┘

기술적 요인:
□ 데이터 구조가 명확한가? → RDB 우선 고려
□ 스키마 변경이 잦을 예정인가? → Document DB 고려
□ 트랜잭션(ACID)이 필수인가? → RDB 필수
□ 예상 데이터 규모가 TB를 넘는가? → NoSQL 검토
□ 초당 쓰기가 만 건을 넘는가? → NoSQL 검토

비기술적 요인:
□ 팀에 해당 DB 경험자가 있는가? → 매우 중요
□ 커뮤니티와 레퍼런스가 충분한가? → 운영 안정성
□ 매니지드 서비스(클라우드)가 있는가? → 운영 비용
□ 장애 발생 시 대응할 수 있는 역량이 있는가? → 리스크
□ 채용 시장에서 해당 DB 전문가를 구할 수 있는가? → 지속성

┌───────────────┬──────────────────────────────────────┐
│     업종      │ 권장 아키텍처                        │
├───────────────┼──────────────────────────────────────┤
│ 금융/은행     │ Oracle/PostgreSQL (ACID 필수)        │
│               │ + Redis (세션/캐시)                  │
├───────────────┼──────────────────────────────────────┤
│   이커머스    │ MySQL/PostgreSQL (주문/결제)         │
│               │ + MongoDB (상품 카탈로그)            │
│               │ + Redis (캐시) + ES (검색)           │
├───────────────┼──────────────────────────────────────┤
│ SNS/미디어    │ MySQL (사용자/관계)                  │
│               │ + Cassandra (타임라인/피드)          │
│               │ + Redis (캐시) + ES (검색)           │
├───────────────┼──────────────────────────────────────┤
│ IoT/센서      │ 시계열 DB (InfluxDB, TimescaleDB)    │
│               │ + Redis (실시간 대시보드)            │
├───────────────┼──────────────────────────────────────┤
│     게임      │ MySQL (계정/결제)                    │
│               │ + Redis (랭킹/세션/실시간 데이터)    │
│               │ + MongoDB (게임 로그)                │
├───────────────┼──────────────────────────────────────┤
│ 스타트업 MVP  │ PostgreSQL + Redis                   │
│               │ (단순 구조로 빠르게 시작)            │
└───────────────┴──────────────────────────────────────┘

조합 1: PostgreSQL + Redis
  → 대부분의 웹 서비스에서 충분
  → RDB로 핵심 데이터, Redis로 캐시/세션

조합 2: PostgreSQL + Elasticsearch
  → 검색 기능이 중요한 서비스
  → RDB로 원본 데이터, ES로 검색 인덱스

조합 3: MySQL + MongoDB + Redis
  → 데이터 특성이 다양한 중대형 서비스
  → RDB로 핵심 비즈니스, MongoDB로 유연한 데이터, Redis로 캐시

┌────────────────────────────────────────────────────────┐
│ 판단 기준 요약                                         │
│                                                        │
│ RDB를 선택하는 경우                                    │
│  * 데이터 구조가 명확하고 안정적                       │
│  * 복잡한 조인과 트랜잭션(ACID)이 필요                 │
│  * 데이터 무결성이 최우선 (금융, 결제)                 │
│  * 데이터 규모가 TB 이내                               │
│                                                        │
│ NoSQL을 선택하는 경우                                  │
│  * 스키마 변경이 잦고 유연성이 필요                    │
│  * 대량의 데이터를 빠르게 읽고/쓰기 (로그, IoT)        │
│  * 수평 확장(스케일 아웃)이 필수                       │
│  * 최종적 일관성으로 충분한 경우                       │
├────────────────────────────────────────────────────────┤
│ 핵심 원칙                                              │
│  * 시작은 RDB (검증된 기술, 풍부한 생태계)             │
│  * 필요가 분명해지면 특정 영역만 NoSQL 도입            │
│  * 폴리글랏 퍼시스턴스는 성숙한 조직에서만             │
│  * "미리 대비"보다 "필요할 때 도입"                    │
└────────────────────────────────────────────────────────┘