이 글은 책 내용을 토대로 작성하였습니다.
목차
B 트리와 LSM 트리 비교
읽기 속도 : B 트리 > LSM 트리
쓰기 속도 : B 트리 < LSM 트리
-
B 트리가 LSM에 비해 읽기 속도가 빠른 이유는
LSM 트리는 각 컴팬션 단계에 있는 여러 데이터 구조와 SS테이블을 확인하기 때문이다.
-
하지만 실제 다루는 데이터에 따라 성능이 달라질 수 있으므로
실제 필요한 작업부하로 시스템 테스트 후 선정하는 것이 좋다.
LSM 트리의 장점
쓰기 증폭
-
B 트리 인덱스는 모든 데이터 조각을 최소 2번 기록해야 한다.
쓰기 전 로그 1번 + 트리 페이지에 1번
또한 페이지 내 몇 바이트만 변경이 일어나면
한 번에 전체 페이지를 기록해야 하는 오버헤드도 있다.
-
로그 구조화 인덱싱 또한
SS테이블의 반복된 컴팩션과 병합으로 인해 n번 데이터를 다시 쓴다.
-
이처럼 DB가 쓰기 요청 1번을 수행할 때
디스크에 n번의 작업을 하게 되는 효과를
쓰기 증폭(Write Amplification)이라 한다.
-
SSD는 수명이 다할 때까지 블록 덮어쓰기 횟수가 제한되기 때문에
쓰기 증폭은 SSD의 경우 특별한 관심사이다.
-
쓰기가 많은 어플리케이션에 성능 병목은 DB가 디스크에 쓰는 속도일 수 있다.
이 경우 쓰기 증폭은 바로 성능비용이다.
쓰기 처리량
-
LSM 트리는 B 트리보다 쓰기 처리량을 많게 유지할 수 있다.
LSM 트리가 상대적으로 쓰기 증폭이 더 낮고
트리에서 여러 페이지를 덮어쓰는 것이 아니라
순차적으로 컴팩션된 SS테이블 파일을 쓰기 때문이다.
-
그래서 이런 차이는 HDD에서 특히 중요한데
HDD에 데이터를 기록할 때 순차 쓰기가 임의 쓰기보다 훨씬 빠르다.
압축률
-
LSM 트리는 보통 B 트리보다 더 적은 파일을 생성한다.
-
B 트리 저장소 엔진은 파편화로 인해
사용하지 않는 디스크 공간 일부가 남는다.
페이지를 나누거나 로우가 기존 페이지에 맞지 않을 경우
페이지의 일부 공간은 사용하지 않게 되기 때문이다.
-
LSM 트리는 페이지 지향적이지 않고
주기적으로 파편화를 없애기 위해 SS테이블을 다시 기록하므로 저장소 오버헤드가 더 낮다.
LSM 트리의 단점
컴팩션 과정
-
로그 구조화 저장소의 단점은 컴팩션 과정이 때로는
진행중인 R/W 성능에 영향을 준다는 점이다.
-
저장소 엔진은 컴팩션을 점진적으로 수행하고 동시 접근의 영향이 없게 수행하려 한다.
하지만 디스크가 가진 자원은 한계가 있다.
그래서 디스크에서 컴팩션 연산이 끝날 때까지
요청이 기다려야 하는 상황이 발생하기 쉽다.
높은 쓰기 처리량
-
또 다른 컴팩션 문제는 높은 쓰기 처리량에서 발생한다.
디스크의 쓰기 대역폭은 유한하다.
초기 쓰기와 백그라운드에서 수행되는 컴팩션 쓰레드가 이 대역폭을 공유해야 한다.
빈 DB에 쓰는 경우 전체 디스크 대역폭은 초기 쓰기만을 위해 사용할 수 있지만
DB가 점점 커질수록 컴팩션을 위해 더 많은 디스크 대역폭이 필요하다.
컴팩션 설정
-
컴팩션 설정을 주의 깊게 하지 않으면
컴팩션이 쓰기 요청 속도를 따라갈 수 없다.
-
이 경우 디스크 상에 병합되지 않은 세그먼트 수는
디스크 공간이 부족할 때까지 증가한다.
그리고 더 많은 세그먼트 파일을 확인해야 하므로 읽기 또한 느려진다.
-
보통 SS테이블 기반 저장소 엔진은
컴팩션이 유입 속도를 따라가지 못해도
유입 쓰기의 속도를 조절하지 않으므로
이런 상황을 감지하기 위한 명시적 모니터링이 필요하다.