금요일, 9월 23, 2011

[독서광] MongoDB 완벽 가이드

오늘은 클라우드 컴퓨팅라는 용어가 인구에 회자되면서 NoSQL에 대한 이야기에 사람들이 관심이 많은 듯이 보인다. 오늘은 NoSQL의 진수(?)라고 책 표지에 적힌 MongoDB 완벽 가이드라는 책을 읽은 소감을 정리해보겠다. 요즘 기억력이 부쩍 감퇴하고 있기에 읽은 즉시 정리해야 휘발되지 않으므로 서둘러본다.

NoSQL(not only SQL)이라는 말을 많이 하는데, 위키피디아 정의에 따르면 다음과 같은 상당히 포괄적인 의미가 함축되어 있다.

몇 가지 측면에서 전통적인 데이터베이스 관리 시스템인 RDBMS과 다른 데이터베이스 관리 시스템의 넓은 클래스 자료는 고정된 테이블 스크마를 요구하지 않으며, 일반적으로 join 연산을 피하고, 수평 확장이 가능하다.

RDBMS와 차별화 포인트를 가져가면 나쁜 점과 좋은 점이 생기게 되는데, 지속적인 손해는 일시적인 손실로 처리하고 일시적인 이익은 반복적인 매출로 잡는 엔론의 분식 회계처럼 NoSQL의 장점은 극대화하고 단점은 이야기하지 않는 방법으로 거의 모든 문제점을 해결하는 만병 통치약에 은총알로 승격시키려는 움직임도 눈에 보인다. 하지만 AWS SimpleDB를 살펴보고 이 책도 읽고나서 든 느낌이지만, NoSQL은 절대로 만병 통치약이 아니며, 용도에 맞춰 제대로 사용해야 장점을 얻을 수 있기에 일반적인 상황에서는 MySQL/PostgreSQL과 같은 RDBMS가 월등이 유리하지 않을까 싶다(뭐 이건 어디까지나 B급 프로그래머 머리 속 생각일 뿐이고 절대로 남에게 이래라 저래라 _강요_하지 않는다. NoSQL 계열 데이터베이스를 쓰실 분은 얼마든지 능력껏 상황껏 마음껏 쓰시라. 뭐, B급 프로그래머도 AWS SimpleDB를 용도에 맞춰 재미있게 쓸테니... 다 같이 잘 살아보세~~~). 여러 전자 상거래와 SNS 회사에서 NoSQL을 사용한다고 하지만, 간도 크게 모든 서비스에 다 적용하지는 못하며 아직까지는 핵심 기능이 아닌 기능에 시범적으로 적용하는 경우가 많다는 생각이다. 물론 처음부터 NoSQL로 다 구축했다고 말하는 대규모 서비스도 존재하겠지만, 그 서비스가 바로 당신이 만들려고 하는 서비스가 아닌 이상 적용 범위와 효과는 '그 때 그 때 달라요'다.

NoSQL에 대한 이야기만 잔뜩 늘어놓았는데 본론으로 들어가보면, MongoDB 완벽 가이드는 '완벽'은 아니지만 처음 MongoDB를 사용하는 사람들에게 힌트를 줄만한 책이다. 그런데 처음 MongoDB를 사용하는 사람이지 처음 컴퓨터 프로그래밍에 입문하는 사람을 위한 친절한 안내서는 절대로 아니다. 이 책을 읽으려면 자바스크립트 언어에 익숙해야 하며(그냥 copy&paste 수준으로는 안 된다), 데이터베이스 기본 이론에 대해 확실하게 알고 있어야 한다. 그렇지 않으면 얇은 페이지임에도 불구하고 읽는 과정에서 조금 애를 먹게 된다. 내용은 MongoDB 셸을 사용한 문서 생성/갱신/삭제/질의/색인 방법, 집계(맵리듀스도 일부 나온다), 고급 기능(제목과는 달리 그리 깊은 내용은 없다), 시스템 관리와 모니터링, 복제/레플리카와 샤딩 등이며, 책 끝 부분에는 자바, PHP, 루비, 파이썬을 사용한 예제 애플리케이션 작성 기법도 나오긴 하는데 20페이지 분량이므로 크게 건질 내용은 없다. 전반적으로 심도 깊은 내부 구조나 철학을 다루기보다는 소개 중심으로 가고 있으므로 MongoDB를 이용한 응용 프로그램 개발자를 표적으로 한다고 보면 되겠다.

MongoDB는 자바스크립트 엔진을 탑재한 셸과, SQL과는 전혀 닮지 않은 질의 방식으로 인해 전통적인 RDBMS 사용자라면 조금 과격하다는 느낌이 들지도 모르겠다. AWS SimpleDB만 하더라도 연산자 형태는 단순 key - value 저장, 질의 형태는 SQL과 유사한 질의어를 사용하지만 MongoDB는 기존의 관습을 무시하고 독자적인 세상을 구축해 놓았으므로(궁금하신 독자분들께서는 SQL to Mongo Mapping Chart를 보시라. 말이 Mapping Chart지... T_T) 학습 과정에 애로 사항이 꽃필 가능성이 높다. 각종 프로그래밍 언어 라이브러리를 사용하더라도 독특한 활용법에 맞춰야 하는 관계상 그리 쉬워보이지는 않는다. RDBMS만 보다가 객체 지향형 데이터베이스를 보는 느낌이라고 설명하면 조금 이해가 갈지도 모르겠다. 지금까지 겁을 좀 줬지만, NoSQL 자체가 기존 RDBMS의 복잡도를 줄이려는 목표로 시작되었기 때문에 책을 읽다보면 전반적인 기능과 한계점이 눈에 보일 것이다.

다른 부분은 다 차치하고서라도 복제/레플리카, 샤딩에 눈이 번쩍 뜨이는 분들도 많으시리라. 클라우드에서 이 단어들은 솔직히 큰 관심을 불러일으키는 주요 논쟁 거리기 때문이다. 그런데, 여전히 문제점은 남아 있다. 복제/레플리카 과정에서 일어나는 성능 저하, 타임 랙(lag)은 피할 수 없어 보이며, 샤딩 과정에서 사용자가 머리를 써서 샤딩 기준을 마련해야 한다는 사실은 변치 않고 있다. 자동 샤딩에 대한 이야기도 아아주우 조금 나와있는데, _자동_이라는 말을 100% 믿을 수 있을지는 각자 판단에 맡긴다.

EOB

댓글 2개:

  1. 맞습니다. Bigtable의 Google도 필요한곳엔 MySQL같은 RDBMS를 쓰고있고, Dynamo의 Amazon도 적절하다 싶은곳 (data가 eventually consistent해도 괜찮은 곳이라던지)에만 쓰고있지요..

    NoSQL 솔루션들에서 제공하는 data model로는 모델링 하기가 너무 힘들지않은가 싶습니다. 물론 Relational DB에서 모델링 하는게 쉽다는말은 아니지만 그 동네에는 Normal form 이라는 데이타 모델의 건강함을 검증하는 방법이라도 있지요..

    결정적으로 국내 서비스 정도 규모의 load 수준은 RDBMS 솔루션들로도 충분히 처리할 수 있는 경우가 대부분이라 "왜 굳이 이걸 써야하죠?" 라는 운영팀의 당연한 의문이 더 설득력을 가지는 경우가 많다는거

    답글삭제
  2. 국내에서도 미투데이 정도의 서비스만 되어도 운영팀의 곤란거리가 됩니다. 쓰기 비중이 높고 sharding과 partitioning이 곤란하죠.

    구글도 빅 테이블 이후로 더 다양한 서비스가 나오기 시작했듯 우리도 NOSQL에 대해 미리 준비하고 있다면 더 다양한 서비스를 꿈꾸고 만들 수 있을 것 같습니다.

    답글삭제