관계 탐색 비교

Graph DB는 관계를 다시 계산하지 않고 저장된 연결을 그대로 따라간다

같은 3-hop 조회라도 차이는 문법보다 저장 방식에서 생깁니다. 그래서 다단계 연결이 많은 문제일수록 Graph DB 쪽 쿼리 의도와 실행 경로가 더 직접적으로 맞물립니다.

공통 질문

사용자 `1001`의 친구의 친구의 친구를 찾는다 이 한 질문이 두 시스템에서 어떻게 다른 작업으로 바뀌는지 비교합니다.

비교 축

RDB

Graph DB

관계 저장 무엇을 읽고 시작하나

`friends` 같은 연결 테이블을 다시 조합

친구 관계가 행으로 분리되어 있어, 경로를 찾으려면 매 단계마다 다음 연결 행을 이어 붙여야 합니다.

노드와 `FRIEND` 간선이 이미 연결된 상태

관계가 데이터 모델 안에 직접 있으므로, 조회는 “다음 간선을 따라간다”는 탐색으로 읽힙니다.

쿼리 모양 질문이 어떻게 표현되나

hop 수만큼 JOIN 증가

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;

경로 패턴이 그대로 보임

MATCH (:User {id:1001})-[:FRIEND*3]->(target)
RETURN target

깊이 증가 4-hop, 5-hop이 되면

조인 수와 중간 결과 관리가 함께 커진다

`N-hop` 탐색이 사실상 `N번 자기 조인`으로 바뀌어, 쿼리 가독성과 실행 계획이 동시에 무거워집니다.

같은 탐색 모델로 더 멀리 따라가면 된다

경로 길이만 바꾸면 되므로, 관계 중심 질의에서는 쿼리 의도와 모델 구조가 계속 일치합니다.

운영 의미 언제 차이가 크게 드러나나

연결이 깊을수록 관계 복원 비용이 누적

소셜 그래프나 추천처럼 여러 단계를 따라가야 하는 문제에서는 조인 중심 모델이 빠르게 복잡해질 수 있습니다.

연결을 따라가는 작업 자체가 1급 연산

추천, 사기 탐지, 지식 그래프처럼 “누가 누구와 어떻게 이어졌는가”가 핵심인 질의에서 강점을 보입니다.

학습 포인트: Graph DB의 장점은 단순히 쿼리 문법이 짧다는 데 있지 않습니다. 관계를 저장된 구조로 다루기 때문에, 깊은 연결 탐색에서 질문과 실행 방식이 더 자연스럽게 이어진다는 점이 핵심입니다.