데이터 모델 전체 그림 (문서 / 그래프 / 시계열 / 벡터)

🎯 핵심 질문

왜 모든 데이터를 MySQL의 테이블에 넣을 수 없을까? 데이터가 소셜 관계망, 초당 백만 건의 센서 스트림, 또는 AI가 이해해야 할 의미 벡터일 때 관계형 테이블은 한계에 직면합니다. 서로 다른 데이터 형태는 서로 다른 모델링 방식이 필요합니다.

1. 관계형 너머: 왜 다른 데이터 모델이 필요한가?

관계형 데이터베이스(MySQL, PostgreSQL)는 "테이블 + 행 + 열"로 데이터를 구성하며, 구조가 고정되고 관계가 명확한 비즈니스 데이터에 적합합니다. 하지만 현실 세계의 데이터는 이보다 훨씬 다양합니다:

데이터 형태	관계형의 고충	더 적합한 모델
사용자 프로필(필드가 고정되지 않고 중첩 구조)	잦은 ALTER TABLE, 대량의 NULL 열	문서 모델
소셜 네트워크(친구의 친구의 친구)	다층 JOIN 성능 기하급수적 저하	그래프 모델
모니터링 지표(초당 백만 건 기록)	쓰기 병목, 과거 데이터 팽창	시계열 모델
AI 의미 검색("의미가 비슷한" 콘텐츠)	의미적 유사도 표현 불가	벡터 모델

💡 핵심 관점

관계형을 "대체"하는 것이 아니라 "보완"하는 것입니다. 대부분 시스템의 핵심 비즈니스는 여전히 MySQL/PostgreSQL에서 운영되지만, 특정 시나리오에서 전용 데이터 모델을 도입하면 수량급의 성능 향상을 얻을 수 있습니다.

2. 문서 모델(Document)

2.1 문서 모델이란?

문서 모델은 데이터를 JSON/BSON 문서로 저장하며, 각 레코드는 자체적으로 완결된 문서로 서로 다른 필드 구조를 가질 수 있습니다.

json

{
  "_id": "user_1001",
  "name": "홍길동",
  "tags": ["VIP", "활성"],
  "address": { "city": "서울", "district": "강남구" },
  "orders": [
    { "id": "o1", "amount": 299 },
    { "id": "o2", "amount": 599 }
  ]
}

핵심 특징:

스키마 제약 없음: 테이블 구조를 미리 정의할 필요 없이 필드를 자유롭게 추가/제거
중첩 구조: 주소, 주문이 문서 안에 직접 포함되어 한 번의 읽기로 전체 데이터 획득
수평 확장: 샤딩(Sharding)에 자연스럽게 적합하여 대규모 데이터에 대응

2.2 문서형 vs 관계형

비교 차원	관계형(MySQL)	문서형(MongoDB)
데이터 구조	고정 스키마, ALTER TABLE로 수정	유연한 스키마, 필드를 언제든 추가
중첩 데이터	다중 테이블 JOIN 필요	문서 안에 직접 중첩
레코드 간 연관	JOIN이 강력함	연관 쿼리가 상대적으로 약함
적합한 시나리오	구조가 안정적인 비즈니스 데이터	구조가 변하는 콘텐츠 데이터

2.3 대표적 시나리오

CMS 콘텐츠 관리: 기사, 댓글, 태그의 구조가 제각각
사용자 프로필: 사용자마다 서로 다른 속성 필드
상품 카탈로그: 휴대폰은 "화면 크기", 식품은 "유통기한" — 필드가 완전히 다름
설정 센터: 각 서비스의 설정 구조가 비표준적

⚠️ 일반적 오해

"MongoDB는 데이터 구조 설계가 필요 없다" — 틀렸습니다! 문서 모델도 신중한 설계가 필요합니다. 중첩 단계가 너무 깊으면 안 되고, 잦은 업데이트가 필요한 하위 문서는 독립 컬렉션으로 분리해야 합니다.

3. 그래프 모델(Graph)

3.1 그래프 모델이란?

그래프 모델은 노드(Node)와 엣지(Edge)로 엔티티와 그 관계를 표현합니다. 각 노드는 하나의 엔티티이고, 각 엣지는 하나의 관계이며, 노드와 엣지 모두 속성을 가질 수 있습니다.

(홍길동) --[팔로우]--> (이순신) --[팔로우]--> (강감찬)
   |                                    |
   +--------[구매]----> (iPhone) <--[구매]--+

3.2 그래프 모델의 결정적 능력: 다중 홉 쿼리

시나리오: 소셜 네트워크에서 "친구의 친구의 친구" 찾기

관계형 방식(3단계 JOIN):

sql

SELECT DISTINCT f3.name
FROM friends f1
JOIN friends f2 ON f1.friend_id = f2.user_id
JOIN friends f3 ON f2.friend_id = f3.user_id
WHERE f1.user_id = 1001;

그래프 데이터베이스 방식(Cypher 쿼리 언어):

cypher

MATCH (me)-[:FOLLOWS*1..3]->(target)
WHERE me.name = '홍길동'
RETURN DISTINCT target.name

관계형은 홉이 하나 늘어날 때마다 JOIN이 추가되어 성능이 기하급수적으로 저하됩니다. 그래프 데이터베이스는 포인터로 관계를 직접 순회하여 다중 홉 쿼리 성능이 거의 변하지 않습니다.

3.3 대표적 시나리오

소셜 네트워크: 친구 추천, 공동 팔로우, 영향력 전파
지식 그래프: 엔티티 관계 추론("누가 누구의 선생님의 학생인가")
사기 탐지: 자금 순환, 연관 계정 네트워크 발견
추천 시스템: 사용자-상품-태그의 관계 그래프 기반 추천

4. 시계열 모델(Time-Series)

4.1 시계열 모델이란?

시계열 모델은 타임스탬프를 중심축으로 "시간순으로 기록하고, 시간 범위로 조회하는" 시나리오에 특화된 최적화 모델입니다.

timestamp            device      cpu_usage   memory
2024-01-15 10:00:01  server-01   45%         12.3GB
2024-01-15 10:00:02  server-01   67%         12.5GB
2024-01-15 10:00:03  server-01   92%         14.1GB

4.2 왜 MySQL로 시계열 데이터를 저장하지 않는가?

문제	MySQL	시계열 데이터베이스(InfluxDB)
기록 속도	만 건/초 수준	백만 건/초 수준
과거 데이터	수동 삭제, 테이블이 점점 커짐	자동 만료 정책(TTL)
집계 쿼리	GROUP BY가 느림	내장 다운샘플링(5초 → 1분 평균)
저장 효율	범용 저장, 공간 낭비	컬럼 기반 압축, 90% 공간 절약

4.3 대표적 시나리오

서버 모니터링: CPU, 메모리, 디스크 초당 수집
IoT 센서: 온도, 습도, GPS 궤적
금융 시세: 주식 가격, 거래량의 초 단위 데이터
로그 분석: 애플리케이션 로그의 시간선 집계

5. 벡터 모델(Vector)

5.1 벡터 모델이란?

벡터 모델은 텍스트, 이미지, 오디오 등 비정형 데이터를 임베딩 모델을 통해 고차원 숫자 벡터로 변환한 다음, 벡터 간 거리를 계산하여 의미적 유사도를 측정합니다.

"맛있는 일식" → Embedding → [0.82, 0.15, 0.91, 0.33, ...]
                                    ↓ 코사인 유사도
"긴자 스시 명가"  → [0.80, 0.18, 0.89, ...] → 96% 유사
"이탈리아 피자"    → [0.12, 0.85, 0.20, ...] → 31% 유사

5.2 벡터 검색 vs 키워드 검색

비교	키워드 검색(LIKE / 전문 인덱스)	벡터 검색
검색 방식	문자열 정확 매칭	의미적 유사도 매칭
"맛있는 일식"	"일식"이 포함된 텍스트만 매칭	"스시", "사시미", "이자카야"까지 발견
다국어	개별 처리 필요	크로스 언어 의미 이해
멀티모달	텍스트만	텍스트, 이미지, 오디오 통합 검색

5.3 대표적 시나리오

RAG(검색 증강 생성): LLM에 관련 지식 조각 제공
의미 검색: 키워드가 아닌 사용자 의도 이해
이미지로 이미지 검색: 이미지를 업로드하여 시각적으로 유사한 이미지 발견
추천 시스템: 콘텐츠 의미 기반 유사 추천

💡 벡터 데이터베이스 선택

독립 벡터 데이터베이스: Pinecone, Milvus, Weaviate — 벡터 검색에 특화, 최고 성능
전통적 데이터베이스 확장: pgvector(PostgreSQL), Atlas Vector Search(MongoDB) — 아키텍처 복잡도 감소
인메모리 벡터 라이브러리: FAISS, Annoy — 소규모, 저지연 시나리오에 적합

6. 선택 의사결정: 데이터 모델을 어떻게 선택할까?

당신의 데이터는 어떤 모습인가?	추천 모델	대표 제품
구조가 고정되고 관계가 명확(주문, 사용자)	관계형	MySQL, PostgreSQL
구조가 유연하고 중첩이 많음(콘텐츠, 설정)	문서형	MongoDB, DynamoDB
엔티티 간 관계가 복잡하고 다중 홉 순회 필요	그래프	Neo4j, Amazon Neptune
시간순으로 기록하고 시간 범위로 조회	시계열	InfluxDB, TimescaleDB
비정형 데이터, 의미적 유사도 검색 필요	벡터	Pinecone, Milvus, pgvector

🎯 실무 조언

현대 시스템은 보통 다중 모델 혼용입니다:

핵심 비즈니스는 PostgreSQL(관계형)
사용자 행동 로그는 InfluxDB(시계열)
AI 지식 베이스는 Milvus + pgvector(벡터)
추천 엔진은 Neo4j(그래프)

"하나의 데이터베이스로 모든 문제를 해결"하려 하지 말고, 각 데이터에 가장 적합한 집을 찾아주세요.

🗂️数据模型全景四种主流数据模型对比

不是所有数据都适合塞进关系型表格。社交网络的人脉关系、IoT 设备的时间流水、AI 搜索的语义向量——不同的数据形态需要不同的建模方式。

📄文档模型 (Document)MongoDB / DynamoDB

数据以 JSON 文档存储，每条记录可以有不同的字段结构，天然适合嵌套、半结构化数据。

{
  "_id": "user_1001",
  "name": "张三",
  "tags": ["VIP", "活跃"],
  "address": {
    "city": "北京",
    "district": "朝阳区"
  },
  "orders": [
    { "id": "o1", "amount": 299 },
    { "id": "o2", "amount": 599 }
  ]
}

无需预定义 Schema，字段随时扩展

嵌套数据一次读取，无需 JOIN

跨文档关联查询较弱

典型场景：用户画像CMS 内容商品目录配置中心

💡选型原则：没有万能数据库。关系型（MySQL/PostgreSQL）仍是大多数业务的基石，但当数据形态明确偏向文档、图、时序或向量时，选择专用模型能获得数量级的性能提升。

데이터 모델 전체 그림 (문서 / 그래프 / 시계열 / 벡터) ​

1. 관계형 너머: 왜 다른 데이터 모델이 필요한가? ​

2. 문서 모델(Document) ​

2.1 문서 모델이란? ​

2.2 문서형 vs 관계형 ​

2.3 대표적 시나리오 ​

3. 그래프 모델(Graph) ​

3.1 그래프 모델이란? ​

3.2 그래프 모델의 결정적 능력: 다중 홉 쿼리 ​

3.3 대표적 시나리오 ​

4. 시계열 모델(Time-Series) ​

4.1 시계열 모델이란? ​

4.2 왜 MySQL로 시계열 데이터를 저장하지 않는가? ​

4.3 대표적 시나리오 ​

5. 벡터 모델(Vector) ​

5.1 벡터 모델이란? ​

5.2 벡터 검색 vs 키워드 검색 ​

5.3 대표적 시나리오 ​

6. 선택 의사결정: 데이터 모델을 어떻게 선택할까? ​