NoSQL 유형별 특성
NoSQL은 하나의 기술이 아니라, 관계형 모델만으로 다루기 까다로운 접근 패턴을 위해 발전한 여러 데이터 모델의 묶음입니다. 어떤 유형이 더 낫다기보다, 데이터가 저장되는 모양과 가장 자주 실행되는 조회 경로가 무엇인지에 따라 선택 기준이 달라집니다.
Key-Value Store
가장 단순한 형태입니다. 키로 값을 저장하고 조회하며, 값은 문자열, JSON, 바이너리, 자료구조처럼 제품별로 다양한 형태가 될 수 있습니다. 핵심은 복잡한 조인보다 키를 통한 빠른 접근입니다.
| 대표 제품 | 특징 |
|---|---|
| Redis | 인메모리 중심, 다양한 자료구조(String, Hash, List, Set, Sorted Set 등) |
| DynamoDB | AWS 관리형, Partition Key/Sort Key 기반 접근, 일관성 옵션 제공 |
| Memcached | 단순 캐시, 분산, 멀티스레드 |
| etcd | Raft 기반 분산 Key-Value 저장소, 설정/서비스 디스커버리에 활용 |
Redis 자료구조
적합한 사용 사례: 세션 저장, 캐싱, 실시간 순위표, 장바구니, 짧은 수명 토큰, 작업 큐 보조
Document Store
JSON/BSON 형태의 문서(Document)를 저장합니다. 함께 읽고 쓰는 데이터를 한 문서에 묶기 좋아서, 중첩 구조와 유연한 필드를 자연스럽게 표현할 수 있습니다.
| 대표 제품 | 특징 |
|---|---|
| MongoDB | 대표적인 문서 DB, 유연한 스키마, 쿼리/집계/인덱스 지원 |
| CouchDB | HTTP API, 복제와 오프라인 동기화 지향 |
| Firestore | Google Cloud 관리형, 실시간 동기화와 모바일 앱 친화 |
MongoDB 쿼리
삽입
db.orders.insertOne({
_id: "order_001",
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 | Dynamo 계열 구조, 쓰기 최적화, 링 구조, 요청별 일관성 수준 |
| HBase | Hadoop/HDFS 기반, 행 단위 일관성, 대용량 희소 테이블 |
| Google Bigtable | Google Cloud 관리형 Wide-Column DB, 대규모 저지연 워크로드 |
Cassandra의 특징
적합한 사용 사례: 시계열 데이터, IoT 센서, 로그 분석, 추천 시스템, 메시징
Graph Database
노드(Node)와 관계(Edge)로 데이터를 표현합니다. 관계가 1급 객체(first-class citizen)이므로, 여러 단계의 연결을 따라가는 탐색을 모델에 직접 담을 수 있습니다.
| 대표 제품 | 특징 |
|---|---|
| Neo4j | 대표적인 Property Graph DB, Cypher 쿼리 언어 |
| Amazon Neptune | AWS 관리형, Property Graph/RDF 계열 API 지원 |
| ArangoDB | Multi-Model(Graph + Document + Key-Value) |
Cypher 쿼리 (Neo4j)
적합한 사용 사례: 소셜 네트워크, 추천 엔진, 사기 탐지, 지식 그래프, 네트워크 분석
유형별 비교
| 유형 | 데이터 모델 | 강한 접근 패턴 | 확장 방향 | 주의점 |
|---|---|---|---|---|
| Key-Value | 키:값 | 키 기반 단건 접근 | 샤딩/캐시/관리형 자동 확장 | 보조 조건 검색은 약함 |
| Document | JSON/BSON 문서 | 문서 단위 조회/집계 | 샤딩과 인덱스 | 문서 경계 설계가 중요 |
| Wide-Column | 파티션:컬럼 패밀리 | 대량 쓰기, 범위 조회 | 파티션 분산과 복제 | 쿼리 먼저 모델링 필요 |
| Graph | 노드:관계 | 다단계 관계 탐색 | 그래프 파티셔닝/클러스터 구성 | 전역 그래프 분산은 까다로움 |
| RDB | 테이블:행:열 | SQL, 조인, 트랜잭션 | 수직 확장, 읽기 복제, 분산 SQL | 스키마와 조인 비용 관리 |
CAP 정리와 NoSQL
CAP 정리는 네트워크 분할이 생긴 분산 시스템에서 Consistency(일관성)와 Availability(가용성)를 동시에 완전하게 유지하기 어렵다는 관점입니다. 제품을 CP/AP로 영구 낙인찍기보다, 장애 상황에서 어떤 응답 정책과 복구 방식을 선택하는지 보는 것이 더 실무적입니다.
| 기본 성향 | 자주 보이는 제품군/예시 | 읽는 법 |
|---|---|---|
| 일관성 우선 | Primary 기반 문서 DB, HBase 계열 | 장애 중 일부 쓰기/읽기를 늦추거나 제한할 수 있음 |
| 가용성·지연 시간 우선 | Dynamo 계열, Cassandra 계열 | 응답을 우선하고 quorum/repair로 수렴을 관리 |
| 단일 노드/비분산 | 로컬 캐시, 단일 인스턴스 DB | CAP보다 장애 복구와 백업 전략이 더 중요 |
| 제품별 조절 | DynamoDB, MongoDB, Cassandra 등 | 읽기/쓰기 옵션, 트랜잭션, 리전 구성에 따라 달라짐 |
ACID vs BASE
ACID와 BASE는 제품군을 둘로 자르는 라벨이라기보다, 장애와 복제 지연을 다루는 설계 철학의 차이를 설명할 때 유용합니다. 전통적인 RDB는 ACID 트랜잭션을 강하게 내세우고, 많은 분산 NoSQL은 가용성과 최종 수렴을 중요하게 다루지만, 현대 제품은 트랜잭션과 강한 읽기 옵션을 함께 제공하기도 합니다.
NewSQL
NewSQL 또는 분산 SQL은 SQL과 ACID 트랜잭션을 유지하면서, 저장·복제·샤딩을 클러스터에 분산하려는 계열입니다. “NoSQL의 대체재”라기보다 트랜잭션이 중요한 대규모 시스템에서 선택지가 하나 더 늘어난 것으로 이해하면 됩니다.
| 대표 제품 | 특징 |
|---|---|
| Google Spanner | 글로벌 분산, 동기 복제, 외부 일관성 트랜잭션 |
| CockroachDB | PostgreSQL 호환, Range 기반 자동 분산, Raft 복제 |
| TiDB | MySQL 호환, TiKV 기반 분산 트랜잭션 |
| YugabyteDB | PostgreSQL 호환 API, 분산 트랜잭션과 복제 |
NoSQL 도입 시 고려사항
정리
| 유형 | 대표 제품 | 핵심 특징 | 적합한 데이터 |
|---|---|---|---|
| Key-Value | Redis, DynamoDB | 저지연 키 접근 | 세션, 캐시, 카운터 |
| Document | MongoDB, Firestore | 유연 스키마, 풍부한 쿼리 | CMS, 프로필, 카탈로그 |
| Wide-Column | Cassandra, HBase | 대규모 쓰기, 희소 데이터 | 시계열, IoT, 로그 |
| Graph | Neo4j, Neptune | 관계 탐색 최적화 | 소셜, 추천, 사기 탐지 |
| NewSQL | Spanner, CockroachDB | 분산 + ACID + SQL | 멀티리전 OLTP, 핵심 트랜잭션 |
NoSQL 유형 선택의 핵심은 데이터 접근 패턴입니다. 어떤 쿼리를 가장 자주 실행하는가에 맞는 데이터 모델을 선택해야 합니다. RDB가 만능이 아니듯, NoSQL도 만능이 아닙니다. 각 유형의 강점과 한계를 이해하고 적재적소에 활용하는 것이 중요합니다.
CAP 정리는 분산 DB 선택의 이론적 근거를 제공합니다. 다만 CP/AP 분류는 제품의 영구 속성이라기보다 네트워크 분할과 장애 상황에서 드러나는 기본 성향입니다. 실무에서는 많은 NoSQL이 읽기/쓰기 일관성, quorum, 트랜잭션, 리전 구성을 조절할 수 있으므로 절대적 분류보다 운영 옵션으로 이해하는 것이 적절합니다.
시험에서는 각 NoSQL 유형의 대표 제품, 데이터 모델 특성, CAP 관점, ACID vs BASE 차이가 자주 출제됩니다. 특히 Key-Value Store와 Document Store의 적합한 사용 사례를 구분하는 문제, Wide-Column Store가 시계열 데이터에 적합한 이유(쓰기 최적화, 파티션 기반 분산), Graph DB가 다단계 관계 탐색에 강한 이유(관계 저장, 인접성 기반 탐색)를 명확히 이해해야 합니다.
또한 Polyglot Persistence(다중 저장소 전략)가 현대 시스템에서 흔히 쓰인다는 점도 기억해야 합니다. 하나의 DB로 모든 요구를 충족하기보다, 메인 데이터(RDB), 캐시(Redis), 검색(Elasticsearch), 분석(Cassandra/HBase) 등 용도별로 저장소를 조합하는 접근이 많습니다.
NewSQL/분산 SQL은 SQL, 트랜잭션, 수평 확장을 함께 노리는 계열로, Google Spanner, CockroachDB, TiDB 등이 대표 제품입니다. NoSQL 유형 분류와 함께 NewSQL의 위치를 파악해두면 전체 데이터베이스 기술 스펙트럼을 이해하는 데 도움이 됩니다.
이러한 다양한 데이터베이스 기술의 존재는 하나의 최적 해가 없다(No One Size Fits All)는 원칙을 증명합니다. 요구사항에 맞는 데이터 모델과 일관성 수준을 선택하는 것이 핵심입니다.
다음 절에서는 분산 데이터베이스의 기초인 레플리케이션과 샤딩을 다루겠습니다.