6장: 데이터베이스와 스토리지 — 키-값 저장소에서 그래프 DB까지

관계형과 비관계형

책은 데이터베이스를 관계형과 NoSQL(비관계형)로 크게 나눈다. 관계형 데이터베이스의 핵심 개념은 익숙한 것들이다. 테이블, 행, 열, 키, SQL, 그리고 정규화와 ACID, 트랜잭션.

• 정규화 — 데이터 중복을 제거하고 무결성을 높인다
• ACID — 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)을 보장한다
• 트랜잭션 — 여러 SQL 작업을 하나의 묶음으로 처리하고, 도중에 오류가 나면 전체를 되돌려 일관성을 유지한다

비관계형 데이터베이스는 저장과 검색에서 더 유연한 방식을 취하며, 네 가지 계열로 나뉜다.

트레이드오프를 정리하면 이렇다.

키-값 저장소 설계

키-값 저장소는 고유한 키가 특정 값과 연결되는 가장 단순한 데이터 모델이다. 구조가 간단한 덕에 읽기와 쓰기 효율이 높고, 분산시켰을 때 확장성, 성능, 유연성, 장애 허용성을 확보하기 쉽다.

책은 이 저장소를 직접 설계하는 과정을 따라간다. 시작은 언제나 요구 사항 정의다.

• 기능적 요구 사항 — put(key, value), get(key), delete(key)
• 비기능적 요구 사항 — 노드 추가로 확장 가능해야 하고, 높은 가용성과 낮은 지연 시간을 유지해야 한다

확장성과 데이터 복제

데이터를 여러 노드에 나누는 수단이 앞 장에서 본 일관된 해싱과 가상 노드다. 그 위에 복제 전략을 얹는다.

주-종 모델은 쓰기 경로가 하나라 일관성 관리가 쉽지만 주 노드가 병목이자 단일 장애점이 된다. 동등 모델은 그 병목을 없애는 대신 쓰기 충돌을 해결하는 장치가 필요하다.

R과 W: 쿼럼 설정

키-값 저장소 설계에서 가장 실용적인 손잡이는 R과 W다.

N = 레플리카 총 개수
W = 쓰기 성공으로 간주하기 위해 응답해야 하는 레플리카 수
R = 읽기 응답을 만들기 위해 조회하는 레플리카 수

R + W > N이면 읽기와 쓰기의 레플리카 집합이 반드시 하나 이상 겹치므로, 읽기가 최신 쓰기를 놓치지 않는다. 이 부등식을 어떻게 만족시키는지에 따라 시스템의 성격이 달라진다.

장애 처리

일시적 장애

노드가 잠깐 응답하지 않는 상황은 쿼럼 기반 시스템으로 흡수한다. W개 이상의 노드가 응답하면 일부 노드가 응답하지 않아도 쓰기를 성공으로 처리하고, 나중에 복구된 노드를 따라잡게 만든다.

영구적 장애와 머클 트리

노드가 오래 죽어 있다 돌아왔을 때는 상황이 다르다. 레플리카 사이에 어떤 데이터가 어긋났는지를 찾아 동기화해야 하는데, 목표는 불일치를 빠르게 감지하면서 전송하는 데이터양을 최소화하는 것이다. 전체 데이터를 다 비교하는 것은 답이 아니다.

이 문제를 머클 트리(Merkle Tree) 로 해결한다.

동작 방식은 이렇다.

1. 모든 키를 해싱해 리프 노드로 만든다
2. 각 노드는 자신에게 할당된 키 범위에 대해, 가상 노드마다 고유한 머클 트리를 유지한다
3. 두 레플리카의 루트 해시를 먼저 비교한다
4. 두 해시가 같으면 데이터가 동일하므로 더 진행하지 않는다
5. 다르면 왼쪽과 오른쪽 자식 노드를 재귀적으로 탐색해 차이가 있는 리프까지 내려간다

핵심은 3번과 4번이다. 대부분의 경우 레플리카는 동일하므로, 해시 하나만 주고받고 끝난다. 다를 때만 트리를 내려가며 어긋난 범위를 좁혀 가므로, 비교 비용이 데이터 크기가 아니라 차이의 개수에 비례한다.

그래프 데이터베이스

책은 비관계형 계열 중 그래프 기반 데이터베이스를 별도로 다룬다. 복잡한 데이터 관계를 저장하고 관리하는 데 최적화된 데이터베이스다.

활용 사례는 복잡한 관계를 모델링하고 분석해야 하는 영역이다. 소셜 네트워크, 추천 엔진, 사기 탐지, 네트워크 및 인프라 관리, 지식 그래프 등이다. 그래프 데이터베이스가 특히 강한 지점은 패턴 매칭, 즉 그래프 내 특정 구조나 연결을 식별하는 작업이다.

Neo4j

대표 구현체인 Neo4j의 특징 중 눈여겨볼 것은 세 가지다.

• ACID 특성 준수 — 그래프 DB이면서도 트랜잭션 무결성을 보장한다
• 데이터 버전 관리 — 과거 데이터를 저장하고 조회할 수 있어 시간에 따른 변화 추적이나 특정 시점 상태 확인이 가능하다
• 생태계 — 활발한 오픈 소스 커뮤니티 기반으로 라이브러리와 도구가 풍부하다

관계형 모델링과 그래프 모델링의 차이

관계형 방식으로 관계를 저장하는 방법은 두 가지다.

• 단방향 저장 — 에지의 시작점과 도착점을 하나의 행으로 저장한다
• 양방향 저장 — 출발점과 도착점을 번갈아 저장하고 방향을 나타내는 열을 추가한다

그래프 방식은 데이터를 이중 연결 리스트 형태의 그래프와 두 개의 저장소(노드 저장소, 관계 저장소)로 표현한다. 예를 들어 노드 4를 추가하고 "노드 2가 노드 4를 팔로우한다"는 관계를 넣는다면, 이중 연결 리스트에 노드를 추가하고, 노드 저장소에 개체 레코드를, 관계 저장소에 에지 레코드를 각각 넣는다.

책이 흥미롭게 다루는 부분은 레코드의 물리적 크기다.

이 구조를 알면 그래프 DB가 왜 관계 탐색에 빠른지 이해된다. 관계 레코드가 이전·다음 관계 레코드를 직접 가리키는 포인터를 들고 있기 때문에, 한 노드의 관계를 순회하는 일이 연결 리스트를 따라가는 것과 같다. 관계형 데이터베이스에서 조인 테이블을 인덱스로 검색하는 것과 달리, 인덱스 조회 없이 포인터를 따라가는 것이다. 이것이 이른바 인덱스 없는 인접성(Index-free Adjacency) 이다.

정리

이 장은 데이터베이스 핵심 개념과 유형을 넓게 훑는다. 관계형과 비관계형의 구분, 키-값 저장소 설계, 그래프 데이터베이스가 주요 축이다. 기본적인 SQL이나 정규화 같은 내용은 이미 익숙한 영역이라 용어 확인 정도로 지나갔고, DynamoDB나 컬럼 패밀리, HBase 절은 개요 수준이라 깊이 파지 않았다.

건져 갈 만한 부분은 두 가지였다. 하나는 R과 W의 쿼럼 설정이 CAP의 선택을 숫자로 노출하는 지점이라는 점이고, 다른 하나는 머클 트리로 레플리카 차이만 골라 동기화하는 방식이다. 둘 다 이론이 실제 구현에 어떻게 내려앉는지 보여주는 좋은 예다.

Neo4j와 그래프 모델링은 개요에서 멈춘다. 레코드 크기와 포인터 구조를 짚어 준 것은 좋았지만, 실제로 그래프 DB를 도입할 판단을 하려면 사이퍼 쿼리 작성과 성능 특성을 별도 자료로 확인해야 할 것 같다.