MongoDB 3.0 발표
새로운점
- 기존과는 다른 새로운 기능이 추가 되었음.1. pluggable storage engin API 제공 :
가장 두드러진 특징
third parti들에게 새로운 스토리지를 생성할 수 있도록 허용하는 인터페이스 제공
특정 어플리케이션에 의해서 튜닝이 가능
MongoDB 가 자신의 스토리지 엔진을 제공하는 것을 허용
2. 더욱 정교한 locking기능 제공, 더욱 우수한 동시성 제공, 속도도 빨라짐
3. 더 쉬워진 쿼리 옵티마이징 처리 에서부터 풍부한 로깅까지 DBA와 오퍼레이터에게 편의기능 제공
4. 고차원 MongoDB Management Service 지원 :
Cloud Manager 제공
향상된 서버의 관리 시스템
하나의 콘솔에서 다수의 다양한 MongoDB cluster들을 관리 가능
엔진의 향상
이전 버젼의 MongoDB는 단일 스토리지 엔진을 제공했었다, 이를 MMAP라고 부른다, 메모리 맵 파일을 도입해서 사용하고 있었다. MMAP는 디스크 I/O의 모든 작업, seeks, block caching, OS상에서 이러한 작업이 수행되었다.MongoDB 3.0은 MMAP의 향상된 버젼(MMAPv1)과 WiredTiger 스토리지 엔진을 제공하게 변경이 되었다.
MMAPv1은 MMAP에 대한 backword compatible 지원을 위해 유지, 이전 MongoDB로 개발된 버젼은 MMAPv1으로 업그레이드 할 수 있다. MMAPv1은 locking 에 대해서 미세한 처리를 수행할 수 있도록 개선 되었다. MMAP는 데이터베이스 레벨로 Lock을 잡았었다. 이로 인해 MMAP는 datalevel로 락을 걸었기 때문에 한번에 하나의 컬렉션만을 쓰기 할 수 있었다. MMAPv1은 컬렉션 레벨로 lock을 걸수 있다. 클라이언트는 복수개의 컬렉션을 동시에 쓰기 할수 있게 되었다. 이로 인해 쓰기 처리 속도는 확실하게 빨라졌다. 그러나 읽기도 빨라졌다. 읽기는 write에 의해서 블록이 될 수 있기 때문이다.
MMAPv1은 할당 메커니즘에 대한 향상도 가져왔다. MongoDB는 document-base 저장소이다. 각 도큐먼트는 반드시 연속적으로 저장되어져야 한다. 도큐먼트가 업데이트 되어 새로운 필드가 추가되거나 존재하는 컨텐츠의 길이가 더 길어지는 경우 전체 도큐먼트는 추가적인 공간을 얻기 위해서 다시 쓰기가 수행되어야 한다. 말할 필요도 없이 도큐먼트 재쓰기 작업은 매우 비싼 작업이다. 도큐먼트가 이동되면 이동과 더불어 인덱스 작업도 수행되어야 한다.
3.0버젼 이전에는 padding factor을 이용했었다. 이는 할당 타임에 추가적인 공간을 잡아주어 재쓰기 작업을 최소화 하는 목적으로 사용되었다. 이러한 padding factor는 이전에 할당된 이력이나 문서의 확대 속도에 따라서 추론되는 방법으로 운영된다.
3.0버젼에서는 2제곱으로 지정된 할당을 사용한다. 각 도큐먼트는 2제곱에서 가장 가까운 크기의 레코드로 저장된다. 그래서 padding은 항상 수행될 수 있도록 하고 있다. 현재 할당된 레코드를 넘어서는 도큐먼트가 있다면 새로운 레코드는 그 다음 거듭제곱으로 할당되어진다. 이것은 document의 재작성을 줄여주며, 하지만 사용되지 ㅇ낳는 도큐먼트 공간에 대한 추가적인 비용이 필요하다. 게다가 레코드 크기는 2의 거듭 제곱이기 때문에 레코드의 프라그멘테이션이 줄어들게 된다. 빈 공간은 쉽게 재 사용 될 수 있다.
노트 : 만약 도큐먼트 크기가 변경되지 않는다면 "power of two" 전략을 각 컬렉션에 대해서 끌 수 있다.
WiredTiger의 내부
MMAPv1은 MongoDB 3.0의 기본 저장 엔진이다. 새로운 WiredTiget storage engine은 획기적인 이점을 제공한다. WiredTiger는 동일한 이름을 가진 회사에서 만든 엔진이다. 2014년 12월 MongoDB에 인수 되었다. 버클리 DB database의 아키텍트를 차용하였다.WiredTiger 성능의 많은 부분은 주의깊게 설계된 내부로 부터 나온다 예를 들어 WiredTiger는 "hazard pointers"를 이용한다. 이는 공유된 객체에 멀티 쓰레도르 접근을 컨트롤 하기 위해서 lock-free메커니즘을 이용한다. 추가적으로 빠르게 업데이트 하기 위한 log-structed 머지와 Bloom filter 접근을 위한 arguments tree를 이용하며 키를 이용한 서치에서 인덱스 miss가 될 수 있는 현상을 줄였다.
MMAPv1은 collection level에 락을 거는 것과는 다르게 (이것만으로도 매우 큰 향상을 가져 왔음), WiredTiger는 도큐먼트 레벨의 락을 건다. 그러므로 MMAPv1의 동시성은 일반적으로 MMAP보다 뛰어나다 그러나 WiredTiger의 동시성도 여전히 더 우수하다.
WiredTiger는 데이터 압축 작업을 잘 수행한다. 3가지 옵션이 있으며 no compression, Snappy(default), Zlib가 있다. Snappy와 Zlib 압축은 서드파티 라이브러리로 제공된다.
WiredTiger가 적용하는 데이터 압축은 collection level에 대해 적용된다. 그래서 도큐먼트 컬렉션중 압축할 대상을 지정하여 압축할 수 있다. WiredTiger는 인덱스와 분리해서 압축할 것이다(인덱스 압축을 enable한경우) 이때 prefix-compression으로 알려진 처리를 수행한다. 이것은 데이터 중복 제거의 일종이다. prefix compression의 이점은 데이터는 압축해제를 할 필요가 없다는 것이다. 결과적으로 인덱스 데이터는 RAM에 딱 맞게 배치되며 성능을 향상 시킨다.
혼합 과 매칭
앞에서 설명한것과 같이 pluggable storage engins API는 MMAPv1과 WiredTiger을 포함하는 것을 허용한다. 개발자는 그들의 스토리지 엔진을 생성할 수 있고, 타겟 어플리케이션에 대해서 특정 스토리지 기능을 추가할 수 있다. 게다가 서로다른 스토리지 엔진은 동일한 MongoDB 개발에서 사용될 수 있다. 비록 동일한 리플리카 셋을 이용하더라도, 복제는 스토리지 엔진에 투명하게 수행된다.리플리카 셋에서 주요 도큐멘트들은 하나의 스토리지 엔진에서 다른 스토리지 인젠으로 복제되어 저장될 수 있다. 인 메모리 스토리지 엔진에서 수행중인 리플리카셋의 멤버들은 주요 클러스트에 있고 (MongoDB 엔지니어의 실험적 버젼으로 현재 평가중이다.) 두번째 리플리카셋의 클러스터 멤버들은 WiredTiger와 같은 곳에 저장될 것이다. 리플리카 셋의 데이터에 접근은 매우 빠를 것이다. 왜냐하면 요청은 in-memory 스토리지 엔진에서 수행할 것이기 때문이다. 두번째 스토리지에서는 크래시로 부터 이들을 보호하는 역할을 하게 된다.
배치에서 이러한 혼합형 스토리지 엔진은 하나의 스토리지에서 다른 스토리지로 이관을 제공한다. MMAPv1 데이터베이스는 MMAP 데이터베이스에 적합하다. WiredTiger 데이터베이스의 경우는 그렇지 않을 것이다. 혼합된 스토리지 엔진에 의해서 MMAP데이터를 WiredTiger로 rolling upgrade의 형식으로 이전할 수 있다. 이로 인해서 클라이언트에게 downtime 없이 이관처리를 가능하게 해준다.
MongoDB관리
3.0의 기술적인 파트가 아닌 부분에대해서 MongoDB Management Service(MMS)는 많은 향상을 가져왔다. 이제는 MongoDB Cloud Manager이라고 불린다. 이 툴은 단일 모니터링 콘솔에서 전체 모니터링처리와 관리 서비스로 확장 되었다.CloudManager는 관리자에게 현재 수행되는 클러스터 통계를 확인할 수 있도록 하며 (MMS도 수행되었음), MongoDB 클러스터 디플로이와 성능 업그레이드, 스케줄 백업 등을 지원하고 있다. 시스템은 고수준 자동화 처리를 통해서 단일 클라우드 매니저 콘솔 컨트롤에서 불규칙한 크기의 MongoDB클러스트 관리로 확대 되었다. 클라우드 매니저는 자동적으로 다양한 자동화 에이전트를 통해서 수행할 수 있다. 그리고 에이전트는 클라우드 매니저 커맨드에 대한 응답을 처리한다.
Cloud Manager의 enterprise 벼젼은 (Ops Manager로 불린다.) 설치 기능을 제공하며, 이는 on-site monitoring과 management dashboard를 가능하게 지원한다. Ops Manager는 로컬 어플리케이션과 같이 수행한다. (Cloud Manager와는 다르게). Cloud Manager는 30일 무료 버젼을 제공함. 이는 오직 모니터링 기능만 제공해준다. Ops Manager는 MongoDB의 Enterprise Edition에서만 가능하다.
기타 개선
MongoDB는 커맨드 라인의 호스트와 함께 젝오한다. 이것은 mongoimport를 포함하여 외부 파일 데이터를 임포트 하는 기능을 가지고 있다. mongoexport는 MongoDB에서 JSON, CSV파일로 익스포트 할수 있어 데이터 베이스 백업을 수행할 수 있다.이 툴은 MongoDB 3.0을 위해 다시 만들어 졌다. 이전 생애에서는 C++ 의 기술을 기반으로 만들어 졌다.
MongoDB 엔지니어에 의해서 관리가 쉽게 그리고 실행 크기를 줄이는 방향으로 만들어 져 있다. 추가적으로 MongoDB 엔지니어들은 멀티 쓰레드 아키텍쳐로 툴의 성능을 향상 시켰다.
MongoDB의 이전 에디션에는 리플리카 셋에서 오직 12개의 클러스터 노드만을 만들수 있었다. 이제 MongoDB 3.0에서는 50 노드 리플리카 셋을 구성할 수 있다.
이러한 설정을 통해서 읽기 요청은 클라이언트에서 가장 가까운 노드 (ping 타임 기준) 에서 서비스를 수행한다. MongoDB는 반응성과 탄력성을 제공한다. MongoDB 3.0에서는 리플리카셋을 더 많이 제공한다. 이것은 요청 서비스가 더욱 클라이언트에 가깝다는 것이다. 나아가 클라이언트가 리플리카 셋에 주는 임팩트도 최소화 할 수 있다.
MongoDB 3.0은 쿼리 시스템의 개선도 가져왔다. MongoDB의 explain() 메소드는 만족스러운 쿼리를 위해서 플랜을 노출한다. 과거에는 쿼리를 먼저 수행하고 explain()을 수행해야 좋은 쿼리 플랜이 나왔다. 그러나 MongoDB 3.0에서는 쿼리 수행 전에 explain()을 요청하여 플랜을 볼수 있다. 이로 인해서 DBA는 쿼리를 보내기 전에 튜닝을 수행할 수 있다. (이것은 long-run 쿼리에서는 매우 우수한 기능을 제공한다.) 반환되는 쿼리 플랜은 좋은 쿼리 플랜을 제공할 뿐만 아니라. 쿼리 옵티마이저가 생각하는 다른 프랜역시 제공한다.
MongoDB 3.0에서는 다른 향상된 기능들을 찾을 수 있을 것이다. geospatial 인덱스를 광범위한 위치에 대한 처리부분에서 향상 시켰다. (현재는 지구 표면의 50퍼센트가 넘는 영역도 쿼리 할 수 있다.) 또한 개발자가 수행중인 시스템의 성능을 향상 시킬 수 있도록 튜닝에 도움을 주는 로깅 시스템의 미세한 처리도 제공한다. DBA는 audit로그를 설정하여 데이터베이스의 어떠한 오퍼레이션도 캡쳐 할 수 있다. 과거에는 오직 관리적인 액션만 로깅으로 잡을 수 있었다.
출처 : http://www.javaworld.com/article/2972304/data-storage/review-mongodb-3-0-rises-for-the-enterprise.html?nsdr=true
EmoticonEmoticon