NoSQL & Polyglot Persistence

1. Overview

NoSQL 및 폴리글랏 퍼시스턴스(NoSQL & Polyglot Persistence, NPP)는 모든 데이터를 딱딱한 2차원 표(Table) 형태에 억지로 끼워 넣어야 했던 RDBMS 시대의 'One Size Fits All(만능주의)' 패러다임을 타파하고, 데이터의 본질적 형태와 확장성에 맞춤화된 다양한 비관계형(Non-Relational) 데이터 저장 기술을 다룹니다.

JSON 형식의 유연한 도큐먼트(Document), 초고속 인메모리 키-값(Key-Value), 소셜 네트워크의 얽힌 관계를 직관적으로 횡단하는 그래프(Graph), 그리고 수억 개의 시계열 로그를 담는 와이드 컬럼(Wide-Column) 등 4대 NoSQL 모델의 차이를 이해합니다. 학습자는 데이터 정합성(Strong Consistency)을 다소 포기하는 대신 시스템이 폭발적으로 확장할 수 있는 가용성(Availability)을 확보하는 CAP 정리와 최종 일관성(Eventual Consistency) 역학을 습득하며, 여러 종류의 데이터베이스를 적재적소에 혼합하여 시스템을 구축하는 폴리글랏 퍼시스턴스(Polyglot Persistence) 아키텍처 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 4대 NoSQL 데이터 모델 (Data Models): Document DB(MongoDB), Key-Value Store(Redis), Graph DB(Neo4j), Wide-Column Store(Cassandra).
• 분산 시스템 철학과 역학 (Scaling & Consistency): 샤딩(Sharding), 리플리카(Replication)의 리더/팔로워(Leader/Follower) 구조, 가십 프로토콜(Gossip Protocol).
• 가용성 중심의 설계 (Availability Physics): CAP 정리(Consistency, Availability, Partition Tolerance), BASE 이론(Basically Available, Soft State, Eventual Consistency), 쿼럼(Quorum) 기반 분산 합의(N/W/R 설정).
• 폴리글랏 생태계 설계 (Polyglot Architecting): CQRS(Command Query Responsibility Segregation)를 위한 읽기/쓰기 모델 분산 저장, 이종(Heterogeneous) DB 간의 이벤트 기반 데이터 동기화 전술.

Out-of-Scope

• RDBMS의 복잡한 정규화 및 SQL 튜닝: 고도의 B-Tree 복합 인덱스 설계나 트랜잭션의 MVCC 물리량 탐구 → 06-01. Relational Systems 영역으로 위임.
• 분산 트랜잭션의 순수 알고리즘 (2PC, Paxos, Raft): 여러 DB 간에 트랜잭션을 강제로 묶어버리는 분산 커밋/합의 알고리즘 상세 증명 → 07-02. Distributed Systems 영역으로 위임.
• 분석 전용 데이터 웨어하우스(DW): Snowflake나 BigQuery 같은 대규모 오프라인 OLAP 시스템 → 06-07. Lakehouse Architecture 영역으로 위임.

Boundaries

• NPP vs. RS (06-01): RS(Relational)가 '어떻게든 데이터의 절대 무결성과 형태를 지켜내는 깐깐한 금고'라면, NPP(NoSQL)는 '스키마 검증과 트랜잭션 락킹 오버헤드를 집어던져서라도 테라바이트급 데이터를 쏟아붓고 즉시 스캔해 내는 거대한 창고'를 설계합니다.

3. Counterexample

• NoSQL을 RDBMS처럼 설계하는 맹목적 정규화 (Anti-Pattern): MongoDB(문서형 DB)를 도입해 놓고, 마치 관계형 데이터베이스처럼 '게시글', '댓글', '작성자' 컬렉션을 모조리 분리한 뒤 애플리케이션 코드에서 이중 삼중으로 쿼리를 날려 수동 조인(Application Join)을 수행하는 행위. 도큐먼트 DB는 관련된 데이터를 하나의 거대한 JSON 도큐먼트에 비정규화(Denormalization)하여 통째로 쑤셔넣을 때($O(1)$ 단일 조회) 그 진가가 발휘됨을 망각한 것입니다.
• 최종 일관성(Eventual Consistency)에 대한 안전 불감증: 카산드라(Cassandra) 같은 분산 DB에 결제 데이터를 써놓고, 즉시 읽었을 때 과거 데이터가 튀어나오자 시스템 오류라고 패닉에 빠지는 현상. 분산된 노드 전체에 데이터 복제가 끝날 때까지 수 밀리초에서 수 초의 **복제 지연(Replication Lag)**이 발생하는 최종 일관성의 물리적 시차를 서비스 프론트엔드 UI(예: "결제가 진행 중입니다" 스피너 처리)와 백엔드 로직으로 우아하게 가려내지 못하는 것은 설계 결함입니다.

4. Prerequisites

• 관계형 시스템 (Basic): NoSQL이 왜 만들어졌는지 그 태생적 이유를 이해하려면 RDBMS의 트랜잭션 한계와 Join 연산의 확장성 제약을 알아야 합니다. (06-01. RS)
• 핵심 자료 구조 (Basic): 키-값 저장소, 그래프 DB가 데이터를 탐색하는 물리적 논리는 컴퓨터 공학의 기본 자료구조(Hash Map, Graph)와 완전히 직결됩니다. (04-02. CDS)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 4대 NoSQL 데이터 모델 분해 (Taxonomy & Models)

• Why to Learn: 추천 시스템은 그래프 DB로, 장바구니 세션은 키-값 캐시로, 상품 카탈로그는 도큐먼트로 찢어 저장해야 성능의 극한을 뽑아낼 수 있기 때문입니다.
• What to Learn:
  • Concepts: Key-Value Store(키-값 해시 맵), Document Store(중첩 JSON/BSON 모델), Wide-Column Store(수백만 개의 동적 컬럼), Graph DB(노드와 엣지 매핑).
  • Skills: 도메인 요구사항에 따른 최적 DB 매핑 훈련(예: IoT 센서 타임스탬프 → Cassandra, 복잡한 인맥촌 탐색 → Neo4j).
  • Tools: Redis-cli, MongoDB Compass.
  • Trade-offs: 스키마리스(Schema-less) 구조의 눈부신 개발 유연성 및 객체-관계 불일치(Impedance Mismatch) 해소 vs 스키마가 없기 때문에 애플리케이션 코드에 지저분한 데이터 유효성(Validation) 방어 로직이 도배되는 단점.
• How to Learn:
  • 1단계: RDBMS로 만든 '부서-직원-프로젝트' 3개 테이블을 MongoDB의 단일 중첩 JSON 도큐먼트 하나로 욱여넣어보고, 데이터를 가져올 때 단 한 번의 디스크 I/O로 모든 정보를 끝내는 과정을 실습합니다.
  • 2단계: SNS "A가 팔로우하는 B가 좋아하는 C" 같은 3-Depth 관계 탐색을 SQL JOIN으로 짤 때의 지옥 같은 쿼리 복잡도와 연산 비용을, Graph DB의 Cypher 쿼리 1줄로 $O(1)$ 엣지 횡단으로 해결하는 쾌감을 맛봅니다.
• Implement: 특정 도메인(예: 이커머스) 데이터 모델을 4가지 서로 다른 NoSQL 스키마(Key-Value, Document, Column, Graph)로 각각 모델링한 비교 분석 명세서 작성.

Recommended

Core Topic 02: 분산 저장과 쿼럼의 물리 (CAP & Consistency Models)

• Why to Learn: 글로벌 서비스에서 데이터베이스가 3개의 대륙에 분산되어 있을 때, 빛의 속도로 인한 통신 지연(Latency) 속에서도 서버가 죽지 않고 작동하게 하는 물리 법칙을 다루기 위함입니다.
• What to Learn:
  • Concepts: CAP 정리, BASE 모델(Basically Available, Soft state, Eventual consistency), 데이터 복제(Replication)와 샤딩(Sharding/Partitioning).
  • Skills: 읽기 정합성과 쓰기 응답성의 딜레마 제어, N/W/R 쿼럼(Quorum) 수식($W + R > N$)을 활용한 강한 일관성(Strong Consistency) 확보 물리량.
  • Tools: Cassandra 컨시스턴시 레벨 설정 시뮬레이션.
  • Trade-offs: 데이터베이스 클러스터 5대 중 3대에만 써지면 성공(응답) 처리하여 초고속 쓰기 성능(Availability)을 얻는 대신 vs 나머지 2대에 데이터가 도달하기 전에 다른 유저가 읽어버리면 구형 데이터를 보게 되는(Eventual Consistency) 뼈아픈 트레이드오프.
• How to Learn:
  • 1단계: 노드 3대(N=3)로 구성된 클러스터에서 쓰기 쿼럼(W)=1, 읽기 쿼럼(R)=1로 세팅하면 엄청난 속도가 나지만 과거 데이터가 튀어나오고, W=2, R=2로 세팅($2+2>3$)하면 무조건 최신 데이터를 읽어내는 수학적 오버랩 원리를 증명합니다.
  • 2단계: 네트워크가 단절(Partition Tolerance 발생)되었을 때 클러스터가 둘로 쪼개지는 상황(Split Brain)에서, 에러를 내뿜고 시스템을 닫을 것인지(CP 시스템) 과거 데이터라도 뱉어낼 것인지(AP 시스템) 선택하는 아키텍트의 의사 결정을 시뮬레이션합니다.
• Implement: 3개의 독립된 Python 딕셔너리(노드)에 가짜 네트워크 지연을 주고 비동기로 데이터를 복제(Replication)할 때, 쿼럼 W/R 값 설정에 따라 클라이언트가 구형(Stale) 데이터를 읽게 될 확률을 도출하는 쿼럼 검증기.

Practical

Core Topic 03: 읽기 주도 비정규화 전략 (Query-Driven Design)

• Why to Learn: NoSQL은 RDBMS처럼 데이터 정규화를 통해 예쁘게 저장해 놓고 나중에 복잡하게 꺼내보는 시스템이 아니라, "화면에 뿌려줄 데이터 모양을 먼저 정하고" 그대로 욱여넣는 역발상을 해야 하기 때문입니다.
• What to Learn:
  • Concepts: 쿼리 주도 모델링(Query-Driven Modeling), 비정규화(Denormalization), 데이터 중복(Data Duplication).
  • Skills: 중첩(Embedding) vs 참조(Referencing) 도큐먼트 디자인 패턴, 쓰기 확대(Write Amplification) 오버헤드 예측.
  • Tools: NoSQL 데이터 모델링 패턴 가이드북.
  • Trade-offs: 화면이 로딩될 때 데이터베이스가 아무 연산 없이 통째로 데이터를 던져주는 빛의 속도의 읽기(Read) 성능 vs 작성자 이름이 한 번 바뀌면 해당 작성자가 쓴 1만 개의 게시글 도큐먼트를 모두 훑으며 작성자 이름을 업데이트해야 하는 가혹한 쓰기(Write) 오버헤드.
• How to Learn:
  • 1단계: 주문 정보 화면을 구성할 때 필요한 '고객 정보, 배송 정보, 결제 이력, 상품 상세'를 한 덩어리의 JSON 도큐먼트로 묶어 설계하고, 이 도큐먼트를 그대로 Key-Value 스토어에 꽂아 넣는 과정을 실습합니다.
  • 2단계: 데이터 중복 저장으로 인해 업데이트 시 다중 도큐먼트 갱신 실패(Partial Failure)가 발생할 확률을 인지하고, 애플리케이션 코드 내에서 이를 보상(Compensation)하는 재시도 로직을 설계합니다.
• Implement: '상품 목록 조회 뷰'의 읽기 속도를 극대화하기 위해, 여러 도메인 데이터를 비정규화하여 하나의 ViewDocument로 말아두고(Materialize), 원본 데이터가 바뀔 때마다 이를 갱신하는 뷰 파이프라인 목업 코드.

Advanced

Core Topic 04: 폴리글랏 퍼시스턴스와 CQRS 생태계 (Polyglot Architecting)

• Why to Learn: 엔터프라이즈의 거대한 시스템은 결코 단일 DB로 움직이지 않습니다. 결제의 정합성(RDBMS), 장바구니의 속도(Redis), 상품 검색(Elasticsearch)을 하나로 엮어 동기화하는 백엔드 대통합 아키텍처를 지휘하기 위함입니다.
• What to Learn:
  • Concepts: 폴리글랏 퍼시스턴스(Polyglot Persistence), CQRS(명령과 조회의 책임 분리), 변경 데이터 캡처(CDC, Change Data Capture).
  • Skills: 원본 DB(Master/RDB)에 일어난 데이터 변경 이벤트를 Kafka 등 메시지 큐를 통해 다른 NoSQL 읽기 전용 뷰(View) 모델로 비동기 투사(Projection)하는 시스템 설계.
  • Tools: Debezium(CDC 툴), Kafka, Elasticsearch.
  • Trade-offs: 각 도메인의 성격에 딱 맞는 최고 성능의 DB를 골라 쓰는 유토피아적 아키텍처 vs 개발 팀이 4~5종류의 이기종 DB 쿼리어를 모두 배워야 하고, 백그라운드 데이터 동기화 파이프라인 관리 비용이 천문학적으로 솟구치는 운영 지옥.
• How to Learn:
  • 1단계: RDBMS에 User 정보가 갱신(Update)되는 순간, 데이터베이스 트랜잭션 로그(Binlog)를 스니핑(CDC)하여 JSON으로 감싼 뒤 검색 엔진(Elasticsearch) 노드로 동기화 이벤트를 쏘아 올리는 CQRS 파이프라인 구조를 그립니다.
  • 2단계: 메시지 큐 지연으로 인해 읽기 DB(NoSQL)의 데이터 반영이 수 초 늦어지는 이벤트 소싱 환경에서, 사용자가 자기 프로필을 수정하고 '저장'을 눌렀는데 구형 프로필이 보이는 문제를 극복하기 위한 클라이언트(프론트엔드) 낙관적 UI 업데이트 기법을 연계 설계합니다.
• Implement: 메인 메모리 구조(가상 RDBMS)에 쓰기 동작이 발생할 때마다 옵저버 패턴(Observer)을 이용해 비동기 스레드로 역색인 검색 해시맵(가상 Search DB)을 최종 일관성 있게(Eventual) 갱신하는 미니 CQRS 엔진 프레임워크.

7. Terminology

8. References

Primary References

• [P4] DS-BoK - Data Infrastructure & Platforms — Non-relational systems for big data.
• [P1] CS2023 - DM/Scalable & Distributed Data — High availability storage.

Secondary References

• [NoSQL Distilled] Pramod Sadalage & Martin Fowler — Definitive introduction.
• [Seven Databases in Seven Weeks] Luc Perkins et al. — Hands-on various models.

Industry References

• [AWS Database Selection Guide] — Practical polyglot choice examples.
• [MongoDB/Neo4j Official Whitepapers] — Real-world use case architectures.

9. Final Checklist

Primary Checklist

• 데이터의 형태(JSON vs 테이블)에 따라 데이터 무결성 체크 책임이 DB에 있는지 애플리케이션에 있는지 구분 가능한가? (P4)
• 고가용성이 최우선인 시스템에서 왜 강력한 일관성(Strong Consistency)을 포기해야 하는지 물리적 이유를 CAP 이론으로 설명 가능한가? (P1)

Secondary Checklist

• 키-값 저장소(Redis 등)에서 만료 시간(TTL) 설정이 물리 메모리 회수와 시스템 안정성에 미치는 영향을 분석하고 있는가?
• 그래프 데이터베이스에서 다중 홉(Multi-hop) 쿼리가 관계형 DB의 조인 대비 가지는 물리적 연산 효율성을 인지하는가?

Industry Checklist

• 비즈니스 도메인 분석 후, 쓰기 부하가 높은 도메인과 읽기 성능이 중요한 도메인을 분리하여 각기 다른 NoSQL을 배치 제안할 수 있는가? (SFIA)
• 이종 DB 환경에서 데이터 동기화 지연 발생 시 대 사용자 안내 전략이나 보상 트랜잭션의 필요성을 논할 수 있는가?