NoSQL의 등장 배경

모든 데이터를 RDB에 넣어야 하나요? — 트래픽 규모, 데이터 구조, 일관성 요구 수준에 따라 최적의 선택이 달라집니다.

NoSQL(Not Only SQL)은 관계형 데이터베이스만으로는 해결하기 어려운 문제를 다루기 위해 등장했습니다. 2000년대 후반 구글, 아마존, 페이스북 등 대규모 인터넷 서비스 기업들이 주도적으로 개발하기 시작했으며, 현재는 거의 모든 규모의 서비스에서 활용됩니다.

관계형 데이터베이스의 성공과 한계

RDB가 성공한 이유

관계형 데이터베이스는 1970년 에드거 코드(Edgar F. Codd)의 논문에서 시작되어 50년 넘게 데이터 관리의 표준으로 자리 잡았습니다.

RDB의 확장 한계

관계형 데이터베이스는 수십 년간 데이터 저장의 표준이었습니다. 하지만 대규모 트래픽과 비정형 데이터가 폭발적으로 증가하면서 한계가 드러났습니다.

확장 방식	설명	RDB 적합성
스케일 업 (Scale Up)	서버 성능을 높임 (CPU, RAM 추가)	가능하지만 비용이 기하급수적
스케일 아웃 (Scale Out)	서버 수를 늘림 (분산)	어려움 (조인, 트랜잭션 문제)

RDB에서 스케일 아웃이 어려운 이유

새로운 데이터 요구사항

2000년대 이후, 기존 RDB로는 처리하기 어려운 새로운 유형의 데이터가 급증했습니다.

RDB에 맞지 않는 데이터 유형

* 소셜 미디어 게시물 — 스키마가 자주 변함
  사진, 동영상, 리액션, 댓글, 공유... 계속 새로운 필드 추가

* IoT 센서 데이터 — 초당 수만 건 쓰기
  온도, 습도, 위치... 시간 순서로 쌓이기만 함

* 사용자 세션/캐시 — 단순 키-값 조회
  복잡한 관계 불필요, 빠른 읽기/쓰기만 중요

* 소셜 네트워크 관계 — 복잡한 그래프 구조
  "친구의 친구의 친구" 같은 관계 탐색은 JOIN으로 매우 비효율적

* 상품 카탈로그 — 카테고리마다 속성이 다름
  전자제품: 화면크기, 배터리, CPU
  의류: 사이즈, 색상, 소재
  → 정규화하면 테이블이 수백 개

NoSQL의 탄생

Not Only SQL

NoSQL은 No SQL(SQL 없음)이 아니라 Not Only SQL(SQL만이 아닌)을 의미합니다. 관계형 모델을 부정하는 것이 아니라, 특정 용도에 더 적합한 대안을 제공합니다.

NoSQL의 공통 특성

CAP 정리

CAP 정리(CAP Theorem)는 2000년 에릭 브루어(Eric Brewer)가 제안한 이론으로, 분산 시스템에서 세 가지 속성을 동시에 모두 만족할 수 없다는 것을 증명했습니다.

속성	영문	설명
일관성	Consistency	모든 노드가 같은 데이터를 보여줌
가용성	Availability	모든 요청이 응답을 받음
분할 내성	Partition Tolerance	네트워크 단절에도 시스템 동작

각 선택의 의미

CP (일관성 + 분할 내성) 예시

노드 A와 노드 B 사이 네트워크 단절 발생!

CP 시스템의 동작
  사용자 → 노드 A에 쓰기 요청
  노드 A: "노드 B에 복제할 수 없으므로 쓰기를 거부합니다"
  → 일관성 유지, 가용성 희생

  은행 시스템에 적합
  잔액이 다른 노드에서 다르게 보이면 큰 문제!

선택	시스템 예시	적합한 경우
CP	MongoDB, HBase, Redis Cluster	금융, 재고 관리, 예약
AP	Cassandra, DynamoDB, CouchDB	SNS, 로그, 캐시
CA	단일 노드 RDB (PostgreSQL, MySQL)	분산이 불필요한 경우