BigTable의 Tablet Serving과 Compaction 그리고 Lucene의 Incremental Indexing

작성일자 글쓴이

김형준님의 강의를 바탕으로 논문을 보고 있는데, 강의 들으면서 낯설지 않은 부분이 Tablet Serving과 Compaction 부분이였다.

한번 정리해 본다.

논문에 나온 그림

새로운 데이터가 들어올때.
BigTable의 DB 무결성을 유지하기 위해서 메모리기반의 버퍼를 유지하고 또한 그 버퍼의 Copy를 이용해서 계속 서비스를 유지하게 하면서 minor compaction을 수행한다. 물론 minor compaction이 완료가 되면 메모리를 지운다.

그 강의에는 나오지 않았지만, 업데이트시를 정리해본다.(나름 추측하는 부분도 써넣었다.)

1. redo log를 작성한다.
2. tablet server가 METADATA table을 읽어들여 redo log가 가르키는 해당 SSTable을 읽어 들인다.
4. 해당 SSTable을 메모리(memtable)에 로딩하여 필요한 부분을 업데이트 시킨다.
5. 로그나 SSTable 인덱스에 그 해당 레코드를 삭제 표시한다.(나의 예상이다)

write시는 좀 간단하다.

1. redo log를 작성한다.
2. memtable에 쓴다.

문제는 memtable이 full이 났을때와 검색시인데.

강의에서 memtable이 풀이 나버리면 기존의 memtable을 freeze하고 새로운 memtable을 하나 복사한 다음에 새로운 SSTable로 쓰는 작업을 백그라운드에서 한다. 쓰는 도중에 복사된 memtable로 계속적으로 서비스가 가능하다.
물론 새로운 SSTable에 할당이 완료되면 그 memtable은 지워지고 commit log또한 지워진다.

이를 minor compaction이라고 하는데 문제는 삭제되거나 update된 데이터를 어떻게 처리하느냐다.

검색시 나오지 않게 하기위해서는 SSTable index에 삭제된 데이터로 표시를 하거나, Log에 표시를 함으로써 검색이 바로 되지 않게 하는 방법도 있겠다. 물론 Lucene에서는 삭제된 파일을 표시하기 위한 파일을 하나 유지한다. 바로 그런 방법으로 삭제된 데이터나 업데이트 된 데이터에 대해서 정확도 유지를 하지 않을까 해본다. 물론 업데이트자료에는 memtable의 데이터에 우선권을 두는 방식으로 하면되겠고.

그래서 중요한게 major compaction이다.
이는 여러개의 SSTable을 하나의 SSTable로 병합하는 건데. 이렇게 병합하면서 삭제된 표시가 된 데이터에 대한 실제 삭제 작업을 하게된다.
루씬에서도 증분색인을 하면서 이와 똑같은 작업을 한다. 실제 merge작업시 삭제 표시된 문서를 지우고 메모리에다 segment를 만들면서 다 완성이 되면 파일로 쓰고 old segment 파일을 지우는 로직이다. 그래서 절대 색인이 깨지거나 데이터가 날라갈 이유가 없다.
또한 색인중에도 검색이 가능한 이유도 되겠고.
BigTable도 마찬가지로 저장중에 정확한 검색이 가능하고, 갑작스런 시스템 다운시 복구가 빠르다.

BigTable 과 루씬 인덱스 간의 비교를 간단하게 해봤다.

BigTable 대 Lucene
memtable : ramsegment
SSTable : FileSegment
compaction : incremental indexing
Log : 루씬은 없음

Log를 이용한 atomic transection이 불가능한게 Lucene과 BigTable의 File 오퍼레이션의 유일한 차이점인거 같다.(Log를 유지하지 않아도 루씬은 색인 데이터가 날라가지 않는다. 왜냐면 old segment 파일을 유지하기 때문이다.)

그러니 그런 SSTable 구조를 루씬 인덱스로 대체하고, 거기다가. BigTable에 나오는 Chubby Server, Master Server, Tablet Server만 잘 버무리면 reliable한 대용량 검색엔진도 가능할거 같기도하다.

방금 Typos님에게 이런식이면 어떠냐구 물어봤는데, 그게 nutch 구조라고 하신다. ㅋㅋㅋㅋ

역시나 잘나가는 DB들은 장점을 공유하는거 같다.
이렇게 해서 DB 무결성은 유지가 되는거구.

오랜만에 Lucene 파일구조를 다시 살펴보고 그랬다. 역시나 비교 분석은 새로운 정보를 얻는데 중요한 역할을 한다. ㅎㅎㅎ

내일은 BigTable의 다른 부분에 대한 고민을 해봐야 겠다.

CC BY-NC 4.0 BigTable의 Tablet Serving과 Compaction 그리고 Lucene의 Incremental Indexing by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.