MongoDB의 샤딩 구조는 분산데이터베이스의 전통적인 분할 3계층 구조 – 응용, 중개자, 데이터 계층 – 를 가진다. 중개자 역할을 담당하는 mongos와 중개자의 메타 정보를 저장하고 있는 config 서버, 그리고 데이터를 저장하는 mongod 로 구성된다. 본 절에서는 이러한 MongoDB의 샤딩 구조에 대한 기본적인 개념부터, 각 모듈들이 처리하는 내부 구조에 대해서 알아본다.
C++로 개발된 MongoDB는 boost의 shared_mutex를 이용하여 락 시스템을 개발하였다. shared_mutex는 기본적으로 one writer many reader의 구조를 가지기 때문에 MongoDB는 쓰기 락이 한 개만 존재한다. 이러한 점은 MongoDB의 쓰기 연산에서 부하가 발생할 경우, 전체적인 시스템 부하를 야기할 수 있다. 하지만, 10gen에서는 쓰기 연산 속도가 매우 빠르기 때문에, MongoDB의 락이 부하를 발생시키지 않는다고 말한다. 사실 NoSQL은 트랜잭션이 없기 때문에 쓰기 연산에 대한 부하가 RDB 처럼 심하지 않다. 즉 근본적인 쓰기만 수행하면 되기 때문에 매우 빠른 특징을 가진다. 또한 MongoDB는 1차적으로 메모리에 데이터를 쓰기 때문에 쓰기 연산 속도가 빠르다는 것이 보장된다.
MongoDB 관리도구인 ‘Monad Management for MongoDB v1.0′이 출시되었다. Monad Management 시스템은 설정 된 임계 값 정보 등을 통해 시스템에 발생할 장애 등을 미리 예측할 수 있으며, 미리 시스템의 증설 시기 등을 계획하거나, 불필요한 데이터의 삭제 시기를 정확하게 판단하여 불필요한 운영 비용을 절감할 수 있게 한다. 또한, 갑자기 발생되는 장애에 대해서도 대시보드와 아이콘, 이메일 등을 통한 즉시 알림 기능을 통해 운영자가 즉각적인 조치를 하게 함으로써 빠른 시스템 복구가 가능하게 하며, MongoDB의 유형별 상세 정보를 파악, 효율적인 시스템 관리를 가능하게 한다.
MongoDB가 많은 사람들에게 각광받고 있는 것은, 빠른 속도와 다른 NoSQL 보다 유연한 쿼리를 제공해 주기 때문이다. 빠른 속도는 기존 RDBMS가 가지고 있던 대용량으로 확장성 문제를 해결해주는 대안이 되었고, 유연한 쿼리는 RDBMS가 가지는 복잡한 쿼리를 대체할 수 있다는 기대감을 가져다 주었다. 이뿐만 아니라, MongoDB는 시스템 장애에 따른 안정성을 보장하기 위해 장애 대응 방안으로 복제와 저널링을 제공해 주고 있다.
MongoDB가 제공하고 있는 장애 대응에 대한 기능으로 복제와 저널링 시스템에 대한 내부 구조를 살펴보는 것과 함께, NoSQL의 근본적인 문제인 데이터 유실 가능성에 대해서 살펴본다.
 |  |  |  |  | |||||||||||||||||||||||||||||||||||||||||||