NoSQL은 상당히 오랫동안 뜨거운 화제였다(음, 이제는 단순한 화젯거리 수준이 아니다).
하지만, 진짜로 NoSQL을 사용해야 할 때는 언제일까?

MongoDB의 적절한 사용법

NoSQL 제품(그리고 MongoDB)은 특정한 문제를 해결하기 위해 사용되어야 한다. 만약 다음과 같은 문제를 겪고 있다면 MongoDB를 고려해보는 것이 좋다.

쓰기 부하가 클 것이 예상될 때

MongoDB는 기본적으로 안전한 트랜잭션을 통해 빠른 속도로 데이터를 삽입한다. 개별 데이터의 비즈니스 가치가 낮은 어마어마한 양의 데이터를 읽어들여야 한다면 MongoDB가 적합하다. 단, 100만건이 넘는 트랜잭션 레코드는 삽입하지 않아야 하며, 최소한 다른 안전 장치를 갖춘 후에 삽입하는 것이 좋다.

신뢰할 수 없는 환경(클라우드와 실생활)에서 고가용성(高可用性)이 필요할 때

MongoDB에서는 replicaSet(마스터-슬레이브로 동작하는 서버의 집합)을 쉽고 빠르게 설정할 수 있다. 게다가, 노드(혹은 데이터 센터)에 문제가 생겼을 때 자동으로 데이터를 안전하게 즉시 복구할 수 있다.

빅 데이터를 다루거나 샤딩이 필요할 때

데이터베이스 스케일링은 어렵다(MySQL 테이블은 테이블당 5~10GB 사이가 되면 성능이 저하된다). MongoDB에는 데이터베이스의 파티셔닝 또는 샤딩이 필요할 때 사용할 수 있는 솔루션이 내장되어 있다.

위치 기반 데이터일 때

MongoDB는 특수한 기능을 내장하고 있어서 특정 위치와 관련한 데이터를 빠르고 정확하게 찾을 수 있다.

데이터가 커지거나 (1GB 이상) 스키마가 고정되어 있지 않을 때

RDBMS에 새로운 칼럼을 추가하면 일부 데이터베이스에서는 전체 데이터베이스에 락을 걸고, 그 외의 데이터베이스에서는 심각한 부하와 성능 저하를 일으킨다. 일반적으로 이런 현상은 테이블의 크기가 1GB보다 클 때 발생한다(또한, 아래에서 설명하는 BillRun과 갈이 크기가 수 TB를 넘는 테이블이 여러 개 존재하는 시스템에는 심각한 문제가 되기도 한다). MongoDB는 스키마가 없는 시스템이므로 새 필드를 추가해도 기존에 저장된 로우(혹은 도큐먼트)는 전혀 영향을 받지 않으며 변경이 즉시 이루어진다. 다른 장점으로는 프로그램이 변경되서 스키마를 수정할 때 DBA가 없어도 된다는 것이다.

DBA가 없을 때

DBA도 없고 데이터를 정규화하거나 조인(join)하기도 싫다면 MongoDB를 고려하는 것이 좋다. MongoDB는 객체를 JSON으로 직렬화하여 그대로 MongoDB에 저장하므로 객체를 저장하기에 좋다. 주의: 빅 데이터를 다룰 것이라면 위험 요소를 피하기 위해 다음과 같은 방법을 따라야 한다.

BillRun - Billing on top of MongoDB | MUG IL, Feb 2014 from Ofer Cohen

실제 사례 연구: 결제 시스템

지난 일리노이 모델링 사용자 그룹(Illinois Modeling Users Group, ILMUG)에서 오퍼 코헨은 MongoDB를 데이터 저장소로 사용한 차세대 오픈소스 결제 솔루션인 BillRun에 대해 발표했다. BillRun 시스템은 매월 5억건 이상의 통화 기록을 처리하는 이스라엘에서 가장 빠르게 성장하는 통신망 기업에서 사용되었다. 이 발표에서 오퍼는 이 시스템이 MongoDB를 사용해서 얻은 장점에 대해 설명했다.

  1. 스키마가 없는 설계 덕분에 새로운 통화 기록 유형을 시스템에 빠르게 도입할 수 있었다. 덕분에 BillRun은 데이터 저장소의 보편성을 유지할 수 있었다.
  2. 새 필드 추가를 제한하거나 데이터 증가를 제한하지 않고도 BillRun은 이미 실무에서 테이블당 수 TB에 달하는 데이터를 다루었다.
  3. 빠른 replicaSet으로 인해 다중 데이터 센터의 DRP(재난 복구 프로토콜)과 HA(고가용성) 솔루션 구성할 때 필요한 규약을 쉽게 충족시킬 수 있다.
  4. 샤딩을 통해 예산을 다 쓰지 않고도 선형적, 수적인 증가가 가능했다.
  5. 초당 2천건 이상의 통화 기록을 삽입할 때처럼 MongoDB 아키텍쳐는 삽입 부하가 높은 시스템에 적합하다. findAndModify(속도가 느림)와 2단계 실행(프로그램 적인 방법)을 통해 트랜잭션을 안전하게 만들 수 있다.
  6. 개발자 지향적인 쿼리덕분에 개발자들은 품격있는 쿼리를 작성할 수 있다.
  7. 위치 기반 기능을 활용해 사용자의 사용 패턴을 분석하고 어디에 통신망 인프라를 투자할 것인지 정했다.

요점

MongoDB는 훌륭한 도구지만 이득을 얻으려면 적합한 시나리오에서 사용해야 한다. BillRun은 MongoDB를 사용하기에 좋은 사례였다.



이 글은 Moshe Kaplan이 작성한 When Should I Use MongoDB rather than MySQL (or other RDBMS): The Billing Example을 번역한 글입니다.

Posted by 행복한고니 트랙백 0 : 댓글 0

티스토리 툴바