[데이터 중심 어플리케이션 설계하기] 2과. 데이터 모델과 질의 언어

2과. 데이터 모델과 질의 언어

참고문서 : 데이터 중심 애플리케이션 설계(마틴 클레프만, 위키북스)

1. 데이터 모델이란 무엇인가?

데이터 모델은 우리가 어떤 문제를 어떻게 해결할지, 그리고 소프트웨어가 할 수 있는 일과 없는 일에까지 영향을 미친다.
예를 들어, 어떤 연산은 빠르고, 어떤 연산은 느릴 수 있다.
데이터 모델을 이해하는 것은 단순히 저장 구조를 아는 것 이상으로, 시스템의 한계와 가능성을 파악하는 데 중요하다.

데이터 모델의 큰 범주

• 관계형 모델
• 문서 모델
• 그래프 모델

2. 관계형 모델과 문서 모델

2-1. 관계형 모델

• 데이터를 관계(relation, 테이블)로 구성
• 각 관계는 순서 없는 튜플(tuple, 행)의 모음
• SQL을 통해 정규화된 구조로 데이터를 저장하고 질의
• 정규화와 조인(join)을 통해 데이터 중복을 최소화하고 일관성을 유지

2-2. NoSQL과 문서 모델

• NoSQL: Not Only SQL
• 대규모 데이터셋, 높은 쓰기 처리량, 오픈소스 선호, 관계형 모델의 스키마 제한 극복, 동적이고 표현력 풍부한 데이터 모델을 지향
• 문서 모델
• 데이터를 JSON, BSON, XML 등 문서 형태로 저장
• 트리 구조(1:N, 중첩 구조)에 적합
• 스키마 유연성(schemaless) 제공

3. 데이터 모델의 관계 표현 방식

3-1. 객체-관계형 불일치

• OOP 객체를 SQL 데이터 모델로 바꾸려면 전환 계층(ORM 등)이 필요 (임피던스 불일치)
• 1:N 관계를 표현하는 방법

1. 멀티 테이블 스키마 + 조인
2. 구조화된 데이터 타입(xml, json) 사용
3. 자체 부호화(질의/색인 불가)

• 문서 지향 DB는 JSON 데이터 모델을 지원해 위 문제를 쉽게 해결

3-2. 관계의 종류와 모델별 특징

• 1:N 관계
• 트리 구조와 유사, 문서 모델에서 자연스럽게 표현
• N:1 관계
• 예: 여러 명이 하나의 학교를 가짐
• 평문 저장 시 갱신 어려움, unique id로 저장 시 의미 상실
• 관계형 모델은 정규화로 쉽게 처리, 문서 모델은 어려움
• N:M 관계
• 예: 추천인 프로필 사진 변경 시 모든 참조에 반영 필요
• 데이터 중복 vs 참조의 선택, NoSQL 이전부터 논쟁
• 계층 모델(트리 구조)은 N:M 표현이 어려움, 네트워크 모델은 다중 부모로 해결

[비교: 관계형 vs 문서 vs 그래프]

모델	관계 표현	장점	단점/제약
관계형	외래키, 조인	일관성, 정규화, 쿼리 최적화	스키마 유연성 부족, 복잡한 조인
문서	중첩, 참조	유연성, 트리 구조 적합	N:M, 상호참조에 불리
그래프	노드-간선 직접 연결	복잡한 관계, 탐색 최적화	도입/운영 난이도, 특수 목적

4. 문서 모델의 특징과 실무적 한계

4-1. 문서 모델의 적합성과 제약

• 적합: 1:N, 트리 구조 데이터, 전체 트리 적재가 필요한 경우
• 제약:
• embed된 필드 직접 참조 불가 (경로로 접근)
• N:M 관계는 비정규화/수동 참조 필요, 일관성 유지 추가 작업
• 상호 연결이 많을수록 문서 모델은 곤란, 관계형/그래프 모델이 더 적합

4-2. 스키마 유연성(schemaless)

• 쓰기 스키마 없음: 임의의 필드 추가 가능
• 읽기 스키마 존재: 실제로는 읽는 쪽에서 구조를 가정
• 장점: 다양한 유형의 데이터를 한 컬렉션에 저장 가능, 외부 시스템 연동에 유리
• 단점: 데이터 구조 불일치, 마이그레이션 시 추가 작업 필요

4-3. 저장소 지역성(Storage Locality)

• 관련 데이터를 한 문서에 그룹화하여 I/O 효율성 향상
• 전체 문서 단위로 읽고 쓸 때 성능상 이점
• 문서 크기 증가/변경 시 성능 저하 가능성 → 필드 수준 업데이트 권장

5. 질의 언어(Query Language)의 유형

5-1. 명령형 vs 선언형

• 명령형(Imperative)
• 연산 순서, 알고리즘을 직접 지정
• 네트워크 모델, IMS 등에서 사용
• 선언형(Declarative)
• 결과 조건만 지정, 실행 방법은 시스템이 최적화
• SQL, Cypher, SPARQL 등

5-2. 주요 질의 언어 및 예시

• SQL (관계형)
• 선언형, 쿼리 최적화기 내장
• MapReduce (분산/문서형)
• 명령형과 선언형의 중간, 저수준 함수(map, reduce)로 데이터 처리
• MongoDB 2.2 이후 aggregate pipeline(선언형) 지원

예시 (MongoDB MapReduce):

db.collection.mapReduce(
function map() {
var year = this.timestamp.getFullYear();
var month = this.timestamp.getMonth() + 1;
emit(year + "-" + month, this.number);
},
function reduce(key, values) {
return Array.sum(values);
},
{
query: { type: "A" },
out: "monthlyCount",
}
);

예시 (MongoDB Aggregate Pipeline):

db.collection.aggregate([
{ $match: { type: "A" } },
{
$group: {
_id: {
year: { $year: "$timestamp" },
month: { $month: "$timestamp" },
},
monthlyCount: { $sum: "$number" },
},
},
]);

• Cypher (그래프형)
• Neo4j 등에서 사용, 패턴 기반 선언형 질의

예시:

CREATE (USA:Location {name:'USA', type:'country'}),
(Idaho:Location {name:'Idaho', type:'state'})
CREATE (Idaho)-[:WITHIN]->(USA)
MATCH (person)-[:BORN_IN]->()-[:WITHIN*0..]->(location)
RETURN person, location

• SPARQL (트리플 저장소)
• RDF 데이터 질의, 시맨틱 웹 표준

예시:

SELECT ?person ?location WHERE {
?person :bornIn ?place .
?place :within* ?location .
}

• Datalog
• 논리형 질의, 단계별 추론

예시:

name(usa, 'United States').
within(idaho, usa).
born_in(lucy, idaho).
ancestor(Person, Location) :- born_in(Person, Place), within(Place, Location).

6. 그래프 데이터 모델과 질의

6-1. 그래프 모델의 구조

• 그래프 모델(Graph Model)은 데이터를 정점(Vertex, Node)과 간선(Edge, Relationship)으로 표현한다. 각 정점과 간선은 다양한 속성(key-value 쌍)을 가질 수 있다.
• 정점(Vertex): 엔티티(사람, 장소, 사물 등)를 나타내며, 고유 ID와 여러 속성을 가질 수 있다.
• 간선(Edge): 정점 간의 관계(친구, 소속, 링크 등)를 나타내며, 방향성과 속성을 가질 수 있다.
• 속성(Attribute): 정점과 간선 모두 key-value 형태의 속성을 가질 수 있어, 복잡한 정보를 유연하게 저장 가능하다.
• 패턴 탐색: 그래프 모델의 가장 큰 장점은 여러 정점과 간선을 따라가는 패턴 기반 탐색(예: 친구의 친구, 특정 경로의 존재 여부 등)이 매우 자연스럽고 효율적이라는 점이다.

실무적 활용 예시

• 소셜 네트워크: 사용자(정점)와 친구 관계(간선), 좋아요, 팔로우 등 다양한 관계를 직관적으로 모델링
• 추천 시스템: 사용자, 상품, 태그, 구매 이력 등을 그래프로 연결하여 유사도, 연결 강도 기반 추천
• 네트워크/IT 인프라: 장비, 서버, 연결 상태 등을 그래프로 표현하여 장애 전파, 경로 분석 등 수행
• 지식 그래프: 다양한 엔티티와 관계를 연결하여 의미 기반 질의, 추론 등 지원

그래프 DB의 장단점

• 장점
• 복잡한 관계, 다단계 연결, 패턴 탐색에 최적화
• 스키마 유연성, 실시간 관계 질의에 강점
• 데이터 구조가 자주 바뀌거나, 관계가 핵심인 도메인에 적합
• 단점
• 대량의 단순 트랜잭션 처리에는 부적합할 수 있음
• 관계형 DB에 비해 도입/운영 난이도, 생태계가 제한적일 수 있음

대표적인 그래프 DB와 선택 기준

• Neo4j: 가장 널리 쓰이는 속성 그래프 DB, Cypher 질의 언어 지원
• Amazon Neptune, Azure Cosmos DB: 클라우드 기반 그래프 DB, 다양한 API 지원
• JanusGraph, TigerGraph: 대규모 분산 그래프 처리에 강점
• OrientDB, ArangoDB: 멀티모델(문서+그래프) DB
• 선택 기준: 데이터의 연결성, 질의 패턴, 확장성, 생태계, 클라우드 지원 여부 등

6-2. 그래프 질의 언어

• Cypher: 선언형, 패턴 매칭 기반
• SPARQL: RDF, 트리플 기반 질의
• Datalog: 논리형, 단계별 추론
• Gremlin: 명령형, 경로 탐색 중심

6-3. 관계형/문서형 DB에서 그래프 질의

• 관계형: 재귀 CTE(WITH RECURSIVE)로 그래프 탐색 가능, 성능 한계
• 문서형: MongoDB의 $graphLookup 등 일부 지원, sharding 환경 제약

7. 실무적 Best Practice 및 참고자료

• 데이터 모델 선택 시, 데이터 구조와 질의 패턴을 먼저 분석
• 트리/문서형 데이터는 문서 모델, 상호 연결/복잡한 관계는 그래프 모델, 일관성/정규화는 관계형 모델이 적합
• 스키마 유연성은 장점이자 단점이 될 수 있으므로, 데이터 구조 변화가 잦은 경우에만 적극 활용
• 최신 DBMS는 다양한 모델/질의 언어를 혼합 지원하므로, 필요에 따라 적절히 조합

참고자료

• 데이터 중심 애플리케이션 설계(마틴 클레프만, 위키북스)
• MongoDB 공식 문서: Schema Design for Time-Series Data
• MariaDB OQGRAPH Storage Engine
• PostgreSQL Apache AGE (OpenCypher)
• MongoDB $graphLookup
• SPARQL 1.1 Query Language
• 빨간색코딩:티스토리

실무자의 시선에서 느낀 점

• 데이터 모델은 단순히 저장 방식이 아니라, 시스템의 한계와 가능성을 결정짓는 중요한 선택지다.
• 문서 모델의 유연성은 빠른 변화에 대응할 수 있지만, 데이터 일관성이나 복잡한 관계가 많아질수록 관계형/그래프 모델의 필요성이 커진다.
• 실제로는 한 가지 모델만 쓰기보다는, 서비스의 성격에 따라 적절히 조합하는 것이 중요하다.