몽고디비와 카우치디비
아직도 두가지 데이터베이스를 중에서 어떤 녀석을 써야할지 결정하지 못했다.
테스트해보면 카우치디비(CouchDB)쪽이 map/reduce라는 것을 아주 환상적으로 구현해놨다. 하지만 데이터를 가져올 때 사용하는 뷰(View)가 별로 빠르지 않다. 요즘 다루는 데이터는 25만건 정도되는 게시물들인데, 이 정도만 넣어봐도 뷰를 만들때 힘들어한다.
몽고디비(MongoDB)는 그에 비하면 도큐먼트 디비의 MySQL 버전을 보는 듯한 느낌이다. 사용되는 언어도 어렵지않다. 빠르고, 간단하다.
선택하기 힘들었던 중요한 이유중에는 카우치디비가 아파치프로젝트인 반면, 몽고디비는 10gen이라는 회사에서 진행하는 프로젝트라는 점이 있었다. 오픈소스이긴 하지만, 언제라도 드롭되면 그만아닐까.
그전에 테스트할 때도 카우치디비가 학교다니는 애들이 만드는 물건인 듯한 느낌이 들었었는데, 오늘 어떤 블로그를 보다가 두 프로젝트의 차이가 바로 이거 였구나, 확신하게 되었다.
카우치디비 개발자가 올린 블로그의 내용은 “몽고디비에는 치명적인 문제가 있다” 는 것이었다. 안그래도 싸움이 붙기 쉬운 주제였는데, 여기에 몽고디비쪽 직원이 댓글을 달면서 더 재미있어졌다.
카우치디비 개발자는 “데이터베이스의 안정성을 위해서는 MVCC 라는 기법을 쓰는 수밖에는 없다.” 는 주장을 되풀이 하고 있었다. 즉 “몽고디비는 MVCC를 안쓰기 때문에 안정성을 획득하기 힘들다” 라는 것이다.
그중에서도 내 눈에 들어온 것은 이 댓글이었다. 댓글에는 이런 문장이 들어있다.
> I responded earlier to the complexity of actually keeping something available that > depends on [multiple servers]. so i won’t cover it again. Yes, it is a difficult, but not unsolvable, problem. … For instance, remember last year when CouchDB was saying MongoDB sucked because of its lack of concurrency? That it was too complicated to do concurrency in C++ and that Erlang was the way? Well, now Mongo has concurrency, so on to the next “must have” thing.
번역해보자면.. “맞습니다. 그건 어려운 문제입니다. 하지만 풀 수 없는 문제는 아니랍니다. … 작년에 카우치디비쪽에서 몽고디비는 쓰레드처리가 개떡같다고 했던 것을 기억하나요? 그때 C++에서는 쓰레드처리를 하기 힘들기 때문에 얼랭(erlang)을 써야만 한다고 했었지요. 자, 이제 몽고디비가 쓰레드처리를 잘하게 되니까, 또 다른 ‘반드시 이걸 써야만 하지’ 라는 얘기가 나오네요?”
저 블로그의 댓글 싸움은, 카우치디비에서 일하는 또라이가 지 생각만이 옳다고 우기고 있는 거로 밖에 안보인다.
일단, 저 싸움에서는 몽고디비쪽에 손을 들어주고 싶지만. 아직도 둘중에 어떤 녀석을 설치해줄지는 결정하지 못했다. 현재까지 정리는 …
카우치디비:
도대체 맵/리듀스(map/reduce)가 무언지 한번쯤 경험해보고 싶다면
그렇게 안정적이라는 MVCC 가 얼마나 느린지 궁금하다면
몽고디비:
현장에 곧바로 적용해보고 싶다면 (물론 데이터가 날아갈 수도 있다… 응? )
빠른 도큐먼트 디비를 찾는데, 다른 녀석들이 복잡해보인다면
어쨌든, 아직 몽고디비에는 시비걸만한 요소가 있다는 거다. (기능 추가하는 걸보면, 엄청 열심히 일하는 사람들이라서, 조만간 잘 팔릴께 확실하다.)
그리고, 카우치디비가 1.0 이 되면서 300배나 빨라졌다니까, 한번 더 테스트해봐야겠다. (혹시 빨라졌으면 다시 올리겠슴.)