jaso extends j2ee

Google의 Bigtable은 범용적인 데이터 저장 공간으로 활용이 가능하다. 혹자는 배치 작업을 위한 데이터에만 적합하다고 하지만 BigTable의 논문에서는 분명히 General purpose라고 말하고 있다. 인덱스의 구조를 자세히 살펴보면 충분히 온라인 업무에서도 사용 가능하도록 구성되어 있다. 실제 논문 마지막에 있는 Real Application 부분에서도 보면 Personalized Search, Google Analytics와 같은 온라인 업무에서도 사용하고 있다고 리포트 한다.

Bigtable이 온라인 업무에서도 적절한 속도를 보장하는 것은 독특한 인덱스 정책과 하이브리드 방식(메모리/디스크)의 데이터 저장, row 기반의 데이터 모델링 등을 통해서 가능하다.

1. 독특한 인덱스 정책
일반적인 DBMS의 경우 index는 index와 연결된 레코드를 직접 가리키고 있다. index를 찾아 오는 순간 바로 하나의 데이터에 대한 직접적인 접근이 가능하다. BigTable의 경우 index는 대충의 위치만 가리킨다. 여기서 대충의 위치는 범위를 가리킨다. 해당 데이터에 대한 위치를 서버, 파일, 파일의 offset 정도로 나타내는데 file offset의 경우 정확한 위치가 아니라 64KB(조정 가능) 블럭에 대한 위치이다. 이 블럭의 처음부터 끝까지 scan을 하면 원하는 값이 있다라는 의미이다. 따라서 일반적인 DBMS보다 검색 속도는 다소 떨어진다.
index를 이렇게 구성한 이유는 index의 크기 때문이라고 생각한다. Google에서 관리하는 대부분의 데이터는 row가 최소 몇억이상이다. 이런 데이터에 대해 모든 row에 index를 만든다는 것은 index의 사이즈 역시 몇십 GB, 또는 몇 TB가 될 수 있기 때문에 index에 대한 scan 속도도 무시 못한다. 물론 저장도 문제가 된다.

2. 하이브리드 방식
BigTable의 데이터, index 파일은 분산파일시스템에 저장된다. 이것은 다시 말해 RandomAccess write기능 및 lock 등에 대해 제약 조건이 많다는 것을 의미한다. 이런 상태에서 빠른 insert, delete 등의 기능을 제공하기 위해 메모리 기반의 DBMS 기법을 이용한다. insert, delete에 대한 처리는 메모리에서 처리하고 메모리가 어느정도 가득차게 되면 메모리 내용을 디스크로 저장한다. 그리고 가끔 백그라운드에서 디스크에 저장되어 있는 여러개의 파일을 merge하면서 필요한 작업을 수행한다. select에 대한 처리는 MemTable, DiskTable에 대한 데이터를 merge하여 서비스 한다.

3. row 기반 데이터 모델링
BigTable은 기본적으로 다양한 검색 조건에 대한 처리는 온라인 서비스로 제공하지 않는다. row-key에 대해 between, like 등에 대해서 온라인 서비스가 가능한 속도 보장은 어렵다. 따라서 대부분의 온라인 검색은 row-key 기반으로 조회가 되어야 한다. 이런 모델이 되도록 데이터 모델을 해야하고 BigTable을 온라인으로 사용하는 업무도 이런 특성을 가진 업무에 국한된다 할 수 있다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준