4. 스토리지 엔진의 공통 변수

스토리지 엔진은 특정 자료구조를 기반으로 만들어진다.

하지만 캐싱, 복구, 트랜잭션과 같은 기능은 이런 자료구조가 설명해주지 않는다.

 

스토리지 구조에는 크게 3가지 공통 변수가 있다.

 

1. buffering 사용 여부

2. immutable file 또는 mutable file 사용

3. 데이터 저장시 정렬 여부

 

스토리지 구조가 갖는 최적화 방법과 구별 기준 대부분은 이 3가지 개념 중 하나와 관련되어 있다.

 

Buffering

스토리지 구조가 디스크에 데이터를 저장하기 전에 특정 양의 데이터를 모았다가 저장하는지 아닌지를 나타낸다.

물론 모든 디스크 기반 구조는 어느정도 버퍼링 기법을 사용할 수 밖에 없다.

디스크가 최소한 block 단위로 데이터를 전달하므로, 블록 데이터를 모았다가 쓰는 것이 좋기 때문이다.

따라서 버퍼링을 사용하지 않는 내용을 다룰 때는 '스토리지 구현시 피할 수 있는' 관점에서 다룰 것이다.

 

최적화 관점에서 버퍼링 여부를 보면 B-Tree 노드에 in-memory 버퍼를 둬서 I/O 비용을 줄이는 예시를 생각할 수 있다.

그리고 two-component LSM Tree 는 B-Tree 와 유사하지만, 버퍼링을 사용할 때는 전혀 다른 방식으로 사용하며, 버퍼링을 불변성과 함께 사용한다.

 

 

Mutability ( Immutability)

스토리지 구조가 파일의 일부에 대해 읽고, 수정하고, 수정한 결과를 디스크에 쓸 수 있는지 여부를 나타낸다.

불변 구조의 경우 append-only 특성을 가진다.

따라서 한번 데이터를 쓰면, 그렇게 쓰여진 내용은 변하지 않는다.

수정사항이 생기면 해당 수정사항은 파일 끝에 추가된다.

 

불변성을 구현하는 다른 방법으로는 conpy-on-write 방법이 있다.

이 방법은 페이지를 수정할 때 레코드를 수정한 버전을 갖고 있다가 기존 페이지가 아니라 파일 내 새로운 페이지에 변경 사항을 쓰는 방식을 사용한다.

 

LSM 과 B-Tree 사이의 차이점은 보통 in-place 스토리지 변경에서 불변성 여부로 묘사되는데, B-Tree 에서 나온 immutable 구조인 Bw-Tree 와 같은 구조도 존재한다. (이를 보면 B-Tree 는 mutable 하고, LSM 은 immutable 한 것 같다.)

 

Ordering

데이터 레코드가 디스크 페이지에 키 순서대로 저장되는지 여부를 나타낸다.

즉, 키 값 기준으로 정렬된 데이터는 디스크 세그먼트에 연속적으로 저장된다.

정렬 여부를 통해 특정 레코드를 찾는 성능에 더해 레코드의 범위 탐색을 효율적으로 할 수 있는지를 알 수 있다.

 

데이터를 정렬하지 않고 저장하는 경우 (삽입된 순서대로 저장하는 등) 쓰기 시간을 최적화할 수 있다.

예를 들어 Bitcask 와 WiscKey 는 데이터 레코드를 append-only 파일에 삽입된 순서대로 저장한다.

 

 

뒤 내용을 정리하면서 이 세 가지 개념을 더 자세하게 정리할 것이다.