점프와 쉼없는 나아감

Column-Oriented DBMS라는 것이 있다.  전통적인 DBMS는 데이터베이스 테이블을 row 단위로 저장하는데 이것은 column 단위로 저장한다.  이렇게 하는 게 무슨 이득이 있을까 생각이 들 법도 한데 데이터를 읽을 때 row 단위로 저장할 때보다 disk IO 양이 줄어들게 된다.  데이터베이스 읽기 작업을 할 때 Disk IO 작업이 가장 많은 비용이 든다는 점을 감안한다면 이러한 구조를 이용함으로써 읽기 쿼리 작업의 성능을 높일 수 있다는 것을 알 수 있을 것이다.  여기에 column 들을 정렬시켜 저장해 놓는 방식을 쓰게 되면 복잡한 쿼리(읽기) 작업의 성능이 더 좋게 된다.  물론 반대 급부로 데이터베이스를 변경하려면 row 단위 방식보다 쓰기 작업이 무척 많아지게 되기 때문에 보통 배치 작업으로 수행하게끔 업데이트 작업을 구현한다.  업데이트가 자주 발생하지 않고 대규모 데이터에 대해 복잡한 쿼리를 수행해야 하는 OLAP 환경에 적합한 DBMS 구조로 알려져 있고, 실제로 이를 겨냥한 제품도 나와 있다.(Sybase IQ, KDB 등)

c-store는 이러한 colum-oriented DBMS 중 하나로 이제 막 0.2 버전에 있는 아직은 실험적인 상태에 있는 DBMS이다.  그럼에도 불구하고 관심을 가지게 된 이유는 이것에 여러 가지 독특한 기능이 있기 때문이다.

먼저 c-store에는 데이터 압축 기능이 있다.  column 단위로 저장은 row 단위 보다 데이터 압축률이 더 높다. 데이터가 압축되어 있으면 Disk IO 가 줄어들기 때문에 성능 향상을 도모할 수 있다.  물론 압축된 데이터를 풀어야 하기 때문에 CPU Time이 더 소모되지만 추가적인 CPU Time을 소모해서라도 가장 많이 처리 비용을 발생시키는 Disk IO를 줄이겠다는 것이 기본 아이디어이다.  압축 기법을 더욱 발전시켜 압축된 상태로 쿼리를 처리하는 방법도 고안하고 있는 것 같다.  이렇게 하여 추가적인 CPU Time 소모도 방지할 수 있고 일부 쿼리에서는(특히 aggregate query) 새로운 방식의 최적화도 수행할 수 있다.

두번째로 c-store는 column-oriented DBMS의 단점인 업데이트 성능에 대한 해결책도 도모하고 있다.  데이터를 segment 단위로 저장하고 이 segment를 읽기에 최적화된 RS와 쓰기에 최적화된 WS로 구분해 놓았다.  모든 업데이트를 WS에서 수행하고 tuple mover로 주기적으로 RS에 반영하여 WS 크기를 작게 유지한다.  이러한 방식으로 실시간 업데이트가 가능한 DBMS를 구현하고 있다.

마지막으로 데이터를 segment 단위로 저장하기 때문에 horizontal partitioning이 가능해진다.  이로써 각각의 데이터 segment를 클러스터 하드웨어의 노드들에 분산 배치하여 병렬 처리를 할 수 있는 가능성이 생긴다.  이제까지 DBMS 클러스터링 기술이 고가용성 문제 해결에 적합하지, 성능 문제 해결에 적합한 것이 아니었다는 점을 감안하면 여기에 한가지 가능성이 있는 셈이다.

c-store가 어떻게 발전해 나갈지 앞으로가 궁금해진다.

관련 링크

• http://db.lcs.mit.edu/projects/cstore : c-store 홈페이지
• http://notaboutdb.blogspot.com : c-store에 대해 자세히 설명하고 있는 blog