데이터 저장소 선택

학습 목표

RDB와 NoSQL 의 강점·한계를 아키텍처 관점에서 비교할 수 있다.

워크로드(트랜잭션·스키마·읽기/쓰기·관계)별 저장소 선택 기준을 설명할 수 있다.

Polyglot persistence — 서비스마다 다른 DB — 의 이유와 비용을 설명할 수 있다.

CAP·일관성 결정과 저장소 선택을 연결할 수 있다.

문제 상황

• 주문·결제는 ACID 필수인데 전사 MongoDB 일괄 도입 — 환불·정산 불일치
• 상품 카탈로그 스키마가 매주 바뀌는데 ALTER 배포가 월 1회 — 릴리스 막힘
• 피드 타임라인 쓰기 TPS 8만 — 단일 PostgreSQL WAL·connection 한계
• MSA 7편 DB per service인데 모든 서비스가 같은 MySQL 인스턴스 — 결합 그대로
• Elasticsearch에 주문 저장 — 트랜잭션 없음, 중복 결제 방어 실패
• "NoSQL이 빠르다" — 쿼리 패턴·일관성 없이 벤더만 선택

분산·통신·복원력까지 봤다. 데이터를 어디에 어떤 형태로 둘지가 다음 구조 결정이다.

1. 저장소 선택이 아키텍처인가

저장소는 변경 비용이 큰 결정 — 스키마·쿼리·운영·팀 스킬이 오래 묶인다.

관점	질문
도메인	무엇이 진실(source of truth) 인가
일관성	strong TX vs eventual
접근 패턴	key lookup · range · join · graph · search
규모	단일 노드 vs partition
운영	백업·복제·마이그레이션 누가 하나

• 품질 속성 — 성능·가용성·유지보수성이 저장소에 다르게 실현
• Database 시리즈 — 내부 메커니즘; 여기서는 시스템 조립·선택

2. RDB (관계형)

RDB — 스키마·SQL·ACID 트랜잭션·join 중심.

강점	한계
ACID·제약 (FK, unique)	수평 확장 어려움 (shard 설계 비용)
복잡 쿼리·리포트	스키마 변경 배포 부담
성숙 운영·도구	쓰기 집중 단일 primary 병목
팀 친숙	유연 문서 모델에 비효율

잘 맞는 워크로드	예
금융·주문·재고 원장	PostgreSQL, MySQL
다대다 관계·집계	SQL join
강한 일관성 단일 bounded context	모놀리스 core

-- order + payment in one TX (conceptual)
BEGIN;
  INSERT INTO orders (id, user_id, total) VALUES (...);
  INSERT INTO payments (order_id, amount, status) VALUES (...);
COMMIT;

3. NoSQL 계열

NoSQL — 한 가지 모델에 특화, 스케일·유연성 트레이드오프.

유형	모델	대표	특징
Document	JSON 문서	MongoDB, DynamoDB	스키마 유연, aggregate 단위
Key-value	k → v	Redis, DynamoDB	초저지연 lookup, TTL
Wide-column	partition + sort key	Cassandra, HBase	쓰기·partition scale
Graph	node·edge	Neo4j	관계 탐색·추천
Search	inverted index	Elasticsearch	전문 검색 (보조 저장소)

• NoSQL ≠ 항상 빠름 — access pattern 맞을 때 이득
• 일관성·트랜잭션 수준은 제품마다 다름 — CAP 편과 연결

4. 워크로드별 선택

워크로드 신호	1차 후보	주의
다단계 TX·정합성	RDB	cross-service TX 지양
문서 단위 read/write	Document	join 많으면 RDB
세션·rate limit·cache	Key-value	영속 원장 아님
시계열·이벤트 log	Wide-column / TS DB	보관·compaction
소셜·추천 관계	Graph	운영·스케일 비용
검색·자동완성	Search	source of truth 별도

결정 질문 (순서)

1. Source of truth가 하나인가 — 복제·캐시와 구분
2. Read vs write 비율·hot key
3. Consistency — 사용자가 stale을 허용하는가
4. Query — ad-hoc SQL vs 고정 access pattern
5. 팀 — 운영·튜닝 역량

• 한 저장소로 전부 vs 역할 분리 — 후자가 흔하지만 운영 표면적 증가

5. Polyglot persistence

Polyglot persistence — 서비스·워크로드마다 최적 저장소.

order service     → PostgreSQL   (ACID, ledger)
catalog service   → MongoDB      (flexible product doc)
inventory service → PostgreSQL   (stock TX)
session / cart    → Redis        (TTL, fast lookup)
search service    → Elasticsearch (read model, index)
analytics         → columnar / warehouse (batch)

이점	비용
적합 모델·스케일	N종 백업·모니터링
장애 격리 (DB per service)	데이터 최종 일관성·동기화
팀 자율 선택	스킬·라이선스 분산

• MSA DB per service — 인스턴스 분리가 아니라 소유권·스키마 분리
• 공유 DB 안티패턴 — 결합·스키마 전쟁
• CQRS — write RDB + read search/cache — 다음 캐시·CDC 편과 맞물림

6. 안티패턴

안티패턴	결과
기술 먼저 ( "우리 Redis 쓴다" )	도메인 부적합
ES/Mongo에 원장	TX·감사 실패
Cross-DB 2PC 남용	가용성·복잡도
ORM이 모든 DB를 RDB처럼	성능·쿼리 낭비
마이그레이션 없는 스키마 유연	데이터 부채

7. 실무 체크리스트

질문	좋은 답
진실 저장소는?	하나 명시, 나머지 파생
TX 경계?	서비스·aggregate 안
일관성 SLA?	strong / eventual 문서화
스케일 축?	read replica · shard · 다른 store
운영 준비?	backup·PITR·runbook
ADR?	후보·거절 이유 기록

조합	예
RDB + Redis	cache-aside (다음 편)
RDB + ES	catalog search index
RDB + Kafka	event log (CDC 편)

8. 정리

• RDB — ACID·join·원장에 강함
• NoSQL — 패턴 맞을 때 scale·유연성
• 워크로드·일관성·운영으로 선택 — 유행 아님
• Polyglot — MSA에서 자연스럽지만 비용 인지
• 다음 — 캐싱 전략

다음에 다룰 것

• 캐싱 전략
• cache-aside, TTL, invalidation, Redis

---

해당 내용은 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 및 Designing Data-Intensive Applications (Martin Kleppmann) 의 내용을 기반으로 합니다.