저장소와 검색

DB를 제대로 고르려면, 내부에서 데이터를 물리적으로 어떻게 저장하고 찾는지 알아야 해. 결국 저장소 엔진의 선택이 워크로드의 성패를 가르거든.

가장 단순한 DB를 상상해보자 — 파일에 키-값 쌍을 한 줄씩 추가하는 거. 쓰기는 O(1)으로 빠르지만 읽기는 O(n)으로 끔찍해. 읽기를 살리려면 색인(index) 이 필요한데, 여기서 핵심 트레이드오프가 나와. 색인은 읽기를 빠르게 하지만 쓰기를 느리게 한다. 이 한 문장이 저장소 엔진 설계의 전부야.

양대 산맥은 LSM 트리와 B 트리야. LSM 트리는 쓰기를 먼저 인메모리 균형 트리(멤테이블)에 모아서, 일정 크기가 되면 정렬된 파일(SSTable)로 디스크에 쓰고, 백그라운드에서 병합하지. 순차 쓰기만 하니까 디스크에서 빠르고 압축률도 좋아. B 트리는 고정 크기 페이지 단위로 읽고 쓰면서 트리 구조를 유지해. 키의 위치가 한 곳에 있으니까 읽기가 빠르고, WAL(쓰기 전 로그) 로 충돌을 복구하지. LSM이 쓰기에 강하고 B 트리가 읽기에 강하다는 게 일반적인 결론인데, 워크로드에 따라 달라져.

그런데 OLTP와 OLAP는 접근 패턴이 완전히 달라. OLTP는 소수의 레코드를 키로 조회하는 짧은 트랜잭션이고, OLAP는 수십억 행에서 몇 개 컬럼만 집계하는 긴 질의야. 같은 엔진으로 둘 다 잘하기는 어렵지. 그래서 별도의 데이터 웨어하우스를 만들고 ETL로 데이터를 옮겨서 분석하는 구조가 보편적이야.

여기서 게임 체인저가 칼럼 지향 저장소야. 100개 컬럼에 수십억 행인 팩트 테이블에서 분석 질의가 4~5개 컬럼만 쓴다면, 행 단위로 저장하면 95개 컬럼을 쓸데없이 읽는 거잖아. 칼럼 단위로 저장하면 필요한 컬럼만 읽으면 돼. 게다가 같은 칼럼의 값들은 비슷한 경향이 있어서 비트맵 부호화와 런 렝스 부호화로 압축이 잘 되고, 비트 연산으로 필터링도 빠르지.

---

정리

3장 읽고 기억할 거:

1. LSM 트리 vs B 트리 — 저장소 엔진의 양대 산맥. LSM은 쓰기에 강하고(순차 쓰기), B 트리는 읽기에 강하다(키 위치가 한 곳). 워크로드에 따라 선택
2. OLTP와 OLAP는 접근 패턴이 완전히 다르다. 같은 엔진으로 둘 다 잘하기는 어렵고, 데이터 웨어하우스로 분리하는 게 현실적이다
3. 칼럼 지향 저장소는 분석 질의의 게임 체인저. 필요한 칼럼만 읽고, 압축도 잘 되고, 비트맵 색인으로 필터링도 빠르다