8. 최신 트렌드

NoSQL

NoSQL이란?

Not Only SQL
- 관계형 모델(테이블)이 아닌 다양한 데이터 모델 사용
- 대규모 분산 환경에서의 확장성과 유연성에 초점
- 스키마가 유연하거나 없음 (Schema-less / Schema-flexible)

RDBMS vs NoSQL

구분	RDBMS	NoSQL
데이터 모델	테이블 (행/열)	문서, Key-Value, 컬럼, 그래프
스키마	고정 (정의 후 사용)	유연 (동적 변경)
확장 방식	수직 확장 (Scale-Up)	수평 확장 (Scale-Out)
트랜잭션	ACID 보장	BASE (Eventual Consistency)
조인	지원	제한적 / 미지원
일관성	강한 일관성	최종 일관성 (설정 가능)
적합 분야	복잡한 관계, 트랜잭션	대용량, 빠른 읽기/쓰기

NoSQL 유형

1. Key-Value Store
   - 가장 단순한 모델: (key, value) 쌍
   - 빠른 읽기/쓰기, 캐시에 적합
   - 예: Redis, Amazon DynamoDB, Memcached

   SET user:1001 "{'name':'홍길동','dept':'CS'}"
   GET user:1001

2. Document Store
   - JSON/BSON 형태의 문서 저장
   - 문서마다 다른 구조 가능 (유연한 스키마)
   - 예: MongoDB, CouchDB

   {
     "_id": "1001",
     "name": "홍길동",
     "dept": "CS",
     "courses": ["DB", "OS", "Network"]
   }

3. Column-Family Store
   - 행 키 + 컬럼 패밀리로 데이터 구성
   - 대규모 데이터 분석에 적합
   - 예: Apache Cassandra, HBase

   RowKey: user1001
     personal: {name: "홍길동", age: 22}
     academic: {dept: "CS", grade: 4}

4. Graph Database
   - 노드(Node)와 엣지(Edge)로 관계 표현
   - 소셜 네트워크, 추천 시스템에 적합
   - 예: Neo4j, Amazon Neptune

   (홍길동)-[:FRIEND]->(김영희)
   (홍길동)-[:ENROLLED]->(DB수업)

Redis

- 인메모리 Key-Value Store
- 매우 빠른 읽기/쓰기 (마이크로초 단위)
- 다양한 자료 구조 지원: String, List, Set, Hash, Sorted Set

주요 사용:
  - 캐시 (가장 일반적)
  - 세션 저장
  - 실시간 랭킹/리더보드
  - 메시지 큐 (Pub/Sub)
  - 분산 락

기본 명령어:
  SET key value
  GET key
  DEL key
  EXPIRE key seconds    -- TTL 설정
  HSET hash field value -- Hash 타입
  LPUSH list value      -- List 타입
  SADD set member       -- Set 타입
  ZADD sorted_set score member  -- Sorted Set

주의:
  - 메모리 기반 → 메모리 용량 제한
  - 영속성: RDB 스냅샷, AOF 로그 (설정에 따라)
  - 단일 스레드 (6.0부터 I/O 멀티스레딩)

MongoDB

- 문서(Document) 기반 NoSQL
- JSON 유사 형태 (BSON으로 저장)
- 유연한 스키마: 같은 컬렉션의 문서가 다른 필드를 가질 수 있음

구조:
  RDBMS     →  MongoDB
  Database  →  Database
  Table     →  Collection
  Row       →  Document
  Column    →  Field
  JOIN      →  Embedded / $lookup

기본 CRUD:
  // 삽입
  db.students.insertOne({
    name: "홍길동",
    dept: "CS",
    grade: 4
  });

  // 조회
  db.students.find({ dept: "CS" });
  db.students.find({ grade: { $gte: 3 } });

  // 수정
  db.students.updateOne(
    { name: "홍길동" },
    { $set: { grade: 4 } }
  );

  // 삭제
  db.students.deleteOne({ name: "홍길동" });

  // 집계
  db.students.aggregate([
    { $match: { dept: "CS" } },
    { $group: { _id: "$grade", count: { $sum: 1 } } }
  ]);

인덱스:
  db.students.createIndex({ name: 1 });     // 단일 인덱스
  db.students.createIndex({ dept: 1, grade: -1 }); // 복합 인덱스

CAP 정리

CAP 정리란?

분산 시스템에서 다음 3가지를 동시에 만족할 수 없다 (최대 2가지):

C (Consistency, 일관성)
  - 모든 노드가 같은 시점에 같은 데이터를 봄
  - 읽기는 항상 최신 쓰기의 결과를 반환

A (Availability, 가용성)
  - 모든 요청이 (성공/실패) 응답을 받음
  - 장애가 없는 노드는 항상 응답

P (Partition Tolerance, 분할 허용)
  - 네트워크 분할(노드 간 통신 불가)이 발생해도 시스템이 동작

실제로는 네트워크 분할(P)은 피할 수 없으므로
C와 A 중 하나를 선택:
  CP: 일관성 우선 (일부 요청 거부 가능)
  AP: 가용성 우선 (일시적 불일치 허용)

CAP 분류

CP 시스템 (일관성 + 분할 허용):
  - 분할 발생 시 일관성을 위해 일부 요청 거부
  - 예: MongoDB (Primary 장애 시 선출까지 쓰기 불가)
  - 예: HBase, Zookeeper

AP 시스템 (가용성 + 분할 허용):
  - 분할 발생 시 가용성을 위해 일시적 불일치 허용
  - 예: Cassandra, DynamoDB, CouchDB
  - 최종 일관성 (Eventual Consistency)

CA 시스템 (일관성 + 가용성):
  - 분할을 허용하지 않음 → 단일 노드 시스템
  - 예: 전통적 RDBMS (단일 서버)
  - 분산 환경에서는 사실상 불가능

BASE

NoSQL의 일관성 모델. ACID의 대안.

BA (Basically Available)
  - 기본적으로 가용: 항상 응답을 반환
  - 일부 노드 장애에도 시스템은 동작

S (Soft State)
  - 시간이 지남에 따라 상태가 변할 수 있음
  - 외부 입력 없이도 데이터 변경 가능 (동기화)

E (Eventually Consistent)
  - 최종적 일관성: 충분한 시간이 지나면 모든 복제본이 일치
  - 일시적 불일치 허용

ACID vs BASE:
  ACID → 강한 일관성, 트랜잭션 보장 (금융, 결제)
  BASE → 높은 가용성, 최종 일관성 (SNS, 로그, 캐시)

분산 데이터베이스

분산 DB 개념

데이터를 여러 노드에 분산 저장하고 관리하는 시스템

장점:
  - 수평 확장 (Scale-Out): 노드 추가로 성능/용량 증가
  - 고가용성: 복제를 통해 단일 장애점 제거
  - 지역성: 사용자 가까운 노드에서 서비스

단점:
  - 일관성 유지 어려움
  - 네트워크 지연
  - 설계/운영 복잡도 증가

데이터 분산 전략

1. 샤딩 (Sharding) = 수평 분할
   - 데이터를 여러 노드에 나누어 저장
   - 각 노드가 데이터의 일부(샤드)를 담당

   샤딩 키 기준으로 분배:
   ├── 범위 기반 (Range): id 1~1000 → 노드1, 1001~2000 → 노드2
   ├── 해시 기반 (Hash): hash(id) % N → 노드 결정
   └── 디렉토리 기반: 매핑 테이블로 관리

   해시 샤딩 vs 범위 샤딩:
   - 해시: 균등 분배, 범위 쿼리 어려움
   - 범위: 범위 쿼리 용이, 핫스팟 가능

2. 복제 (Replication)
   - 같은 데이터를 여러 노드에 복제
   ├── 마스터-슬레이브: 쓰기는 마스터만, 읽기는 슬레이브도
   ├── 마스터-마스터: 여러 노드에서 쓰기 가능 (충돌 해결 필요)
   └── Quorum 기반: W + R > N이면 일관성 보장

   Quorum:
     N = 전체 복제본 수
     W = 쓰기 시 응답 필요한 노드 수
     R = 읽기 시 응답 필요한 노드 수
     W + R > N → 강한 일관성
     예: N=3, W=2, R=2 → 항상 최신 데이터 읽기 보장

분산 트랜잭션

2PC (Two-Phase Commit):
  준비 단계 (Prepare): 코디네이터가 참여자에게 커밋 준비 요청
  커밋 단계 (Commit): 모든 참여자가 준비 완료하면 커밋 명령

  ┌────────────┐         ┌────────────┐
  │ Coordinator│         │ Participant│
  │            │ Prepare │            │
  │            │────────→│            │
  │            │  Ready  │            │
  │            │←────────│            │
  │            │ Commit  │            │
  │            │────────→│            │
  │            │  ACK    │            │
  │            │←────────│            │
  └────────────┘         └────────────┘

  단점: 코디네이터 장애 시 블로킹, 성능 오버헤드
  → 분산 환경에서는 Saga 패턴 등 대안 사용

NewSQL

RDBMS의 ACID + NoSQL의 확장성을 결합

특징:
  - SQL 인터페이스 (기존 RDBMS와 호환)
  - ACID 트랜잭션 보장
  - 수평 확장 가능 (분산 아키텍처)

예시:
  - Google Spanner: 글로벌 분산, 외부 일관성
  - CockroachDB: Spanner 영감, PostgreSQL 호환
  - TiDB: MySQL 호환, Raft 기반 복제
  - VoltDB: 인메모리, 고성능 트랜잭션

핵심 정리

1. NoSQL: Key-Value, Document, Column-Family, Graph
2. Redis: 인메모리 캐시, 다양한 자료 구조
3. MongoDB: 문서 기반, 유연한 스키마
4. CAP 정리: C/A/P 중 최대 2개 (실질적으로 CP 또는 AP 선택)
5. BASE: 최종 일관성 (ACID의 대안)
6. 샤딩: 수평 분할 (해시/범위), 복제: 가용성/읽기 성능
7. NewSQL: ACID + 수평 확장 (Spanner, CockroachDB)

면접 포인트

자주 나오는 질문

Q1. RDBMS와 NoSQL의 차이는?

• RDBMS: 테이블 기반, 고정 스키마, ACID, 복잡한 JOIN 가능
• NoSQL: 다양한 모델, 유연한 스키마, BASE, 수평 확장 용이
• 정답은 없음 → 요구사항에 따라 선택 (트랜잭션 중요 → RDBMS, 확장성/속도 → NoSQL)

Q2. CAP 정리를 설명하라.

• 분산 시스템에서 일관성(C), 가용성(A), 분할 허용(P) 중 최대 2가지만 만족
• P는 불가피 → 실질적으로 CP(일관성 우선) vs AP(가용성 우선) 선택
• CP: MongoDB, HBase / AP: Cassandra, DynamoDB

Q3. Redis를 주로 어디에 사용하는가?

• 캐시: DB 앞에서 자주 조회되는 데이터 캐싱
• 세션 저장: 웹 애플리케이션 세션 관리
• 실시간 랭킹: Sorted Set으로 리더보드
• 메시지 큐: Pub/Sub, Stream
• 주의: 메모리 기반이므로 용량 제한, 영속성 설정 필요

Q4. 샤딩이란?

• 데이터를 여러 노드에 수평 분할하여 저장
• 샤딩 키에 따라 각 데이터가 어느 노드에 저장될지 결정
• 해시 샤딩: 균등 분배, 범위 쿼리 어려움
• 범위 샤딩: 범위 쿼리 용이, 핫스팟 위험

Q5. 최종 일관성(Eventual Consistency)이란?

• 일시적으로 복제본 간 데이터가 다를 수 있지만, 충분한 시간이 지나면 동일해짐
• SNS 게시글, 좋아요 수 등 즉시 일관성이 필요 없는 경우에 적합
• 강한 일관성보다 가용성과 성능이 우수

Q6. RDBMS를 언제 선택하고 NoSQL을 언제 선택하는가?

• RDBMS: 데이터 관계가 복잡, 트랜잭션 필수, 일관성 중요 (금융, 주문)
• NoSQL: 대용량 데이터, 빠른 읽기/쓰기, 스키마 변경 빈번 (로그, SNS, IoT)
• 하이브리드: RDBMS + Redis 캐시 조합이 실무에서 흔함