몽고DB(Mongo DB)

몽고DB는 웹 프로그램과 인터넷 기반 서비스를 위해 만들어진 데이터베이스 관리 시스템입니다. 몽고DB는 관계형 데이터베이스와 키-값 저장 시스템의 장점만을 모아서 설계되었습니다. 키-값 저장 시스템은 데이터 구조의 단순성을 통한 빠른 처리 속도와 정형화되지 않은 데이터 구조를 저장할 수 있는 장점이 있으며, 관계형 데이터베이스는 강력한 쿼리 기능을 바탕으로 다양한 분석능력과 인덱스를 기반으로 처리 속도가 빠른점이 장점입니다.

 

몽고DB는 이들 데이터베이스의 중간형이라 말할 수 있으며 빅데이터 처리를 위해서 서버들을 수평으로 확장이 가능하며, 비정형 데이터를 저장할 수 있으며 정교한 쿼리를 통한 양질의 분석 결과를 얻을 수 있습니다.

 

개발자들이 몽고DB에 관심을 갖는 이유는 빅데이터 처리를 위한 서버의 수평적 확장의 용이성 때문이 아니라 정형화 되지 않는 계층적 구조의 데이터를 표현할 수 있기 때문입니다. 이를 통해서 관계형 데이터베이스에서 사용하는 조인연산이 필요없이도 원하는 분석 결과를 도출할 수 있기 때문입니다.

 

예를 들면 트위터에서 입력되는 데이터를 관계형 데이터베이스로 모델링 한다고 생각을 해 보면, 정규화 과정을 통해서 몇 개의 테이블로 분할되어 설계되어질 것입니다. 이 구조에서 원하는 결과를 얻기 위해서는 복잡한 조인연산을 통해서 데이터를 선별해야하는 복잡한 과정을 거치게 됩니다. 이에 반해서 몽고DB의 경우는 트위터의 정보를 여러 개의 테이블로 분산하지 않고 하나의 문서로 표현하여 저장할 수 있습니다. 모든 정보가 하나의 문서로 저장되기 때문에 복잡한 조인 연산은 필요치 않습니다.

 

 

몽고DB와 관계형 데이터베이스의 구조적 차이점

일반적인 관계형 데이터베이스 모델과 몽고DB의 데이터베이스 모델의 저장 구조의 차이는 다음 그림과 같습니다.

 

 

[ 관계형 데이터베이스의 저장 구조 ]

 

[ 몽고DB의 저장 구조 ] 

 

 

관계형 데이터베이스와 몽고DB에서 사용되는 용어들의 차이점은 다음과 같습니다.

 

관계형 데이터베이스	몽고DB
Table, View	Collection
Row, Record	Document
Column	Field
Index	Index
Join	Embedded Document
Foreign key	Reference
Partition	Shard

[ RDBMS와 몽고DB의 용어 정리 ]

 

 

다큐먼트(Document) 의 의미

관계형 데이터베이스의 경우에는 열(column)이 모여서 행(row)을 이루고 여러개의 행들이 모여서 테이블(Table)을 구성합니다. 그리고 모든 행들은 동일한 열(row)들로 구성되어 있는 구조입니다. 이런 정형화된 구조로 인하여 SQL을 사용하여 원하는 결과를 빠르게 찾는 이점이 있는 반면에 컬럼을 추가하기 위해서는 모든 레코드에 동일한 저장공간을 만들어야 하는 비효율적인 측면도 존재합니다.

 

이에 반해 몽고DB의 경우에는 저장되는 데이터의 형식이 정해져 있지 않습니다. 레코드마다 삽입되는 정보의 구조가 틀려도 상관이 없습니다. 이에 반해 SQL을 사용하여 세밀하게 정보를 검색하는 기능은 관계형 데이터베이스에 비해서 다소  떨어집니다. 다음 그림은 관계형 데이터베이스와 몽고DB의 구조적 차이점을 도식화한 것입니다.

 

[ 관계형 데이터베이스와 몽고DB의 모델 비교 ]

다음 그림은 소셜 뉴스 사이트의 기사를 나타내는 도큐먼트 저장소의 한 형태를 나타내고 있습니다. 여기서 알수 있듯이 도큐먼트 저장소의 기본 구조는 키-값 의 집합입니다. 값들은 숫자, 문자열, 날짜와 같은 데이터 타입이 될 수도 있지만 배열 구조처럼 복잡한 구조를 가질수도 있으며 이를 통해서 다양한 구조를 가진 데이터를 도큐먼트 저장소에 담을수 있습니다. 아래의 그림에서 ‘tags’ 부분을 보면 단순한 배열 구조로 데이터가 저장이 되어 있으며, ‘comments’의 경우에는 좀더 복잡한 배열 구조를 가지고 있습니다.

 

[ 소셜 뉴스 사이트의 저장 문서의 구조 ]

다큐먼트 저장소에 데이터를 저장하는 형태는 XML, JSON, BSON 형태입니다.

BSON(Binary JSON)   BSON은 바이너리 JSON(Binary JSON)의 약어로 JSON 문서를 바이너리로 인코딩한 포맷입니다. 최초에 몽고DB에서 제안하였으며, 주로 JSON 형태의 데이터를 저장하거나 네트워크를 통해서 정보를 전송할 때 사용됩니다.   BSON은 데이터를 표현할 때 리틀 엔디언(Little Endian) 방식으로 작성을 하기 때문에 하위바이트를 먼저 기술합니다. 아래의 그림은 JSON을 BSON의 변환하는 방법을 나타낸 개념도입니다. [ JSON을 BSON의 변환하는 방법 ]

 

 

몽고DB의 유연한 쿼리 제공

몽고DB가 많은 사람들에게 각광 받고 있는 것은 빠른 속도와 유연한 쿼리를 제공해주기 때문입니다. 빠른 속도는 관계형 데이터베이스가 가지고 있던 대용량으로 확장하는데 걸림돌을 제거해 주었고, 유연한 쿼리는 관계형 데이터베이스가 가지는 복잡한 쿼리를 대체할 수 있는 기대감을 주었습니다. 

[ 관계형 데이터베이스와 몽고DB의 쿼리 비교 ]

관계형 데이터베이스에서는 애드혹(ad hoc)기능을 지원하고 있습니다. 애드혹이란 데이터베이스 시스템이 받아들일 수 있는 질의를 미리 정의할 필요가 없으며 질의의 내용이 무엇이든지 간에 잘 알려진 형식이면 쿼리가 실행이 된다는 것입니다. 애드혹 기능은 모든 데이터베이스 시스템에서 디폴트로 제공하는 기능은 아니지만 몽고DB에서는 이 그 기능을 대부분 지원하려고 노력하고 있습니다.

 

 

몽고DB의 복제 정책

몽고DB는 데이터베이스의 복제(Replication) 기능을 제공합니다. 이 기능은 서버와 네트워크 장애가 발생할 경우를 대비해 데이터를 다른 서버에 백업하고 핵심 서버가 동작이 불가능할 경우 다른 보조 서버에게 핵심서버의 역할을 맡기는 일을 담당합니다.

 

또한 복제는 데이터베이스의 읽기에 대한 확장을 위해서도 사용됩니다. 데이터베이스 연산 작업시 성능과 가장 밀접한 관계에 있는 것이 데이터베이스에 접근하여 데이터를 읽는 작업입니다. 속도 성능을 개선하기 위해서 여러대의 서버에 읽는 작업을 분산하여 처리를 합니다.

 

몽고DB에서의 복제 방법은 기본적으로 마스터(Master)-슬레이브(Slave) 방식을 채택하고 있습니다. 마스터가 죽더라도 슬래이브중에서 마스터를 선출할 수 있는 마스터 선출 방식을 채택하고 있습니다.

[ 몽고DB의 복제 정책 ]

쓰기 연산 동작은 마스터에서만 이루어집니다. 쓰기 연산 데이터를 저장하는 곳은 ‘Data Store’와 ‘Oplog’ 두 군데 영역에 저장합니다. ‘Data Store’에는 쓰기 연산을 수행한 결과를 저장하고 ‘Oplog’는 연산 수행과 관련된 명령 자체를 타임스탬프와 같이 저장합니다. 슬래이브는 읽기만 가능합니다.

 

 

확장

대부분의 데이터베이스에서 시스템을 확장 하는 방법에는 수직적 확장(Vertical scaling)과 수평적 확장(Horizontal scaling)으로 나눌수 있습니다. 먼저 수직적 확장은 디스크나 메모리를 추가하는 방법을 말합니다. 이 방법은 아주 간단하며 신뢰성이 뛰어나고 비용이 적게 들지만 빅데이터와 같은 대용량 데이터 처리에서는 문제가 발생합니다.

 

수평적 확장은 데이터베이스를 여러대의 서버에 분산시켜서 저장을 합니다. 이 구조의 장점은 기존의 하드웨어 장비를 그대로 사용할 수 있으며 장애 발생시 복제 서버를 통한 지속적인 서비스 제공이 가능합니다.

 

몽고DB는 수평적 확장이 용이하도록 설계되었습니다. 자동 샤딩(Auto sharding)을 통해서 데이터를 여러 노드에 걸쳐 분산하는 것을 자동으로 관리해줍니다. 또한 샤딩 시스템은 샤드 노드를 추가해서 용량을 필요한 만큼 늘릴수 있습니다.

 

 

몽고DB의 라이센스

몽고DB는 많은 자바 기반의 시스템과 틀리게 C++로 구현되어 있으며, 맥 OS, 윈도우, 리눅스에서 컴파일 되고 실행할 수 있습니다. 바이너리의 경우에는 ‘mongodb.org’에서 다운로드 받을 수 있으며, 해당 소스코드는 오픈되었으며 ‘GNU-AGPL’ 라이센스를 가지고 있습니다.

 

‘GNU-AGPL’에 대해서는 논란의 소지가 많은데, 이 라이선스가 실제로 의미하는 바는 소스 코드는 무료로 이용이 가능하지만 소스 코드에 대한 수정사항은 커뮤니티의 이익을 우해서 공개되어야 한다는 것입니다. 수정사항에 대해서 공개를 원하지 않는 회사에 대해서는 특별한 상업적 라이선스를 제공하고 있습니다.