NoSQL 유형별 특성
NoSQL은 하나의 기술이 아니라, 관계형이 아닌 다양한 데이터 모델의 총칭입니다. 각 유형은 특정 문제를 해결하기 위해 설계되었으며, 데이터 모델과 접근 패턴에 따라 적합한 유형이 다릅니다.
Key-Value Store
가장 단순한 형태입니다. 키로 값을 저장하고 조회합니다. 해시 테이블과 같은 원리입니다.
| 대표 제품 | 특징 |
|---|---|
| Redis | 인메모리, 초고속, 다양한 자료구조 (String, List, Set, Hash, Sorted Set) |
| DynamoDB | AWS 관리형, 자동 스케일링, Partition Key + Sort Key |
| Memcached | 단순 캐시, 분산, 멀티스레드 |
| etcd | 분산 설정 저장소, Kubernetes가 사용 |
Redis 자료구조
적합한 사용 사례: 세션 저장, 캐싱, 실시간 순위표, 장바구니, 분산 락, 메시지 큐
Document Store
JSON/BSON 형태의 문서(Document)를 저장합니다. 중첩 구조를 자연스럽게 표현할 수 있습니다.
| 대표 제품 | 특징 |
|---|---|
| MongoDB | 가장 인기, 유연한 스키마, 강력한 쿼리/집계, 인덱스 지원 |
| CouchDB | HTTP API, 오프라인 동기화, MapReduce |
| Firestore | Google Cloud, 실시간 동기화, 모바일 최적 |
MongoDB 쿼리
삽입
db.orders.insertOne({
user: {id: 1001, name: "김철수"},
items: [{product: "노트북", price: 1500000}],
total: 1500000
})
조회
db.orders.find({
"user.id": 1001,
total: {$gte: 100000}
})
수정
db.orders.updateOne(
{_id: "order_001"},
{$set: {status: "delivered"}}
)
집계 파이프라인
db.orders.aggregate([
{$match: {status: "shipped"}},
{$group: {_id: "$user.id", total: {$sum: "$total"}}},
{$sort: {total: -1}},
{$limit: 10}
])적합한 사용 사례: 콘텐츠 관리(CMS), 사용자 프로필, 상품 카탈로그, 로그, 이벤트 저장
Wide-Column Store
행(Row)마다 다른 컬럼을 가질 수 있는 구조입니다. 컬럼 패밀리 단위로 데이터를 저장합니다.
| 대표 제품 | 특징 |
|---|---|
| Cassandra | AP 시스템, 쓰기 최적화, 링 구조, 튜닝 가능 일관성 |
| HBase | Hadoop 기반, CP 시스템, 강한 일관성, HDFS 저장 |
| Google Bigtable | GCP 관리형, 분산, HBase 호환 API |
Cassandra의 특징
적합한 사용 사례: 시계열 데이터, IoT 센서, 로그 분석, 추천 시스템, 메시징
Graph Database
노드(Node)와 관계(Edge)로 데이터를 표현합니다. 관계가 1급 객체(first-class citizen)입니다.
| 대표 제품 | 특징 |
|---|---|
| Neo4j | 가장 인기, Cypher 쿼리 언어, ACID 지원 |
| Amazon Neptune | AWS 관리형, Gremlin/SPARQL 지원 |
| ArangoDB | Multi-Model (Graph + Document + Key-Value) |
Cypher 쿼리 (Neo4j)
적합한 사용 사례: 소셜 네트워크, 추천 엔진, 사기 탐지, 지식 그래프, 네트워크 분석
유형별 비교
| 유형 | 데이터 모델 | 쿼리 유연성 | 확장성 | 일관성 |
|---|---|---|---|---|
| Key-Value | 키:값 | 키 검색만 | 매우 높음 | 설정 가능 |
| Document | JSON 문서 | 높음 (풍부한 쿼리) | 높음 | 설정 가능 |
| Wide-Column | 행:컬럼 패밀리 | 제한적 (PK 기반) | 매우 높음 | 설정 가능 |
| Graph | 노드:엣지 | 관계 탐색 최적 | 보통 | 강함 |
| RDB | 테이블:행:열 | 매우 높음 (SQL) | 보통 | 강함 (ACID) |
CAP 정리와 NoSQL
분산 시스템에서 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성) 세 가지를 동시에 만족시킬 수 없다는 이론입니다.
| 유형 | 대표 제품 | CAP 분류 | 설명 |
|---|---|---|---|
| Key-Value | Redis Cluster | CP | 마스터 장애 시 일시적 불가용 |
| Key-Value | DynamoDB | AP | 튜닝 가능 일관성 (최종 일관성 기본) |
| Document | MongoDB | CP | Primary 장애 시 선거로 새 Primary 선출 |
| Wide-Column | Cassandra | AP | 쿼럼 설정으로 일관성 수준 조절 |
| Wide-Column | HBase | CP | ZooKeeper 기반 강한 일관성 |
| Graph | Neo4j | CA/CP | 클러스터 모드에서 CP |
ACID vs BASE
RDB의 ACID와 대비되는 NoSQL의 BASE 모델입니다.
NewSQL
NoSQL의 확장성과 RDB의 ACID를 결합한 새로운 유형입니다.
| 대표 제품 | 특징 |
|---|---|
| Google Spanner | 글로벌 분산, TrueTime API, 외부 일관성 |
| CockroachDB | PostgreSQL 호환, 자동 샤딩, 서바이벌 |
| TiDB | MySQL 호환, Raft 합의, TiKV 저장 엔진 |
| YugabyteDB | PostgreSQL 호환, 분산 트랜잭션 |
NoSQL 도입 시 고려사항
정리
| 유형 | 대표 제품 | 핵심 특징 | 적합한 데이터 |
|---|---|---|---|
| Key-Value | Redis, DynamoDB | 초고속, 단순 | 세션, 캐시, 카운터 |
| Document | MongoDB, Firestore | 유연 스키마, 풍부한 쿼리 | CMS, 프로필, 카탈로그 |
| Wide-Column | Cassandra, HBase | 대규모 쓰기, 희소 데이터 | 시계열, IoT, 로그 |
| Graph | Neo4j, Neptune | 관계 탐색 최적화 | 소셜, 추천, 사기 탐지 |
| NewSQL | Spanner, CockroachDB | 분산 + ACID + SQL | 글로벌 금융, 대규모 트랜잭션 |
NoSQL 유형 선택의 핵심은 데이터 접근 패턴입니다. 어떤 쿼리를 가장 자주 실행하는가에 맞는 데이터 모델을 선택해야 합니다. RDB가 만능이 아니듯, NoSQL도 만능이 아닙니다. 각 유형의 강점과 한계를 이해하고 적재적소에 활용하는 것이 중요합니다.
CAP 정리는 분산 DB 선택의 이론적 근거를 제공합니다. CP 시스템은 일관성, AP 시스템은 가용성에 우선순위를 둡니다. 실무에서는 대부분의 NoSQL이 일관성 수준을 튜닝할 수 있으므로 절대적 분류보다는 기본 성향으로 이해하는 것이 적절합니다.
시험에서는 각 NoSQL 유형의 대표 제품, 데이터 모델 특성, CAP 분류, ACID vs BASE 차이가 자주 출제됩니다. 특히 Key-Value Store와 Document Store의 적합한 사용 사례를 구분하는 문제, Wide-Column Store가 시계열 데이터에 적합한 이유(쓰기 최적화, 파티션 기반 분산), Graph DB가 다단계 관계 탐색에서 RDB보다 우수한 이유(인접 리스트 저장 구조, 인덱스 프리 인접성)를 명확히 이해해야 합니다.
또한 Polyglot Persistence(다중 저장소 전략)가 현대 시스템의 표준이라는 점도 기억해야 합니다. 하나의 DB로 모든 요구를 충족하기보다, 메인 데이터(RDB), 캐시(Redis), 검색(Elasticsearch), 분석(Cassandra/HBase) 등 용도별로 최적의 저장소를 조합하는 것이 실무의 일반적인 접근입니다.
NewSQL은 NoSQL의 확장성과 RDB의 ACID를 모두 지원하는 차세대 기술로, Google Spanner, CockroachDB, TiDB 등이 대표 제품입니다. NoSQL 유형 분류와 함께 NewSQL의 위치를 파악해두면 전체 데이터베이스 기술 스펙트럼을 이해하는 데 도움이 됩니다.
이러한 다양한 데이터베이스 기술의 존재는 하나의 최적 해가 없다(No One Size Fits All)는 원칙을 증명합니다. 요구사항에 맞는 데이터 모델과 일관성 수준을 선택하는 것이 핵심입니다.
다음 절에서는 분산 데이터베이스의 기초인 레플리케이션과 샤딩을 다루겠습니다.