topic난이도 · 약 20

NoSQL 3대장 · CAP 정리

Document(MongoDB) · KV(Redis) · Wide-Column(Cassandra) + CAP = 분산 시스템의 숙명.

#NoSQL#MongoDB#Redis#Cassandra#CAP#PACELC
왜 배우는가

"왜 Redis를 SQL 대신 쓰지?", "MongoDB vs Postgres 언제?" 판단 기준. CAP 정리를 이해하면 "클라우드 DB가 왜 일시적 불일치를 허용하는지" 감이 잡힌다.

NoSQL은 단일 기술이 아니라 우산 용어. SQL이 아닌 여러 DB를 묶음. 3가지 주요 계열이 있다.

유형대표 제품데이터 모양강점약점
DocumentMongoDB, FirestoreJSON 문서스키마 유연, 중첩 구조조인·트랜잭션 약함
Key-ValueRedis, DynamoDB`key → value`O(1) 초고속복잡 쿼리 불가
Wide-ColumnCassandra, ScyllaDB행+수많은 동적 컬럼대규모 쓰기·지리 분산모델링 난이도
GraphNeo4j노드·엣지관계 추적범용성 낮음
SearchElasticsearch, OpenSearch역색인전문 검색·로그 분석주 저장소 부적합
Time-SeriesInfluxDB, Timescale시간 중심지표·IoT범용 CRUD 약함
javascript
// ━━━ Redis (KV) — 초고속 캐시·세션·큐 ━━━
await redis.set("user:42:name", "짓친");        // 즉시 저장
await redis.get("user:42:name");                // 즉시 조회
await redis.expire("user:42:name", 3600);       // 1시간 후 자동 삭제 (세션)

await redis.lpush("queue:jobs", JSON.stringify({ id: 1 }));   // 리스트 = 큐
await redis.brpop("queue:jobs", 0);             // 블로킹 pop (워커)

await redis.zadd("leaderboard", 1500, "user:42"); // sorted set = 랭킹
await redis.zrevrange("leaderboard", 0, 9);     // top 10

// ━━━ MongoDB (Document) — 스키마 유연 ━━━
await db.users.insertOne({
  _id: ObjectId(),
  name: "짓친",
  profile: { age: 25, tags: ["dev", "music"] },   // 중첩 문서
  posts: [{ title: "...", likes: 10 }],           // 배열 필드
});
await db.users.findOne({ "profile.tags": "dev" });

// ━━━ Postgres + JSONB (실은 관계형 + NoSQL 하이브리드) ━━━
// 실무 기본 선택지. JSONB 컬럼으로 NoSQL 유연성도 확보
// SELECT * FROM users WHERE profile->>'tags' @> '["dev"]';

Redis는 "메모리 기반 다기능 자료구조 서버". 캐시 + 큐 + 세션 + 랭킹이 한 서버로 해결. 바이브코더가 두 번째로 자주 만나는 DB.

2026년 실무 현실 — "일단 Postgres". 관계형 + JSONB로 NoSQL 유연성까지 커버. 캐시·세션·큐는 Redis. 전문 검색이 필요하면 Elasticsearch. 셋 조합이 현대 풀스택의 대세.

CAP 정리(CAP Theorem) — 분산 시스템은 세 가지를 모두 만족할 수 없다. ① Consistency(모든 노드 같은 값) ② Availability(항상 응답) ③ Partition tolerance(네트워크 단절 견딤). 분산 시스템에선 P는 전제 → 실제 선택은 CP vs AP.

선택의미예시
CP (일관성 + 파티션)장애 시 거부 응답전통 RDB, ZooKeeper, HBase
AP (가용성 + 파티션)장애 시 옛 값 응답 (결국 일치)Cassandra, DynamoDB, Redis Cluster
CA이론상단일 노드 DB만 가능 (분산 아님)

Eventual Consistency(결국 일관성) — AP 시스템이 약속하는 것. "지금은 불일치할 수 있지만 시간 지나면 결국 같아진다". Amazon DynamoDB·Cassandra가 표준. 장점: 가용성. 단점: "방금 저장한 게 바로 안 보여요" 사용자 경험.

PACELC 정리 — CAP의 확장. 파티션(P)일 때는 A vs C 선택, 정상(E, Else)일 때는 Latency vs Consistency 선택. 예: DynamoDB는 기본이 PA/EL(가용성+저지연), 강한 일관성 모드는 PA/EC. "느림 vs 최신" 트레이드오프.

바이브코더 선택 가이드. ① 단일 앱·중간 규모 → Postgres(+ JSONB) 하나면 충분. ② 캐시·세션·랭킹·큐 → Redis 추가. ③ 전문 검색 → Elasticsearch. ④ 모바일 실시간 동기화 → Firestore. ⑤ 수십만 TPS + 지리 분산 → Cassandra/DynamoDB.

실기 드릴 3문항
edit실기 드릴 · 단답형

분산 시스템에서 네트워크 단절 시 일관성과 가용성을 동시에 만족할 수 없다는 원리의 이름은?

check_circle실기 드릴 · OX

Redis는 디스크 DB이므로 캐시 용도로 부적절하다.

edit실기 드릴 · 단답형

"지금은 불일치지만 시간이 지나면 일치한다"는 분산 DB의 일관성 모델 이름은?