핵심 정리

기본값은 RDB, 추가 저장소는 데이터 역할이 달라질 때만 붙입니다.

한 서비스 안에서도 모든 데이터를 같은 방식으로 다루지는 않습니다. 원본과 일관성이 필요한 영역은 RDB에 두고, 구조가 자주 바뀌는 문서나 초고속 조회처럼 성격이 다른 부분만 별도 저장소를 씁니다.

서비스 안의 데이터 역할
추천 저장소
언제 이 저장소가 필요한가
핵심 비즈니스와 원본 데이터

주문, 결제, 회원, 재고처럼 잘못 저장되면 안 되는 정보

기본 선택
RDB

MySQL, PostgreSQL 같은 관계형 DB

정합성과 관계를 가장 안정적으로 지킵니다.
  • 트랜잭션과 제약 조건으로 중간 상태를 막음
  • 조인과 스키마로 데이터 관계를 분명하게 관리
구조가 자주 바뀌는 문서형 데이터

상품 속성, 콘텐츠 메타데이터, 이벤트 문서처럼 필드가 들쭉날쭉한 영역

조건부 추가
MongoDB

유연한 문서 모델이 필요한 경우

스키마 변화 비용을 줄이고 중첩 데이터를 자연스럽게 담습니다.
  • 문서마다 조금씩 다른 구조를 그대로 저장 가능
  • RDB 스키마 변경이 병목일 때만 분리 효과가 큼
세션, 캐시, 초고속 조회

자주 읽는 결과, 로그인 상태, 랭킹처럼 빨라야 하는 임시성 데이터

조건부 추가
Redis

원본 저장소가 아니라 가속층

DB를 대체하지 않고, 느린 읽기와 반복 계산을 줄입니다.
  • 밀리초 단위 응답이 필요한 데이터에 적합
  • 원본은 여전히 RDB에 두고 Redis는 빠르게 꺼내 쓰는 계층
도입 순서
먼저 RDB 하나로 시작
→
실제 병목과 데이터 특성 확인
→
MongoDB·Redis를 필요한 역할에만 추가