쪼리

플러그인 스토리지 엔진

스토리지 엔진은 사용자의 데이터를 디스크와 메모리에 저장하고 읽어오는 역할을 담당한다. MMAPv1과 WiredTiger 등을 스토리지 엔진이라고 하며, 이 엔진들은 사용자의 데이터를 디스크에 영구적으로 기록하거나 다시 읽어와서 메모리에 적재하는 역할을 담당한다.

몽고디비 서버도 MySQL 서버와 동일하게 다양한 스토리지 엔진을 사용할 수 있도록 스토리지 엔진이 플로그인 형태로 구현되어 있으나 MySQL 서버와 달리 하나의 인스턴스에서 동시에 여러 개의 스토리지 엔진을 사용할 수가 없다.

즉 하나의 몽고디비 서버에서 MMAPv1와 WiredTiger 스토리지 엔진을 동시에 사용할 수는 없다. 몽고디비 서버는 쿼리를 분석해서 옵티마이저라고 부르는 컴포넌트가 최적화된 실행 계획을 수립하면 실제 그 실행 계획에 맞게 디스크에서 데이터를 읽어는 역할은 스토리지 엔진이 하는 것이다.

스토리지 엔진 종류

• MMAPv1: 처음 출시됐을 때 사용되던 스토리지
• WiredTiger: 몽고디비 3.0부터 도입된 스토리지 엔진
• In-Memory: WiredTiger 변형, 디스크에 기록하지 않고 메모리에만 보관
• RocksDB
• TokuDB

MMAPv1 스토리지 엔진을 제외한 모든 스토리지 엔진은 도큐먼트 수준의 잠금을 지원하기 때문에 대부분 스토리지 엔진의 동시성 처리는 우수하다고 볼 수 있다. 또한 대부분 데이터 파일이나 인덱스의 압축도 지원한다.

WiredTiger 스토리지 엔진

WiredTiger 스토리지 엔진은 내부적인 Lock 경합 최소화를 위해서 Hazard-Pointer나 Skip-List와 같은 많은 신기술을 채택하고 있으며, 최신 RDBMS들이 가지고 있는 MVCC와 데이터 파일 압축, 암호화 기능 등을 갖추고 있다.

내부 동작 방식

다른 DBMS와 동일하게 B-Tree 구조의 데이터 파일과 서버 크래시로부터 데이터를 복구하기 위한 저널 로그(WAL)를 가지고 있다. 다른 RDBMS의 WA처럼 로테이션되면서 로그 파일의 로그 슬롯이 재활용되는 방식이 아니라 새로운 로그 파일이 계속 생성된다.

그리고 체크포인트 시점 이전의 저널 로그는 더 이상 필요하지 않으므로 체크포인트 이후 시점의 저널 로그만 남기저 이전 저널 로그는 자동으로 삭제한다.

공유 캐시

WiredTiger 스토리지 엔진에서 사용자의 쿼리는 공유 캐시를 반드시 거쳐야 한다. 그래서 공유 캐시의 최적화는 몽고디비의 처리 성능에 있어서 매우 중요한 역할을 담당한다. 짧은 시간에 수많은 쿼리를 처리해야 하는 OLTP(On-Line Transaction Processing) 시스템에서는 많은 쿼리들이 공유 캐시에 있는 하나의 데이터 페이지를 동시에 참조하기 위해 경합하는 경우도 많기 때문에 공유 캐시 객체에 대한 잠금 경합이 성능에 많은 영향을 미친다.

WiredTiger 엔진은 공유 캐시의 잠금 경합(Mutex Contention)을 최소화하기 위해서 Lock-Free 알고리즘을 사용한다. 해당 알고리즘은 잠금을 사용하지 않는 것을 의미하는 것이 아니라 경합을 최소화하는 알고리즘을 의미한다. 대표적으로 하자드 포인터와 스킵 리스트 자료 구조를 활용하여 Lock-Free를 구현하고 있다.

MVCC(Multi Version Concurrency Control)

MVCC는 하나의 도큐먼트에 대해서 여러 개의 버전을 동시에 관리하면서 필요에 따라 적절한 버전을 사용할 수 있게 해주는 기술이다.

WiredTiger 스토리지 엔진은 READ_UNCOMMITTED와 READ_COMMITTED 그리고 SNAPSHOT 격리 수준을 기본 격리 수준을 제공하며, 몽고 디비 서버에 내장된 WiredTiger 스토리지 엔진은 SNAPSHOT 격리 수준을 기본으로 하고 있다.

SNAPSHOT 격리 수준은 REPEATABLE_READ와 동일한 격리 수준이다. 그러므로 RDBMS와 비슷하게 검색을 실행하는 커넥션은 자신의 트랜잭션 번호보다 낮은 트랜잭션이 변경한 마지막 데이터만 볼 수 있다.

참고

• 도서 : Real MongoDB

등장배경

글로벌 IT 서비스를 제공하는 회사가 늘어나면서 방대한 양의 데이터를 충분히 빠른 속도로 제공할 수 있는 데이터베이스에 대한 필요성이 높아졌다.

그러나 이를 상용 RDBMS로 이를 처리하기에는 라이선스 비용 문제가 발생하였기 때문에 MySQL 서버가 많이 발전하고 대용량을 전담하는 DBMS로 활용하였으나 부족한 부분은 많았다.

Scale Out 하기에는 쉽지 않기 때문이다. 그러나 2000년대 후반까진 NoSQL DBMS 들이 기능들이 미성숙하여 상용으로 쓰긴 힘들었으나 아래와 같은 장점으로 인해 몽고디비 활용이 늘어나기 시작했다.

• 트랜잭션지원, 분산처리, 재해복구, 샤딩 & 리밸런싱, 데이터복제 자동복구 지원
• WiredTige 엔진 장착 이후

라이선스

몽고디비는 “Mongo DB, Inc”에 의해서 개발 및 유지 보수되는 오픈 소스 데이터베이스다.

또한 기술 지원과 추가 기능을 사용할 수 있는 유료 라이센스 모델인 프로페셔널과 엔터프라이즈 서비스도 제공하고 있다.

몽고디비 버전은 일반적으로 많이 사용되는 3개의 숫자로 구성된 버전으로 관리된다.

특이한 점은 홀수 번호는 개발 버전을, 짝수 버전은 릴리즈 버전을 의미한다. 현재 릴리즈 버전이 3.2.3 이라면 이에 해당되는 개발 버전은 3.3.3 인 것 이다.

아키텍처

몽고디비의 간단한 아키텍처는 다음과 같다.

응용 프로그램들은 각 언어별로 적절한 드라이버를 이용하여 몽고디비 서버와 통신한다.

그리고 몽고디비 서버의 네트워크 모듈은 쿼리 프로세서 모듈로 전달한다. 쿼리 프로세서 모듈은 여러 과정을 거쳐 사용자 데이터를 지정된 스토리지 엔진으로 주고받는다.

가장 아래쪽 구성요소에 위치한 스토리지 엔진은 사용자 데이터를 디스크에 저장하거나 디스크에서 데이터를 읽어서 쿼리 프로세서 모듈로 전달한다.

배포 형태

몽고디비는 클러스터 형태로 서비스할 수 있도록 구현된 데이터베이스 서버다. 하지만 MySQL 서버와 같이 단일 서버로도 사용할 수 있을 뿐더러 복제 또는 샤딩된 구조로도 활용할 수 있다.

단일 노드

• 단일 노드로 사용하므로 아무런 관리 컴포넌트가 필요하지 않음
• 복제를 위한 로그도 필요하지 않으며 다른 노드와의 통신도 불필요
• 단일 노드 구성에는 몽고 DB 드라이버가 직접 몽고디비 서버로 직접 연결하게 되며, 별도의 레플리카 셋을 두지 않으니 몽고 DB 서버가 응답 불가일 경우 자동 fail over나 HA 기능이 작동할 수가 없음

단일 레플리카 셋

• 단일 레플리카 셋에도 별도의 관리용 컴포넌트가 필요하지 않지만 레플리카 셋 구축을 위해 추가적인 몽고디비 서버가 필요
• 레플리카 셋은 자동복구를 위한 최소 단위
• 몽고 디비 드라이버는 직접 몽고디비 서로 접속하지만 replicaSet 옵션을 사용해야한다.
• 아래의 그림처럼 레플리카 셋에는 항상 1개의 프라이머리 노드와 1개 이상의 세컨더리 노드로 구성되며 primary 노드는 사용자의 데이터 변경 요청을 받아 처리하며, 세컨더리 노드는 변경 내용을 전달받아 서로의 데이터를 동기화한다.
• 읽기 쿼리는 프라이머리 노드뿐만 아니라 필요하면 세컨더리 노드로 요청할 수 있다.
• 레플리카 셋은 투표로 프라이머리 노드를 결정하므로 홀수 개의 노드로 구성하면 좋다.

단일 레프리카 셋으로 구성된 서버에 접속할 때, 응용 프로그램에서는 레플리카 셋을 구성하는 멤버들의 목록을 connection string에 사용해야 하며, 나열된 목록의 몽고 디비 서버만 접속할 것으로 보이지만, 몽고디비 드라이버는 나열된 서버 목록들을 seed로만 사용할 뿐이다. 즉, connection string에 나열된 멤버 중 가용 멤버에 접속해서 레플리카 셋을 구성하는 멤버 목록들을 확인하여 모든 멤버들의 적절히 접속한다.

샤딩된 클러스터

• 아래와 같이 샤딩된 클러스터 구조에서는 하나 이상의 레플리카 셋이 필요하며 각 레플리카 셋은 자신만의 파티션 된 데이터를 가지게 된다.
• 샤딩된 클러스터에 참여하고 있는 각각의 레플리카 셋을 샤드라고 하는데, 이 샤드들이 어떤 데이터를 가지는지에 대한 정보는 몽고디비 Config 서버거 관리한다.
• 샤딩된 클러스터 구조에서는 응용 프로그램의 드라이버가 직접 몽고디비 서버에 접근하면 안된다. 몽고 디비 드라이버는 몽고 디비 라우터(mongos)로 연결하고, 라우터는 컨피그 서버로 부터 각 샤드가 가지고 있는 메타 정보들을 참조하여 쿼리를 실행
• 그 뿐만 아니라 라우터는 사용자를 대신해서 모든 샤드로 쿼리를 요청하고 결과를 정렬 및 병합해서 반환하는 처리도 수행

참고 자료

• 도서: Real MongoDB