Brain274. NoSQL (Not Only SQL) 데이터베이스
핵심 인사이트 (3줄 요약)
- 본질: NoSQL은 스키마리스(Schemaless), 수평적 확장(Scale-out), 분산 아키텍처를 특징으로 하는 비관계형 데이터베이스로, RDBMS의 한계를 극복하기 위해 등장했다.
- 가치: 대규모 데이터 처리,灵活的 스키마, 수평적 확장성, 고가용성을 제공하며, 특히 반정형/비정형 데이터 처리와 분산 환경에 적합하다.
- 융합: CAP 정리, BASE 속성, Eventually Consistent, 데이터 모델(키-값, 문서, 컬럼 패밀리, 그래프), 수평 확장과 밀접하게 연관된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
NoSQL(Not Only SQL)은 관계형 데이터베이스(RDBMS)의 한계를 극복하기 위해 등장한 비관계형 데이터베이스를 통칭하는 용어이다. 고정된 스키마가 아닌 유연한 스키마를 가지며, 수평적 확장(Scale-out)이 가능하고, 분산 환경에 최적화된 것이 특징이다.
필요성
인터넷 기업이 다루는 데이터의 양과 종류가 폭발적으로 증가하면서, 전통적 RDBMS의 한계가 드러났다. 수직적 확장(Scale-up)의 한계, 고정 스키마의 경직성, 복잡한 조인의 성능 저하 등이 문제로 지적되었다. NoSQL은 이러한 문제를 해결하기 위해 다양한 데이터 모델과 분산 아키텍처를 제공한다.
배경
NoSQL이라는 용어는 2009년 Johan Oskarsson이组织了了一次聚회에서 처음 사용했다. 이후 Amazon Dynamo, Google BigTable, Facebook Cassandra, MongoDB 등 다양한 NoSQL 데이터베이스가 등장했으며, 각기 다른 데이터 모델과 설계 철학을 가졌다.
비유
NoSQL은大型超市의 상품 진열대와 같다. 관계형 DB가 각Kategorie严格的하게 분류한 진열대라면, NoSQL은 카테고리에 관계없이 빠르게 진열하고 쉽게 재배치할 수 있는 유연한 진열대이다. 하지만 정확한商品 검색에는 관계형 DB가 эффектив적이다.
📢 섹션 요약: NoSQL은 스키마리스, 수평적 확장, 분산 아키텍처를 특징으로 하는 비관계형 데이터베이스로, RDBMS의 한계를 극복하고 대규모 데이터를 효율적으로 처리한다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
NoSQL의 네 가지 데이터 모델
┌─────────────────────────────────────────────────────────────────────────────┐
│ NoSQL 네 가지 데이터 모델 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 키-값 저장소 (Key-Value Store) │
│ ───────────────────────────────────── │
│ • 가장 단순한 모델: 키와 값의 쌍 │
│ • 예: Redis, Memcached, DynamoDB │
│ • 적합: 세션 관리, 캐시, 간단한 설정 저장 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ ┌──────────┬──────────┐ │ │
│ │ │ Key │ Value │ │ │
│ │ ├──────────┼──────────┤ │ │
│ │ │ user:001 │ {name:Kim} │ │ │
│ │ │ user:002 │ {name:Lee} │ │ │
│ │ │ session:x│ "data..." │ │ │
│ │ └──────────┴──────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ 2. 문서 저장소 (Document Store) │
│ ───────────────────────────────────── │
│ • JSON/XML 형태의 문서를 저장 │
│ • 예: MongoDB, CouchDB │
│ • 적합: 반정형 데이터, 마이크로서비스, 카탈로그 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ "_id": "1", │ │
│ │ "name": "Kim", │ │
│ │ "email": "kim@test.com", │ │
│ │ "orders": [ │ │
│ │ {"order_id": "O001", "amount": 100}, │ │
│ │ {"order_id": "O002", "amount": 200} │ │
│ │ ] │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ 3. 컬럼 패밀리 저장소 (Column Family Store) │
│ ──────────────────────────────────────────── │
│ • 와이드 컬럼(Wide Column) 모델 │
│ • 예: Cassandra, HBase │
│ • 적합: 시계열 데이터, 로그, 대량 읽기/쓰기 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Row Key: user:001 │ │
│ │ ┌──────────────────┬──────────────────┬──────────────────┐ │ │
│ │ │ name (Column) │ email (Column) │ orders (Column) │ │ │
│ │ ├──────────────────┼──────────────────┼──────────────────┤ │ │
│ │ │ Kim (Value) │ kim@test.com │ O001:100 │ │ │
│ │ │ │ │ O002:200 │ │ │
│ │ └──────────────────┴──────────────────┴──────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ 4. 그래프 저장소 (Graph Store) │
│ ────────────────────────────── │
│ • 노드, 엣지, 속성으로 구성 │
│ • 예: Neo4j, Amazon Neptune │
│ • 적합: 소셜 네트워크, 추천 시스템, 사기 탐지 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ (Kim) ──friend──▶ (Lee) │ │
│ │ │ │ │ │
│ │ friend friend │ │
│ │ ▼ ▼ │ │
│ │ (Park) ──friend──▶ (Choi) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
NoSQL vs RDBMS 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ NoSQL vs RDBMS 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 항목 │ RDBMS │ NoSQL │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 데이터 모델 │ 고정 스키마 (정형) │灵活的 스키마 (반정형/ │ │
│ │ │ (테이블) │ 비정형) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 查询 언어 │ 표준 SQL │ 다양 (각 시스템마다 │ │
│ │ │ │ 자체 언어/API) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 확장성 │ 수직적 (Scale-up) │ 수평적 (Scale-out) │ │
│ │ │ 대규모 서버 증설 │ 노드 추가 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 일관성 모델 │ 강철 일관성 (ACID) │ 결과적 일관성 (BASE) │ │
│ │ │ │ ( tunable) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 트랜잭션 지원 │ 완전한 ACID │ 제한적 (많은 경우) │ │
│ │ │ │ (Saga 등) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 적합 데이터 │ 정형 데이터, 복잡한 │ 반정형/비정형 데이터, │ │
│ │ │ 관계와 조인 필요 │ 단순 모델, 대량 처리 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 예시 │ Oracle, PostgreSQL, │ MongoDB, Cassandra, │ │
│ │ │ MySQL │ Redis, Neo4j │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
│ ※ NoSQL과 RDBMS는 상호 배타적이지 않으며, 각각 다른 용도에 적합하다. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
CAP 정리 관점에서의 NoSQL
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 정리 관점에서의 NoSQL 분류 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ CP 시스템 (Consistency + Partition Tolerance): │
│ ───────────────────────────────────────────────── │
│ • MongoDB: Master-Slave 구조에서 Master 장애 시 읽기 불가until 새로운 │
│ Master 선출 │
│ • HBase: 파티션 발생 시 읽기/쓰기 일시 중단 │
│ │
│ AP 시스템 (Availability + Partition Tolerance): │
│ ───────────────────────────────────────────────── │
│ • Cassandra: 파티션 발생 시에도 모든 노드가 응답 │
│ • DynamoDB: 파티션 발생 시에도 읽기/쓰기 가능 │
│ • CouchDB: Eventually consistent │
│ │
│ ※ 하나의 시스템도 설정에 따라 CP 또는 AP로 동작 가능 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] NoSQL 데이터베이스는 CAP 정리에 따라 CP 또는 AP 시스템으로 분류될 수 있다. MongoDB와 HBase는 CP 시스템에 가깝고, Cassandra와 DynamoDB는 AP 시스템에 가깝다. 그러나 Tunable Consistency 기능을 통해 동작 특성을 조절할 수 있다.
📢 섹션 요약: NoSQL은 네 가지 데이터 모델(키-값, 문서, 컬럼 패밀리, 그래프)로 구성되며, CAP 관점에서 CP 또는 AP 시스템에 해당하고, RDBMS와 상호 보완적 관계이다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
데이터 모델 선택 가이드
┌─────────────────────────────────────────────────────────────────────────────┐
│ NoSQL 데이터 모델 선택 가이드 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ✅ 키-값 저장소 선택: │
│ ───────────────────── │
│ • 단순한 데이터 구조 (세션, 장바구니, 캐시) │
│ •极高的 읽기/쓰기 성능 필요 │
│ • 예: Redis (메모리 KV), Memcached (분산 캐시) │
│ │
│ ✅ 문서 저장소 선택: │
│ ───────────────────── │
│ • 다양한 속성을 가진 데이터 (카탈로그, 사용자 프로필) │
│ • 자주 변경되는 스키마 │
│ • 예: MongoDB (범용), CouchDB (충실성) │
│ │
│ ✅ 컬럼 패밀리 저장소 선택: │
│ ───────────────────────── │
│ • 시계열 데이터, 로그 데이터 │
│ • 대량 읽기/쓰기 작업 │
│ • 예: Cassandra (범용), HBase (Hadoop 통합) │
│ │
│ ✅ 그래프 저장소 선택: │
│ ───────────────────── │
│ • 관계 중심 데이터 (소셜, 추천, 사기 탐지) │
│ • 복잡한 관계 탐색 (친구 친구 찾기, 최단 경로) │
│ • 예: Neo4j (범용), Neptune (AWS 관리형) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
다중 모델 데이터베이스
┌─────────────────────────────────────────────────────────────────────────────┐
│ 다중 모델 데이터베이스 예시 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ArangoDB: │
│ ───────── │
│ • 문서 + 그래프 모델 │
│ • AQL (ArangoDB Query Language) 통합 │
│ • 예: 문서와 그래프를 함께 활용하는 추천 시스템 │
│ │
│ Azure Cosmos DB: │
│ ────────────────── │
│ • 문서 + 키-값 + 그래프 + 컬럼 패밀리 │
│ • 다중 API (SQL, MongoDB, Cassandra, Gremlin) │
│ • 글로벌 분산 + tunable consistency │
│ │
│ Amazon DocumentDB: │
│ ────────────────── │
│ • MongoDB 호환 문서 저장소 │
│ • 완전 관리형 서비스 │
│ │
│ MarkLogic: │
│ ───────── │
│ • 문서 + 시맨틱 (RDF triples) │
│ • 내장 검색 엔진 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: NoSQL 데이터 모델 선택은 사용 사례의 특성에 따라 달라지며, 다중 모델 DB를 활용하면 다양한 데이터 모델을 단일 플랫폼에서 사용할 수 있다.
Ⅳ. 결론
NoSQL은 RDBMS의 한계를克服한 비관계형 데이터베이스로, 네 가지 데이터 모델(키-값, 문서, 컬럼 패밀리, 그래프)을 제공한다. 각각 다른 특장과 적합한 용도가 있으므로, 시스템 요구사항에 맞게 올바른 데이터 모델을 선택하는 것이 중요하다. 또한 다중 모델 DB를 활용하면 다양한 데이터 모델을 단일 플랫폼에서 사용할 수 있다.
📢 섹션 요약: NoSQL은 네 가지 데이터 모델로 구성되며, 각 모델이 서로 다른 특장과 용도를 가진다. 시스템 요구사항에 맞는 올바른 선택이 중요하다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ NoSQL Database Concept Map │
│ │
│ ┌───────────────────────────┐ │
│ │ NoSQL Database │ │
│ │ (Not Only SQL) │ │
│ └───────────┬───────────────┘ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Key-Value│ │ Document │ │Column │ │
│ │ (키-값) │ │ (문서) │ │Family(컬럼)│ │
│ │ Redis等 │ │MongoDB等│ │Cassandra等│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Graph │ │
│ │ (그래프)│ │
│ │ Neo4j等 │ │
│ └─────────┘ │
│ │
│ 공통 특징: 스키마리스 | 수평 확장 | 분산 아키텍처 | BASE 속성 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- NoSQL은 스키마리스, 수평적 확장, 분산 아키텍처를 특징으로 한다.
- 네 가지 주요 데이터 모델: 키-값, 문서, 컬럼 패밀리, 그래프가 있다.
- CAP 관점에서 CP 또는 AP 시스템에 해당한다.
- RDBMS와 상호 보완적이며, 각각 다른 용도에 적합하다.