데이터베이스 — 3강: NoSQL·분산 DB·데이터 모델링

NoSQL 데이터베이스

NoSQL의 등장 배경:
→ 웹 2.0 — 대용량·비정형 데이터 급증
→ 수평 확장(Scale-Out) 필요성
→ 유연한 스키마 요구 (스키마리스)
→ 관계형 DB의 ACID 비용 부담

NoSQL 유형:

키-값 저장소 (Key-Value Store):
→ 예: Redis, DynamoDB, Memcached
→ 단순 키로 값 조회
→ 빠른 읽기/쓰기, 캐싱·세션 관리에 적합
→ 복잡한 쿼리 불가

문서 저장소 (Document Store):
→ 예: MongoDB, CouchDB, Firestore
→ JSON/BSON 형태 문서 저장
→ 중첩 구조 지원, 스키마 유연
→ 컬렉션(Collection) = 테이블

컬럼 저장소 (Wide-Column):
→ 예: Cassandra, HBase, BigTable
→ 행·컬럼 패밀리 구조
→ 대용량 시계열·로그 데이터
→ 열 단위 압축·집계 효율적

그래프 데이터베이스 (Graph DB):
→ 예: Neo4j, Amazon Neptune
→ 노드(Node)와 엣지(Edge) 구조
→ 소셜 네트워크, 추천 시스템, 지식 그래프
→ 관계 탐색 쿼리에 최적화

CAP 정리와 BASE

CAP 정리 (Brewer, 2000):
→ 분산 시스템에서 동시에 3가지 보장 불가

Consistency (일관성):
→ 모든 노드가 동일한 최신 데이터 반환

Availability (가용성):
→ 모든 요청에 응답 (오류 없이)

Partition Tolerance (파티션 내성):
→ 네트워크 분리 시에도 동작

분산 시스템에서 P는 필수:
→ CP 시스템: 일관성 우선 (MongoDB, HBase)
  → 파티션 발생 시 가용성 포기
→ AP 시스템: 가용성 우선 (Cassandra, CouchDB)
  → 파티션 발생 시 일관성 포기

BASE 속성 (NoSQL 특성):
→ Basically Available: 기본적으로 가용
→ Soft State: 데이터 상태 유동적
→ Eventual Consistency: 최종 일관성
  (시간이 지나면 모든 노드가 동기화)

vs ACID:
→ ACID: 즉각적 일관성, 높은 신뢰성 (RDBMS)
→ BASE: 최종 일관성, 높은 확장성 (NoSQL)

분산 데이터베이스

수평 분할 (Sharding / Partitioning):
→ 데이터를 여러 서버에 분산
→ 각 서버(샤드)는 데이터 부분집합 보유

샤딩 전략:

범위 샤딩 (Range Sharding):
→ 키 범위로 분할 (A-M → 샤드1, N-Z → 샤드2)
→ 범위 쿼리 효율적
→ 데이터 불균형(Hotspot) 문제

해시 샤딩 (Hash Sharding):
→ 키 해시값으로 분할
→ 균등 분산
→ 범위 쿼리 비효율

디렉토리 샤딩:
→ 조회 테이블로 위치 관리
→ 유연하지만 단일 장애점

복제 (Replication):
→ 마스터-슬레이브: 마스터 쓰기, 슬레이브 읽기
→ 멀티 마스터: 여러 노드 쓰기 가능 (충돌 처리 필요)
→ 쿼럼(Quorum): 과반수 노드 응답 시 성공

일관성 수준 (Cassandra 예):
→ ONE: 1개 노드 응답
→ QUORUM: 과반수 노드 응답
→ ALL: 모든 노드 응답 (높은 일관성, 낮은 가용성)

데이터 모델링과 정규화

정규화 (Normalization):
→ 데이터 중복 제거, 삽입·수정·삭제 이상 방지

1NF (제1정규형):
→ 모든 속성이 원자값 (반복 그룹 없음)
→ 예: 전화번호를 "010,011"로 저장 → 위반

2NF (제2정규형):
→ 1NF + 부분 함수 종속 제거
→ 복합키의 일부에만 종속된 속성 분리
→ 단일 기본키면 자동으로 2NF

3NF (제3정규형):
→ 2NF + 이행 함수 종속 제거
→ A→B, B→C 일 때 A→C (이행 종속)
→ 비키 속성이 기본키에만 종속

BCNF (보이스-코드 정규형):
→ 3NF + 결정자는 모두 후보키
→ 3NF보다 엄격
→ 일부 함수 종속 정보 손실 가능

역정규화 (Denormalization):
→ 성능을 위해 의도적으로 중복 허용
→ 읽기 많은 시스템에서 조인 비용 감소
→ NoSQL에서 빈번히 사용 (임베딩)

ER 다이어그램과 데이터 설계

ER 모델 구성요소:
→ 엔터티(Entity): 개체 (사각형)
→ 속성(Attribute): 특성 (타원)
→ 관계(Relationship): 연결 (마름모)

속성 유형:
→ 단순 속성: 더 이상 분해 불가 (주민번호)
→ 복합 속성: 분해 가능 (주소→도시+구+동)
→ 다치 속성: 여러 값 (전화번호들)
→ 유도 속성: 계산으로 도출 (나이→생년월일)

카디널리티:
→ 1:1 (일 대 일): 직원-사원증
→ 1:N (일 대 다): 부서-직원
→ M:N (다 대 다): 학생-수강과목 → 수강(교차 테이블) 생성

ER → 관계형 변환 규칙:
→ 강한 엔터티 → 테이블 (PK: 기본키)
→ 약한 엔터티 → 테이블 (부분키 + 부모 PK = 복합키)
→ M:N 관계 → 교차 테이블 생성
→ 1:N 관계 → N 쪽에 FK 추가
→ 복합·다치 속성 → 별도 테이블

데이터 웨어하우스:
→ OLAP (Online Analytical Processing)
→ 스타 스키마: 팩트 테이블 + 차원 테이블
→ 스노우플레이크 스키마: 차원 테이블 정규화
→ ETL: Extract-Transform-Load

NewSQL과 최신 트렌드

NewSQL:
→ RDBMS의 ACID + NoSQL의 확장성 결합
→ 예: Google Spanner, CockroachDB, TiDB, YugabyteDB
→ 분산 트랜잭션 지원
→ SQL 인터페이스 유지

Time-Series DB (시계열 DB):
→ 예: InfluxDB, TimescaleDB, Prometheus
→ 시간 순서 데이터 최적화
→ IoT 센서, 메트릭, 로그 데이터
→ 자동 데이터 압축·집계

벡터 데이터베이스:
→ 예: Pinecone, Weaviate, pgvector
→ 임베딩 벡터 저장·유사도 검색
→ AI·머신러닝 응용 (RAG, 추천)
→ 근사 최근접 이웃(ANN) 알고리즘

멀티모델 DB:
→ 하나의 DB에서 여러 모델 지원
→ 예: ArangoDB (그래프+문서+키-값)
→ 유연성 높지만 전문 DB 대비 성능 낮을 수 있음

서버리스 DB:
→ 예: PlanetScale, Neon, Supabase
→ 사용량 기반 과금, 자동 확장
→ 운영 부담 최소화

Q. MongoDB와 PostgreSQL 중 어떤 것을 선택해야 하나요? A. 스키마가 확정되어 있고 관계가 복잡하며 트랜잭션이 중요하다면 PostgreSQL을 선택합니다. 스키마가 자주 바뀌거나 JSON 데이터를 그대로 저장해야 하고 빠른 개발이 필요하다면 MongoDB가 유리합니다. 하지만 최근 PostgreSQL도 JSONB로 문서형 데이터를 잘 지원하고, MongoDB도 트랜잭션을 지원하므로 경계가 흐려지고 있습니다. 팀의 기술 스택과 운영 인프라도 선택 기준이 됩니다.

Q. 정규화를 지나치게 하면 어떤 문제가 생기나요? A. 과도한 정규화는 테이블 수를 늘려 조회 시 JOIN이 많아지고 성능이 저하됩니다. 예를 들어 5개 이상의 테이블을 JOIN하면 쿼리 복잡도와 실행 계획 비용이 크게 증가합니다. 실무에서는 쓰기가 많은 OLTP 시스템은 정규화를 유지하고, 읽기 중심의 OLAP나 API 응답 데이터는 의도적으로 역정규화(임베딩, 집계 테이블)를 적용하는 것이 일반적입니다.