NoSQL 데이터 모델링 방법

Database

NoSQL 데이터 모델링 방법

Somaz 2025. 4. 19. 13:02

728x90

Overview

다양한 유형의 비정형 데이터와 대규모 트래픽을 효율적으로 처리하기 위해 전통적인 RDBMS를 넘어 NoSQL이 널리 사용되고 있다.

이번 글에서는 대표적인 NoSQL 유형인 문서형(MongoDB), 키-값형(Redis), 컬럼형(Cassandra), 그래프형(Neo4j)의 데이터 모델링 방식을 살펴본다. 각 기술은 데이터 구조와 처리 방식에 따라 설계 방법이 다르므로, 상황에 맞는 모델링 전략이 중요하다.

2023.04.21 - [Database] - DB 스키마란?(Schema)

2023.05.17 - [Database] - MongoDB란?

2023.10.15 - [교육, 커뮤니티 후기/DOIK (데이터베이스 오퍼레이터 인 쿠버네티스) 스터디] - DOIK(Database Operator In Kubernetes) 1주차

2023.10.18 - [교육, 커뮤니티 후기/DOIK (데이터베이스 오퍼레이터 인 쿠버네티스) 스터디] - DOIK 1주차 - 도전과제1(Deploying Cassandra with a StatefulSet) + 도전과제4(kui)

2023.12.18 - [GCP] - GCP를 활용한 데이터 자동화(MongoDB, CloudSQL, GA, Dune)

2024.04.25 - [Database] - DB 샤딩(Sharding): 개념 및 동작방식

2025.03.20 - [Database] - DB의 데이터 무결성(Integrity)과 제약 조건(Constraints)

2025.03.28 - [Data Enginnering] - 대량 데이터 처리와 데이터 아키텍처 설계(OLAP & OLTP)

1. NoSQL 개요

유형	예시	DB특징
문서형	MongoDB	JSON/BSON 문서 기반
키-값형	Redis	단순 key-value 저장소
컬럼형	Cassandra	분산형, 대규모 쓰기/읽기 최적화
그래프형	Neo4j	관계 중심, 연결된 데이터 탐색 최적화

NoSQL은 “Not Only SQL”의 줄임말로, 정해진 스키마가 없거나 유연한 구조를 가지고 있으며, 수평 확장에 강한 구조로 설계되어 있다.
NoSQL은 ACID보다는 BASE(Basically Available, Soft state, Eventually consistent) 원칙을 따르는 경우가 많다. 따라서 일관성보다는 가용성과 확장성을 중시하는 환경에 적합하다.
각 NoSQL 유형은 특정 유스케이스에 따라 선택되어야 하며, 단일 애플리케이션 내에서도 RDBMS와 함께 하이브리드 아키텍처로 구성되는 경우도 많다.

2. 문서형 데이터 모델링 (MongoDB)

데이터 구조: JSON 기반의 계층적 문서
모델링 전략: 중첩(Nested) vs. 참조(Reference)
장점: 스키마 유연성, 하나의 Document에 전체 데이터를 저장 가능

{
  "user_id": 1,
  "name": "somaz",
  "orders": [
    { "order_id": 100, "item": "keyboard" },
    { "order_id": 101, "item": "monitor" }
  ]
}

자주 함께 조회되는 데이터는 중첩(Nested)
독립적이고 반복 가능한 구조는 참조 사용

참고: MongoDB의 `lookup` 연산자는 RDB의 JOIN과 유사한 역할을 하지만, 성능 저하를 유발할 수 있으므로 남용은 피해야 한다. 다대일 관계는 중첩으로, 다대다 관계는 참조 설계가 권장된다.

3. 키-값형 데이터 모델링 (Redis)

데이터 구조: 단순 키-값 저장 (문자열, 리스트, 해시, 셋 등)
모델링 전략: Key Naming Convention, Expire Time 설정
장점: 초고속 응답 속도, 캐싱, 세션 저장에 적합

SET user:1:name "somaz"
SET user:1:email "somaz@example.com"

Key 설계 시 접두어(`namespace`)를 잘 활용하자 (`user:1:profile`)
Expire 설정으로 메모리 자동 관리 가능

구조 선택 팁: 데이터 유형에 따라 `Hash`(구조화된 필드 저장), `Sorted Set`(랭킹 시스템), `List`(FIFO 큐) 등 Redis의 다양한 구조를 상황에 맞게 활용하면 된다.

4. 컬럼형 데이터 모델링 (Cassandra)

데이터 구조: 컬럼 패밀리 기반, 행별 스키마 가능
모델링 전략: 쿼리 중심 설계(Query First Design), 복합 파티션 키
장점: 대용량 데이터 쓰기, 시간순 이벤트 처리에 강함

CREATE TABLE user_events (
  user_id UUID,
  event_time timestamp,
  event_type text,
  PRIMARY KEY ((user_id), event_time)
);

정규화보다 중복을 허용하고, 조회 패턴 중심으로 설계
파티션 키 설계를 잘못하면 성능 저하 유발

주의: Cassandra는 JOIN, 서브쿼리, 트랜잭션 기능이 약하므로 애초에 쿼리 형태를 예측해 테이블을 설계해야 한다. "1쿼리 = 1테이블"을 기본 원칙으로 삼는다.

5. 그래프형 데이터 모델링 (Neo4j)

데이터 구조: 노드(Node), 관계(Relationship), 속성(Property)
모델링 전략: 엔터티 간의 연결 중심 모델
장점: 친구 추천, 경로 탐색, 소셜 네트워크 분석에 적합

CREATE (u:User {name: "somaz"})
CREATE (p:Post {title: "NoSQL modeling"})
CREATE (u)-[:WROTE]->(p)

쿼리는 Cypher 언어를 사용하며, 관계(Relationship)를 중심으로 설계
RDB의 JOIN보다 직관적이고 빠른 관계 탐색이 가능

Neo4j는 관계가 많은 데이터셋에 강점을 보이지만, 단순 CRUD 기반의 대량 데이터 저장 용도로는 부적합하다. 쿼리 복잡도보다는 관계의 밀도에 따라 도입을 검토해야 한다.

마무리

NoSQL은 단순히 "스키마가 없는 DB"가 아니다. 각 NoSQL DB는 고유의 데이터 저장 구조와 쿼리 패턴이 있으며, 그에 맞는 모델링 전략이 필요하다.

MongoDB는 유연한 구조로 웹앱 개발에 적합
Redis는 캐시와 세션 저장에 최적
Cassandra는 대량의 로그나 타임시리즈에 적합
Neo4j는 관계 기반 분석에 강점을 지닌다

결국 모델링의 핵심은 “사용자 쿼리를 예측하고 그에 맞는 구조를 설계하는 것”이다.

🔄 참고: 최근에는 MongoDB + Redis, Cassandra + Spark, Neo4j + RDBMS 조합처럼 각 NoSQL의 강점을 살린 멀티 모델(Multi-Model) 아키텍처가 주목받고 있다. 단일 DB로 모든 요구를 만족시키기보다는 역할 분담이 중요하다.

Reference

MongoDB 공식 모델링 가이드
Redis Data Structures
Cassandra Data Modeling Best Practices
Neo4j Modeling Guide
"NoSQL Distilled" – Pramod J. Sadalage & Martin Fowler (책 추천)

728x90

'Database' 카테고리의 다른 글

ACID와 CAP 이론 비교 (4)	2025.06.12
정규화(Normalization)와 반정규화(Denormalization)란? (4)	2025.06.05
데이터베이스 인덱스(Index) 최적화 방법 (4)	2025.03.21
DB 샤딩(Sharding): 개념 및 동작방식 (0)	2024.05.10
PostgreSQL 개념 및 특징(with MySQL) (0)	2024.03.29

현재글NoSQL 데이터 모델링 방법

Somaz의 IT 공부 일지