Mongodb를 고민하는 국내 개발자들이 짚고 넘어가야할것들

Mongodb는 nosql의 일종으로 다른 nosql보다는 배우기도 쉽고 접근성이 좋아서 그리고 json형태이기 때문에 nodejs와의 궁합이 좋아서라는 이유로 사용을 고려해볼 수 있다.

하지만 Mongodb를 사용하기전에 몇가지 집고넘어갈 것이 있다. 반드시 체크해보기 바란다.

1. 게시판의 텍스트 검색용인가?

만약 당신이 단순하게 텍스트에 기반한 검색기능을 이용하고자 한다면 다른 DB를 고려하기를 바란다. Mongodb는 현재 이 글을 쓰는 시점에는 한글검색을 완벽하게는 지원하지 않는다.(안된다는게 아니다. 다만 형태소분석과 함께 되지않기때문에 성능상 최적화가 어려워진다.) 물론 elasticsearch 와 엮어서 쓰면 제대로 검색이 되기야 하겠지만 단순하게 게시판의 제목과 내용을 검색하는 용도라면 뭐하러 익숙한 sql을 버리고 새로운 문법을 배우려하는가. 그럴바엔 차라리 mariadb를 사용하기를 권한다. mariadb도 fulltext index를 Mroonga를 통해 지원(링크)한다. 또한 sphinx 와 함께 사용하면 작은 검색엔진으로서는 훨씬 훌륭하다.

https://docs.mongodb.org/manual/reference/text-search-languages/#text-search-languages

2. 특정 키값으로만 데이터를 찾는다.

왜 sql 놔두고 mongodb를 쓰려는지 이유는 알 수 없지만 데이터의 sharding 때문이라면 mongodb를 써도 괜찮다고 생각한다. 하지만 그게 아니라면 기존의 관계형 db가 훨씬 나을것이다. 왜냐면 join이 필요한 경우가 생길지 어떻게 아는가? mongodb에서는 join같은 기능이 없다. 정말로 오로지 키값으로 데이터를 찾는 용도로 할때만 추천한다. 로그의 상세데이터를 본다던가...

3. RDB를 사용하기에는 너무 데이터양이 큽니다. 수십기가~테라바이트를 사용하고 수억건이 넘는 데이터를 처리해야합니다.

수억건까지는 RDB도 인덱싱과 파티셔닝의 퍼포먼스 관리를 잘 해준다면 문제없이 동작한다. 그걸 신경쓰기 싫어서라고 한다면 mongodb도 좋다고 생각한다. 하지만 RDB로 처리해야 편한걸 mongodb에서도 편할것이라고 생각하지 말기를... mongodb도 인덱싱을 걸어야하는건 RDB와 다르지 않고 join등을 희생한 대신 쓰기에 좀 더 최적화 되있을 뿐이다. 읽기보다 쓰기가 많은 작업에 더 어울린다는 말이다.

4. SNS서비스와 같이 최신글만 위주로 보게되는 서비스입니다.

mongodb는 SNS서비스와는 꽤 궁합이 좋다고 생각한다. 내용을 검색하는 문제라면 한글에 대한 fulltext index가 지원하지 않는다는 점이 조금 걸리기는 하지만 사용자의 키값과 최신날짜순으로의 조합으로 나름 훌륭한 서비스가 가능할 것이다. RDB에 비하여 저장하는 연산이 가볍기 때문에 마구잡이로 쓰고 지나간 일들을 볼일이 거의 없는 이런 경우에는 RDB보다 적합하다.

5. 검색엔진처럼 데이터양도 엄청나고 전체적인 서치가 필요합니다.

RDB로는 도저히 답이 안나온다. 하지만 mongodb도 이러한 검색에 최적화되어 만들어졌다고는 보기 어렵다. 이런경우에는 어차피 내용을 풀스캔해야한다고 봐야하는데 mongodb는 이런부분에 약하다. 어쨋든 인덱스를 가지고 동작하는 방식이기 때문이다. 단독으로 하기보다는 elasticsearch와 함께 고려해보아야 한다.
구글의 빅테이블에 대한 논문을 기반으로 만들어진 HDFS 와 HBASE 와 같은 하둡계열의 경우에는 기본적으로 검색엔진을 토대로 만들어졌기 때문에 사정이 더 나을것 같지만 mongodb와 엄청난 차이가 있다고 보기는 어려울 것 같다. 어차피 내부적으로 데이터를 저장하는 방식은 다른 nosql의 key/value 시스템과 다를바 없기 때문이다.

{a: 1, b : {bc:1, bd:2}} 는 결국
a = 1
b.bc = 1
b.bd = 2

라는 key/value 시스템과 같은 형태로 저장된다. 대신 hadoop과는 다르게 하나의 데몬위에서 인덱스와 같은 기능들을 제공하기 때문에 어쩌면 조금 더 편리하게 쓸 수 있을지 모른다. 속도적인 측면을 제외하고라도 장기적으로 mongodb가 한글검색만 완벽하게 지원한다면 다른 nosql을 제치고 편의성에서는 1등의 자리를 넘볼 수 있을지도?

결론

이 결론은 어디까지나 mongodb를 겉핥기로 쓰려고 했으나 점점 하다보니 하려는 프로젝트와 맞지 않는것을 깨달아 전환하면서 쓴 글이고 필자의 주관적인 의견이므로 다른 이견이 있을 수 있습니다. 이견은 댓글로 달아서 이야기했으면 좋겠습니다. 제가 잘못 판단하고 있는 부분이 얼마든지 있을 수 있다고 생각합니다.

로깅 서비스나 요즘시대의 트위터같은 SNS와 같은 서비스라면 mongodb는 꽤 괜찮은 선택이다. json형태의 데이터관리와 auto-sharding 기능이 사용을 편리하게 해준다. 하지만 쓰기와 읽기비율이 읽기에 좀  더 치중된 서비스라면 분명하게 여러가지 데이터를 조합할 일이 많을것이다. mongodb는 join과 같은 복잡한 데이터 연산을 하기가 어렵기 떄문에 sql문법보다 오히려 읽기 어려워진다. 또한 text search가 아직 미흡한 점이 국내에서 사용하기엔 발목을 잡을것이다. map/reduce 기능에 큰 기대를 하지 말자. RDB들에도 내부적인 function 기능들을 이용해서 sum이 가능하다. 다만 데이터 서버가 나누어진 clustered환경에서 이러한 sum 작업이 쉬워진다는것 뿐이다.