NoSQL 자료 구조

어제 글에서 RDBMS에 B+Tree 구조로 인해서

읽기에는 강하지만 쓰기에는 약하다고 이야기를 했었다.

(깜박하고 비공개로 해놔서 지금 다시 띄워놨다)

암튼 NoSQL은 쓰기 성능의 병목을 해결하기 위해 등장했는데

RDBMS가 정합성(ACID)과 조회에 집중했다면,

NoSQL은 유실되든 일관성이 안맞든 일단 많이 빨리 저장하고 싶다 라는 니즈에서 출발했다.

이러한 니즈에 맞춰 미친 듯한 쓰기 속도를 내기 위한 자료구조로 LSM-Tree를 사용한다.

RDBMS가 데이터를 "제자리에 찾아가서" 쓴다면, LSM Tree 기반 NoSQL은 데이터를 무조건 맨 뒤에 추가한다.

데이터 저장시 디스크 헤드를 이리저리 움직이는 Random I/O는 찾아야할 제 자리가 있기 때문이다.

그럼 만약 자리 상관없이 로그 마냥 끝에 갖다 붇인다면?

가장 큰 고민인 저장 비효율이 사라지는 것이다.

수정 안한다 그냥 일단 추가한다.

그냥 쓴다고 대충 쓰는 것도 아니다 체계적인 프로세스가 있다.

컴퓨터 하드웨어 구조상 일반적인 저장요소(CPU 내부 메모리 칩 이런거 말고) 중 가장 효율적인 Write가 가능한 곳은 메모리다.

데이터가 들어오면 디스크가 아닌 먼저 메모리에 있는 MemTable에 저장한다.

메모리 내에서는 정렬된 상태를 유지한다.

(메모리라서 작업 속도가 빠르다)

MemTable이 가득 차면, 내용을 그대로 디스크의 파일로 덤프한다.

이 파일을 SSTable(Sorted String Table)이라고 한다.

여기서 쓰기가 계속 되면 SSTable이 1번, 2번, 3번...처럼 쌓이는데,

백그라운드에서는 주기적으로 이 파일들을 병합하고 정리한다.

MemTable, SSTable 1번, SSTable 2번...

데이터 저장 구조가 분산 된 것을 보면 알겠지만,

일단 데이터 찾으려면 어디에 있는지부터 찾아야한다.

다만 읽기 성능을 보완하고자 하는 장치가 있는데,

하나는 아까 설명한 파일 병합하고 정리하는 Compaction(컴팩션)이고,

다른 하나는 Bloom Filter다.

데이터 찾으려면 수많은 파일을 뒤져야하는데,

만약 없는 데이터면?

모든 파일은 다 뒤적거리면서 데이터도 못 얻고 자원만 낭비한다.

블룸 필터는 최악의 경우만 피하기 위해 각각의 파일 집합 마다 데이터 포함 여부를 검사하는 자료구조다.

블룸 필터는 단 2가지 대답만 한다.

내부 구조와 동작 원리를 이야기하고자 한다면 아티클을 또 따로 파야하니, 일단 명시만 하고 넘어가겠다.

RDBMS는 B+Tree 구조로 데이터를 정렬해준다.

덕분에 읽기가 빠르고 데이터에 대한 정합성을 보장한다.

다만 데이터 정렬 구조상 제 자리를 찾아야하기 떄문에,

쓰기가 많아지면 디스크 헤드가 이리저리 널을 뛴다(Random I/O)

NoSQL은 LSM-Tree 방식으로 일단 쓴다.

메모리에 먼저 박고, 최적화 해서 디스크에 순서대로 들이분다.

최적화 고려 안하고 일단 생성만 하니 읽을 때 구조적으로 여러 파일을 뒤져야하니 최악의 경우 모든 데이터를 조회하는 문제가 발생 할 수 있었다.

이 문제는 블룸 필터를 문지기로 세워서 없는 놈만 빠르게 걸러냈다.