Property Graph와
그래프 데이터베이스
그래프 DB의 핵심 데이터 모델을 이해하고, 주요 제품과 표준 질의 언어를 비교합니다.
PART 0에서 우리는 "데이터를 저장하는 것"과 "이해하는 것"의 차이를 배웠습니다.
관계형 데이터베이스(RDB)는 테이블에 데이터를 저장하지만,
데이터 사이의 "관계"를 탐색하는 데는 비효율적입니다.
RDB의 한계: JOIN의 비용
RDB에서 "홍길동의 친구의 친구가 본 영화"를 찾으려면?
사용자 테이블 JOIN 친구관계 테이블 JOIN 친구관계 테이블 JOIN 시청기록 테이블 JOIN 영화 테이블
테이블이 5개, JOIN이 4번.
관계가 깊어질수록 쿼리 복잡도와 실행 시간이 기하급수적으로 증가합니다.
반면 그래프 DB에서는?
MATCH (홍길동)-[:친구*2]->(friend)-[:시청]->(movie) RETURN movie
한 줄이면 됩니다. 관계 탐색이 DB의 본질이기 때문입니다.
핵심 메시지
RDB는 "무엇을 저장할까"에 최적화되어 있고,
그래프 DB는 "무엇이 어떻게 연결되어 있을까"에 최적화되어 있습니다.
데이터 간의 관계가 핵심인 도메인에서는 그래프 DB가 압도적으로 유리합니다.
그래프 데이터베이스의 가장 대표적인 데이터 모델이
Property Graph(속성 그래프)입니다.
Neo4j, TigerGraph, ArangoDB 등 대부분의 그래프 DB가 이 모델을 사용합니다.
4가지 핵심 구성요소가 있습니다.
노드 (Node)
그래프의 "점"
사람, 영화, 장소 등
하나의 엔티티(개체)를 표현
관계 (Relationship)
그래프의 "선"
노드 사이의 연결을 표현
항상 방향이 있음 (A→B)
속성 (Property)
노드나 관계에 붙는 키-값 쌍
이름:"홍길동", 나이:30
관계에도 속성 가능: 평점:4.5
라벨 (Label)
노드의 유형/카테고리
:Person, :Movie 등
하나의 노드에 여러 라벨 가능
age: 30
year: 2010
RDF Triple과의 차이
PART 0에서 배운 RDF Triple은 (주어, 술어, 목적어) 세 요소로 구성됐습니다.
Property Graph와의 핵심 차이:
RDF: 관계에 속성을 붙일 수 없음. "홍길동이 인셉션을 봤다"는 표현 가능하지만, "별점 4.5"를 관계에 직접 붙이려면 별도 구조(Reification)가 필요
Property Graph: 관계 자체에 속성을 자유롭게 부여 가능. [:WATCHED {rating: 4.5}]
즉, Property Graph는 실용적이고, RDF는 표준적·논리적입니다.
둘 다 "그래프"지만, 설계 철학이 다릅니다.
Property Graph의 핵심
노드는 "무엇이 있는가",
관계는 "어떻게 연결되는가",
속성은 "그것의 구체적 정보",
라벨은 "그것의 유형"을 표현합니다.
이 네 가지만 알면, 어떤 데이터든 그래프로 모델링할 수 있습니다.
Property Graph 모델을 사용하는 대표적인 그래프 데이터베이스를 비교합니다.
| 비교 기준 | Neo4j | TigerGraph | ArangoDB |
|---|---|---|---|
| 한 줄 요약 | 가장 대중적인 그래프 DB |
대규모 분석 특화 고성능 그래프 DB |
그래프 + 문서 + KV 멀티모델 DB |
| 질의 언어 | Cypher 직관적, 패턴 매칭 기반 |
GSQL 절차적, 대규모 분석용 |
AQL SQL과 유사한 문법 |
| 강점 | 거대한 생태계 풍부한 문서·커뮤니티 GDS(그래프 분석) 라이브러리 |
수십억 노드 처리 병렬 분산 처리 실시간 딥링크 분석 |
하나의 DB로 다양한 데이터 모델 지원 유연한 스키마 |
| 약점 | 대규모 분산 처리에 상대적으로 약함 |
학습 곡선이 가파름 커뮤니티가 작음 |
그래프 전용 기능이 Neo4j 대비 부족 |
| 적합한 경우 | 입문·학습·중소규모 그래프 프로젝트 |
엔터프라이즈급 대규모 그래프 분석 |
여러 데이터 모델을 하나로 통합하고 싶을 때 |
| 라이선스 | Community(무료) Enterprise(유료) |
Community(무료) Enterprise(유료) |
Community(무료) Enterprise(유료) |
왜 Neo4j부터 배우는가?
입문자에게 Neo4j가 가장 적합한 이유는 간단합니다.
1. Cypher가 직관적이라 배우기 쉬움
2. 문서와 튜토리얼이 압도적으로 많음
3. 무료 클라우드(AuraDB)로 설치 없이 바로 시작 가능
4. GDS(Graph Data Science) 라이브러리로 그래프 분석까지 확장 가능
5. Cypher를 배우면 GQL 국제 표준도 거의 알게 됨
Neo4j의 질의 언어인 Cypher는 2024년,
ISO 국제 표준 GQL(Graph Query Language, ISO 39075)의 기반이 되었습니다.
GQL이란?
GQL은 SQL의 그래프 버전이라고 생각하면 됩니다.
SQL이 관계형 DB의 국제 표준 질의 언어인 것처럼,
GQL은 그래프 DB의 국제 표준 질의 언어입니다.
2024년 4월, ISO/IEC 39075로 공식 발표되었으며,
Neo4j의 Cypher가 GQL의 핵심 기반이 되었습니다.
Cypher와 GQL의 관계
Cypher = GQL의 사실상 원본이라고 볼 수 있습니다.
Cypher(2012년 Neo4j 도입) → openCypher(2015년 오픈소스화) → GQL(2024년 ISO 표준)
문법이 거의 같기 때문에,
Cypher를 배우면 GQL도 사실상 배우는 것입니다.
MATCH (p:Person)-[:WATCHED]->(m:Movie) WHERE p.name = "홍길동" RETURN m.title, m.year
MATCH (p:Person)-[:WATCHED]->(m:Movie) WHERE p.name = "홍길동" RETURN m.title, m.year
기본 문법이 거의 동일합니다. 세부 확장 문법에서만 차이가 있습니다.
SQL과 Cypher, 문법 비교
이미 SQL을 아는 분이라면 이 비교가 도움이 될 겁니다.
| 작업 | SQL (RDB) | Cypher (Neo4j) |
|---|---|---|
| 데이터 조회 | SELECT * FROM users |
MATCH (u:User) RETURN u |
| 조건 필터 | WHERE age > 25 |
WHERE u.age > 25 |
| 관계 탐색 | JOIN ... ON ...테이블 간 키로 연결 |
(a)-[:관계]->(b)패턴으로 직접 표현 |
| 데이터 생성 | INSERT INTO ... |
CREATE (n:Label {...}) |
| 데이터 수정 | UPDATE ... SET ... |
SET n.prop = value |
| 데이터 삭제 | DELETE FROM ... |
DETACH DELETE n |
Cypher의 핵심 철학
SQL이 "어떤 테이블에서 어떤 컬럼을" 표현한다면,
Cypher는 "어떤 패턴으로 연결된 것을" 표현합니다.
(노드)-[관계]->(노드) 이 패턴이 Cypher의 전부입니다.
다음 챕터에서 이 문법을 본격적으로 다룹니다.
이 페이지에서 기억할 것
1. 그래프 DB가 필요한 이유
관계 탐색은 RDB의 JOIN보다 그래프 DB의 패턴 매칭이 훨씬 효율적
2. Property Graph 4요소
노드(점) + 관계(선) + 속성(키-값) + 라벨(유형) → 이것으로 모든 데이터를 표현
3. Neo4j를 먼저 배우는 이유
가장 대중적, 가장 많은 자료, 무료 클라우드 제공, Cypher = GQL 표준 기반
4. Cypher = GQL
Neo4j의 Cypher가 ISO 국제 표준 GQL의 기반. 하나를 배우면 둘 다 아는 것
5. SQL과 Cypher의 차이
SQL: 테이블 + JOIN으로 관계 표현 / Cypher: (노드)-[관계]->(노드) 패턴으로 직접 표현