기고 | 빅 데이터 시대, 어떤 DBMS를 골라야 할까

키-값 쌍 데이터베이스
키-값 쌍 데이터베이스는 카우치베이스(Couchbase)의 최신 1.8 에디션과 아파치 카산드라(Cassandra)를 포함한다. 이들은 확장성이 아주 뛰어나지만, 복잡한 데이터세트에서 개발자들에게 어떠한 도움도 주지 않는다. 만약 당신이 기본적으로 디스크백(disk-backed)되고, 분산된 해시 테이블(hash table)을 필요로 하며, 모든 것을 식별해 검색할 수 있다면, 이들은 확장성이 훌륭하면서도 번개처럼 빠를 것이다. 하지만 만약 특정 값에 도달하기 위해 키를 연달아서 찾아야 하는 상황이라면, 그와 달리 좀 더 복잡한 경우라고 볼 수 있다.

데이터 규모와 복잡성
 
 

키-값 쌍 데이터베이스의 수없이 다양한 순열들이 존재하는데, 이들은 기본적으로 CAP 정리의 다양한 균형점들, 그리고 스토리지와 메모리 사용의 다양한 설정들이다. 궁극적으로 해시 테이블의 기본적인 형태를 갖게 될 것이다.

이는 합성하지만 않는다면 평면 파트 목록(flat parts lists)에 좋다. 또한 주식 시세, 지금 당장이나 키가 의미를 가지면서 값을 찾아주는 주요 수단이 되는 타 유형의 목록에도 좋다. 일반적으로 이들은 인덱스와 복잡한 값에 반하는 쿼리, 또는 키들의 목록 작성할 수도 있지만, 만약 당신이 많은 수를 필요로 한다면, 차라리 다른 방법을 찾는 편이 좋을 것이다.

칼럼 패밀리/빅 테이블 데이터베이스
카산드라를 포함한 대부분의 키-값 스토어(store)들은 칼럼의 그룹만들기를 제공하는데, ‘칼럼 패밀리(column family)’나 ‘빅 테이블(big table)’이라고 간주할 수 있다. H베이스(HBase)같은 몇몇 데이터베이스들은 시작부터 칼럼 패밀리 스토어로 만들어졌는데, 이는 키-값 쌍 데이터베이스보다 더 진화한 것이다. 근본적으로 키와 값이 복합재가 된다. 이를 해시 맵(hash map)이 다차원 배열과 교차된 것으로 생각해보라. 각각의 칼럼은 데이터 줄들을 포함한다.

카산드라의 인증 버전을 판매하는 데이터스택스(DataStax)의 제품 부회장 로빈 슈마허(Robin Schumacher)는 “카산드라를 대중적으로 사용하는 분야는 기기, 센서, 웹사이트(예를 들면 웹 로그), 금융 상품 판매 등의 데이터에서 가져온 시계열 데이터다. 이딀 데이터는 빠른 속도로 전송돼 오는데다, 다수의 장소에서 단번에 모여 빠르게 합쳐지고, 시간대마다 빠른 쓰기 용량과 고성능 읽기 기능을 필요로 한다.”

이들 데이터에 맵리듀스(MapReduce)도 사용할 수 있다. 또한 이들은 훌륭한 반정형 데이터 분석 스토어가 될 수 있다. 이들 데이터는 확장성은 좋지만, 보통 거래가 많이 일어나지는 않는다. 만약 데이터간의 관계가 데이터 그 자체만큼 중요하다면, 칼럼 패밀리/빅 테이블 데이터베이스를 사용하지 않는 게 좋다.

문서 데이터베이스
많은 개발자들은 객체 지향 프로그래밍과 깔끔하게 맞아떨어지는 점 때문에 문서 데이터베이스(document database)를 높이 평가한다. 몽고DB(MongoDB)의 10젠(10gen), 카우치베이스, 아파치의 카우치DB(CouchDB)와 같은 잘나가는 업체들과 함께 문서 데이터베이스는 가장 많은 업체들이 열을 올리는 분야다.

카우치베이스의 프랭크 위겔은 회사들이 1.8 버전안의 키-값 쌍 데이터베이스에서 2.0의 문서 데이터베이스로 이동하는 중이라고 전했다. 그에 따르면, 문서 데이터베이스는 자연스런 발전이다. 데이터 접속을 위한 클러스터링(clustering)부터 문서 데이터베이스와 키-값 스토어들은, 문서 데이터베이스 안에서 데이터베이스가 데이터스토어 안의 문서들을 이해할 수 있다는 점을 제외하곤 완벽하게 동일하다고 한다. 다시 말해, 값들은 JSON이고, JSON 문서 내부의 요소들은 더 나은 쿼리와 검색을 위해 지수화 할 수 있다.

이들은 개발자가 JSON 문서를 작성할 때 특히 유용하다. 10젠의 회장 막스 시레슨이 필자에게 말한 것처럼, “데이터가 관계형 데이터베이스 안에서 모델링하기 너무 복잡할 때, 문서 데이터베이스를 고려해봐야 한다. 예를 들어, 복잡한 파생 금융 상품은 전통적인 포맷으로 저장하기 힘들다. 전자 의료 기록 역시 그의 좋은 예다. 만약 XML 스토어를 사용하는 방안을 고려하고 있었다면, 몽고DB와 JSON/BSON의 사용을 꼭 고려해 봐야 한다”라고 밝혔다.

이는 아마도 당신의 데이터는 사용자, 시스템, 소셜 네트워크 등에서 수집되는 운용 저장소일 것이다. 몽고DB가 종종 일종의 맵리듀스를 활성화시키는 것과 같은 데이터베이스를 통해 당신이 보고하는 지점은 아닐 것이다. 몽고DB에서 최소한, 어느 것에나 질의할 수 있는 반면, 인덱스 없이 납득할 만한 성능을 얻기는 일반적으로 힘들 것으로 본다.