[데이터 중심 애플리케이션 설계] 03장 - 저장소와 검색
2장에서 애플리케이션 개발자가 데이터베이스에 데이터를 제공하는 형식을 설명했다. 그리고 나중에 다시 요청할 수 있는 메커니즘인 데이터 모델과 질의 언어도 살펴봤다. 이번 장에서는 같은 내용을 데이터베이스 관점에서 살펴본다. 즉, 데이터베이스가 데이터를 저장하는 방법과 데이터를 요청했을 때 다시 찾을 수 있는 방법을 설명하겠다.
1. 해시 색인
키-값 저장소는 대부분의 프로그래밍 언어에서 볼 수 있는 사전 타입(dictionary type)과 매우 유사하다.
단순히 파일을 추가하는 방식으로 데이터 저장소로 구성한다면 키를 데이터 파일의 바이트 오프셋에 매핑해 인메모리 해시 맵을 유지하는 전략이 가장 간단하게 가능한 색인 전략 중 하나가 된다. 매우 단순해 보이지만 실제로 많이 사용하는 접근법이다.
위 방식은 파일을 계속 추가만 하는 구조이고 동일한 키에 대해서 최근에 추가한 파일을 조회하게 되는데 이 경우 특정 크기의 세그먼트(segment)로 파일을 나누는 방식이 디스크 공간의 부족을 극복하는 좋은 해결책이다. 또한 여기에 컴팩션(compaction)을 통해 중복된 키를 버리고 각 키의 최신 갱신 값만 유지하는 방식으로 디스크 공간을 확보할 수 있다.
2. SS 테이블(Sorted String Table)과 LSM 트리(Log-Structed Merge-Tree)
SS 테이블은 정렬된 문자열 테이블이라는 뜻으로 일련의 키-값 쌍을 키로 정렬한 구조이다. 해시 색인의 세그먼트들에서 각 세그먼트가 키를 기준으로 정렬된 것과 같다. LSM 트리는 SS 테이블을 효율적으로 관리하는 구조이다.
LSM 트리에서 각 세그먼의 키들은 고유하며 정렬되어 있고 병합된 세그먼트 역시 마찬가지다. 병합 과정은 각 세그먼트의 첫 번째 키를 통해 가장 낮은 키부터 출력 파일로 복사한 뒤 병합하는 과정이 반복되며 이 덕분에 서로 다른 세그먼트에 동일한 키가 각각 존재할 경우 최근에 쓴 값이 반영된다. 특정 키를 찾는 경우 해시 색인에서는 모든 키가 메모리 상에 적재되어 있었지만 LSM 트리는 각 세그먼트의 특정 키(sparse index)들만 적재해서 특정 키가 존재하는 구간을 찾을 수 있다.
3. B 트리
B 트리는 SS 테이블과 같이 키로 정렬된 키-값 쌍을 유지하기 때문에 키-값 검색과 범위 쿼리에 효율적인 자료구조이다. B 트리는 LSM이 일반적으로 수 메가바이트의 가변 크기를 가진 세그먼트로 나누고 순차적으로 세그먼트를 기록하는 것과 달리 고정 크기의 페이지로 데이터를 나누고 한 번에 하나의 페이지에 읽기 또는 쓰기를 한다.
4. OLTP(online transaction processing), OLAP(online analytic processing)
OLTP는 온라인 트랜잭션 처리라는 뜻으로 사용자 입력을 기반으로 레코드가 삽입되거나 갱신되는 대화적 특성에서 붙은 이름이다. 반면 OLAP는 온라인 분석 처리라는 뜻으로 비즈니스 분석을 위해 데이터베이스에 접근하는 특성에서 붙은 이름이다.
OLTP와 OLAP는 아래와 같이 시스템의 특성을 비교해볼 수 있다.
| 특성 | 트랜잭션 처리 시스템(OLTP) | 분석 시스템(OLAP) |
|---|---|---|
| 주요 읽기 패턴 | 질의당 적은 수의 레코드, 키 기준으로 가져옴 | 많은 레코드에 대한 집계 |
| 주요 쓰기 패턴 | 임의 접근, 사용자 입력을 낮은 지연 시간으로 기록 | 대규모 불러오기 또는 이벤트 스트림 |
| 주요 사용처 | 웹 애플리케이션을 통한 최종 사용자/소비자 | 의사결정 지원을 위한 내부 분석가 |
| 데이터 표현 | 데이터의 최신 상태(현재 시점) | 시간이 지나며 일어난 이벤트 이력 |
| 데이터셋 크기 | 기가바이트에서 테라바이트 | 테라바이트에서 페타바이트 |
Ref
- 데이터 중심 애플리케이션 설계 - p.71 ~ p.111