CS 전공/리뷰2011. 3. 31. 14:08
DB 구조 쪽으로 떠오르는 신성 D. Abadi 교수가 Hadapt라는 회사를 차렸군요. Hadapt는 HadoopDB의 상용화 버전을 만드는 벤처입니다. HadoopDB는 MapReduce의 오픈소스 버전인 Hadoop을 연결 계층으로 이용하여 단일 노드의 DBMS들을 엮는 비공유 구조의 데이터 처리 시스템입니다.
달리 얘기하면, Hadoop에서 파일 시스템 대신에 DBMS를 이용한다고도 할 수 있습니다.

HadoopDB는 MapReduce의 장점인 확장성(scalability)을 그대로 유지하면서, Hadoop의 떨어지는 성능을 노드 단위의 DBMS의 우수한 성능으로 보완하자는 의도로 만들어진 시스템입니다. MapReduce의 성능이 좋지 못한 이유에 대해서는 이전 블로그 글를 참고하시고요. 이 시스템은 PostgreSQL을 하위 DBMS로 활용을 했는데 Hadapt에서는 VectorWise라는 DBMS를 이용했습니다.  아마 Connector들을 더 추가해서 다른 DBMS들도 지원을 할 것은 확실한 것 같고요.

그런데, 재미있는 것은 이 VectorWise에 관여되어 있는 사람이 또 Peter Boncz라는 겁니다. 이 사람 또한 컬럼-기반 DBMS인 MonetDB를 가지고 연구를 많이 한 사람이고요. 거기에 메모리 계층을 고려한 DB 연산의 최적화도 같이 접목시키는 연구를 많이 했죠. 어쨌든 VectorWise는 Ingres에 판권을 맡기고, 만드는 컬럼-기반 DBMS입니다. 컬럼 DBMS는 I/O를 줄이기 위해 기존 행-단위 기록을 했던 방식을 반대로 컬럼(열)-단위로 바꿨습니다. 즉 1행, 2행, 3행 식으로 디스크에 기록을 하는 것이 아니라, 첫번째 열값, 두번째 열값, 세번째 열값 순으로 기록을 합니다. 이렇게 하면 질의 처리 시, 특히 selection 연산의 경우 모든 행들을 읽어서 그중 selection할 대상이 되는 컬럼만 추리는 방식에서 대상이 되는 컬럼만 디스크에서 읽게 함으로써 많은 I/O를 줄일 수 있습니다. 특히 OLAP 업무에 특히 적합한 저장 방식입니다. 이 컬럼-단위 저장에도 몇가지 방식이 있는데 그중 PAX라는 페이지 저장 방식[1]이 주로 활용됩니다. 여기에 더해서 데이터 압축도 합니다. 근래의 컴퓨팅 시스템은 컴퓨팅 사이클보다 디스크 지연시간이 훨씬 bottleneck이기 때문에 압축과 압축해제에 소요되는 컴퓨팅 비용보다 디스크 I/O 때문에 잡아먹는 비용이 더 클 수 있다는 근거로 이런 선택을 한 것이고요.
 재미있는 것은 D. Abadi도 C-Store라는 이름의 컬럼-기반 DBMS를 박사학위 주제로 했던 사람이었다는 거죠(C-Store는 Vertica라는 이름으로 상용화가 되었고, 이 회사는 최근에 HP에 인수됩니다.) 아마 같은 주제를 해왔던 사람이라 다른 컬럼-기반 DBMS를 제치고 썼는지도 모르지요.

아무튼, MapReduce에서 보면 데이터 처리에 있어 I/O 비용이 굉장히 높아서 이를 줄임으로써 throughput을 향상시키려고 할 것이고요. 둘 다 주목적이 데이터 분석이나 처리 업무에 있고, OLTP에 있지 않으니, 둘의 결합은 매우 훌륭하다고 생각됩니다. 

참고로 좀더 알아보니 컬럼-기반 DBMS 를 만드는 회사들이 몇개 더 있군요.
InfoBright라는 회사는 MySQL 기반으로 컬럼 기반 DBMS를 만든다고 하고, 학계에서 만든 시스템으로는C-Store나 MonetDB를 이용해 볼 수 있습니다. 더 많은 리스트는 http://en.wikipedia.org/wiki/Column-oriented_DBMS에서 확인해 볼 수 있습니다.

그나저나 작금의 DBMS 시장은 정말 알게모르게 요동치는 듯 하네요. OLTP에서의 강자들 Oracle과 IBM, MS들은 그대로 있지만, 시장이 점차 커지고 있는 데이터 분석 분야에 신흥 업체들이 계속 출현하고, 또 여러 공룡 업체에 인수되는 현상들이 계속 보입니다. 
Netteza는 IBM에게 Vertica 는 HP에게, Greenplum은 EMC에 Aster는 Teradata 에게 인수되는 등 아주 요동칩니다. 창업과 기업인수가 활발한 미국의 IT 업계가 부럽네요. 

 [1] 
“Weaving Relations for Cache Performance” by Natassa Ailamaki, David DeWitt, Mark Hill, and Marios Skounakis, VLDB Journal, 2001

written by bart7449 
Posted by Bart
CS 전공/생각?2011. 3. 25. 15:52
예전에 애리조나대 문 교수님께서, 컴퓨터공학은 응용학문이다 보니 실제로 중요한 법칙 같은 것은 몇 개가 안되는 것 같다.
라는 말씀을 하셨는데, 문득 옳은 지적이신 것 같다는 생각이 요새 많이 든다.
대부분의 SW 개발 업무라는 것이 어떤 문제가 주어졌을 때 그 문제를 푸는 방법(알고리즘)과 그의 구현(프로그램)이라고 한다면, 대부분의 개발 업무라는게 이런 식인 것 같다.

1) 문제가 주어진다.
2) 한 문제를 여러 작은 문제들로 나눈다.
3) 각 문제에 대한 기존 해결책이 있는지 조사한다.
4) 있으면, 가장 낫다는 놈을 가져다 쓰고 없으면 만든다.
5) 합쳐보고 테스트하고, 추가로 최적화시켜 본다.

그리고 이렇게 해서 잘 쓰다가 요구하는 성능치가 더 높아지면, HW를 추가로 공급하거나, 또는 알고리즘을 개선하는 방법을 써야 한다. 많은 경우 기존 알고리즘을 개선하는 방법은 크게 다음과 같은 것같다.

1) 입력 데이터 크기 줄이기
 - 같은 알고리즘이라도 처리에 필요하지 않는 데이터는 읽지 않음으로써 성능 향상을 꾀할 수 있다.
 - 사실 불필요한 데이터 읽기를 피하기 위한 가장 잘 알려진 데이터 구조는 인덱스이다.
 - 최근의 컬럼-기반 DBMS도 요구되는 데이터만 읽기 위해 데이터를 행-기반에서 열-기반으로 옮긴걸로 간소화할 수 있겠다.

2) 알고리즘 자체의 성능 개선
  - 대개는 최악 복잡도를 개선하는 것을 목적으로 하는데, 실제로는  최악 복잡도는 낮아도 평균 복잡도가 우수한 알고리즘들도 많이 선택되는 듯.

3) 시스템 구조에 좀더 적합한 알고리즘
  - 같은 복잡도라도 시스템 구조를 좀더 잘 활용하는 알고리즘들이 효과적이다. 대표적인 것이 메모리 계층에서 데이터 이동이 많지 않도록 cache-aware한 알고리즘들이다. 복잡도는 더 높은 cuckoo hash가 실제로는 더 빠른 것을 보면 메모리 계층에 대한 고려는 매우 중요.

4) 분산/병렬 처리
  - 알고리즘을 병렬화해서 shared-nothing 또는 shared-memory 구조에서 분산 병렬처리하는 방식으로변경(scale-out)
 
5) 추가 자원 투입
  - 더나은 컴퓨팅 성능을 갖는 HW를 투입(scale-up)

대충 이게 다일 듯.
쓰고나면 별로 하는 일 없어보이는데 왜 이쪽 일이라는 것은 언제나 복잡해 보이는지 모르겠다.
Posted by Bart