[MongoDB in Action] MongoDB 셸

이 내용은 몽고디비 인 액션 2nd Edition 책을 읽고 개인적으로 정리한 내용입니다.

코어 서버 mongod

코어 데이터베이스 서버는 mongod라는 실행 프로그램을 통해 구동된다. mongod 프로세스의 데이터 파일은 모두 같은 서버에 저장되고, 저장되는 위치는 /data/db에 기본 설정되어 있다.

mongod는 stand-alone 모드와 replica-set의 모드로 실행될 수 있다.

MongoDB를 상용에서 구동할 때는 복제가 권장사항이며, 2개의 복제 노드와 arbiter 모드로 구동하는 mongod로 이루어진 복제 세트가 일반적이다.

샤딩 기능을 이용할 때 config server 모드로 mongod 프로세스를 구동시킬 수 있다. 또한 mongos라는 별도의 라우팅 서버도 존재한다.

11장(복제) 와 12장(샤딩)에서 좀 더 자세히 다룬다

mongo shell

MongoDB 명령어 shell은 자바스크립트에 기반한 툴이다. mongo 실행 파일은 shell을 로드하고 지정된 mongod 프로세스에 연결한다. 여기서 query를 날릴 수도 있으며 서버의 상태를 체크할 수도 있다.

몽고가 설치 되어 있다면 여러 커맨드로 다양한 작업을 할 수 있다.

• mongodump, mongorestore : mongodump로 백업하고, mongorestore로 복구한다.
• mongoexport, mongoimport : JSON, CSV, TSV 타입의 데이터를 export, import 할 수 있다. (대용량 데이터를 초기에 임포트하기 좋다)
• mongostat : MongoDB 시스템을 지속적으로 poll 해서 모니터링에 유용한 통계 데이터를 제공한다.
• mongotop : 각 컬렉션의 데이터를 읽고 쓰는데 걸린 시간의 양을 보여준다.
• mongoperf : MongoDB 인스턴스가 구동되고 있을 때 발생하는 디스크 오퍼레이션을 이해하는데 도움을 준다.
• mongooplog : MongoDB oplog에서 어떤일이 발생하고 있는지를 보여준다.
• bsondump : BSON 파일을 JSON을 비롯해 사람이 읽을 수 있는 형태로 변환해준다.

몽고 DB를 사용하는 이유

MongoDB는 관계 데이터베이스와 Key-Value 저장 시스템의 장점만을 모아서 설계되었다.

Key-Value 데이터베이스 : 시스템의 단순성으로 인해 속도가 매우 빠르고 확장도 상대적으로 용이하다

• 대표적으로 Memcached가 있다. Memcached는 메모리에만 데이터를 저장함으로써 데이터의 지속성을 포기한 대신에 속도가 매우 빠르다. (저장 시스템으로는 적합하지 않고, 캐싱 계층이나 잡 큐와 같은 서비스에 쓰인다.) 관계 데이터베이스 : 수평적인 확장은 어려운 반면에 다양한 데이터 모델과 강력한 쿼리 언어를 가지고 있다.

몽고DB는 이 둘 사이의 유용한 측면을 취하는 타협점으로서 의도되었으며, 최종 목표는 쉽게 확장되고, 다양한 구조의 데이터를 저장할 수 있고, 정교한 쿼리 언어를 갖는 데이터베이스가 되는 것이다.

데이터베이스의 용도라는 관점에서 보면 MongoDB는 아래 condition에서 일차 데이터 자장시스템으로 적합하다.

• 웹 애플리케이션
• 분석과 로깅 애플리케이션
• 중간 정도의 캐시를 필요로 하는 애플리케이션
• 미리 구조가 알려지지 않는 데이터 저장소

MongoDB 와 다른 데이터베이스 비교

간단한 키-값 저장 시스템

Key-Value 저장 시스템은 일반적으로 캐싱에 사용된다. 키-값을 새로 넣거나 검색하거나 삭제할 수 있을 뿐이라 일반적으로 빠르고 확장성이 좋다.

가장 잘 알려진 것으로는 Memcached 가 있다. 맴캐시디는 데이터를 메모리에만 저장함으로써 데이터의 지속성을 포기한 대신에 속도는 매우 빠르다. 또한, 분산 시스템으로 동작하면서 여러 서버에 걸쳐 캐시 상태를 유지해야 하는 복잡성을 없애준다.

하지만 Memcached 는 기본 데이터 저장 시스템으로는 거의 사용되지 않으며 캐싱 계층이나 Job Queue와 같은 서비스를 위한 단순한 지속성 계층에서 사용하는 것이 최선이다.

정교한 키-값 저장 시스템

좀 더 기능이 많은 데이터 모델을 위해 단순한 키-값 저장 시스템을 보다 정교하게 만들 수 있다. 아마존의 다이나모를 들 수 있다.

다이나모의 목표는 장애가 발생했을 때 계속해서 기능할 수 있는 데이터 저장 시스템이다. 이러한 시스템을 위해서는 데이터가 여러 개의 노드에 걸쳐서 자동으로 복제됨으로써 항상 읽기와 쓰기를 할 수 있어야 한다.

다이나모에서는 마스터가 없고 모든 노드가 동등하므로 시스템을 하나의 전체로서 이해하기가 쉽고 노드를 쉽게 추가할 수 있다.

이러한 다이나모의 확장성을 많이 구현한 것이 카산드라이다.

카산드라는 페이스북에서 수신함 검색 기능을 위해 만든 데이터 저장시스템의 오픈소스버전이다. 데이터는 사용자 인덱스로 인덱스되는데, 각 레코드는 키워드 검색을 위한 검색어 배열과 수신자 검색을 위한 수신자 아이디 배열로 이루어져 있다.

위의 두 예를 보면, 대용량 저장 장치와 가용성이 요구될 때, 이러한 정교한 키-값 저장 시스템이 필요한 것을 확인할 수 있다. 마스터가 없는 구조이므로 이 시스템은 노드를 추가해서 쉽게 확장한다. 또한, eventual consistency를 채택했는데, 이 의미는 현재 읽은 데이터가 반드시 가장 마지막에 쓰여진 데이터는 아니라는 것이다.

이것은 엄격한 일관성, 더 다양한 데이터 모델 그리고 secondary index를 제공하는 MongoDB와는 대조된다.

관계 데이터베이스

관계 데이터베이스가 고정된 스키마 테이블을 사용하는 반면에 MongoDB는 스키마가 없는 도큐먼트를 사용한다.

SQL은 데이터 과학자나 데이터 탐색을 위해 질의를 작성하는 분석가들에게 쉬울 것이다. 반면에 MongoDB 쿼리 언어는 애플리케이션으로 내장하기 위한 쿼리를 작성하는 개발자들을 겨냥한 것이다.

도큐먼트 데이터베이스

Document 데이터베이스는 많지 않다. CouchDB가 있으며 MongoDB와 비슷하지만 CouchDB는 JSON을 단순 텍스트로 저장한다. CouchDB에서는 인덱스가 맵리듀스 함수를 작성해서 정의된다는 점이 다른데, 많이 복잡하다. 확장성도 차이가 있는데, CouchDB는 데이터를 서버에 걸쳐서 파티션하지 않고 노드 각각에 하나의 완전한 복제본을 가지고 있다.

사용 예와 배포

웹 애플리케이션

MongoDB는 웹 애플리케이션에서 일차적 데이터 저장 시스템으로 사용하기에 적당하다. 사용자 관리, 세션, 데이터, 업로드 등을 위해 수많은 데이터 모델이 필요한데, 이러한 것들을 다양한 구조의 데이터로 표현할 수 있으므로 관계 모델로 표현할 때 필요한 테이블 수보다 훨씬 적다.

MongoDB는 높은 트래픽의 웹사이트를 유지하는 데 유용한 도구다. TBI 라는 외사가 100만 뷰가 넘는데도, 안정적으로 MongoDB를 운영하고 있다고 한다.

애자일 개발

Shutterfly나 뉴욕타임스처럼 많은 개발 팀들이 훨씬 더 신속하게 애플리케이션을 만들 수 있다고 판단해서 MongoDB를 선택했다. ORM(객체-관계 매핑) 기술에 의해 생성된 SQL을 최적화하는 데 들어가는 시간이 절감된다. 따라서 짧은 개발 사이클과 중간 크기의 애자일 개발 팀에 의한 프로젝트에 도움이 된다.

분석과 로깅

MongoDB가 분석에 적합한 것은 속도, 그리고 타깃 atomic 업데이트와 capped 컬랙션이라는 두 가지 핵심적인 특징 때문이다.

• atomic 업데이트 : 카운터의 값을 효율적으로 증가하고 값을 배열에 푸시할 수 있다.
• capped 컬렉션 : 가장 최근의 도큐먼크만을 저장한다.

grep 이나 로그 검색 유틸리티를 쓰지 않고도 MongoDB 쿼리 언어를 사용해서 로그를 검색할 수 있다.

캐싱

더 빠른 쿼리언어와 객체를 보다 전체적으로 표현할 수 있는 데이터 모델을 제공하는 장점으로 인해 캐시로서 사용하기도 한다.

가변적인 스키마

json 을 bson 타입으로 직접 변환해서 저장한다. 이는 json 구조에 대한 선언 없이 인덱스와 질의를 쉽게 할 수 있게 해준다는 뜻이다.

팁과 한계

그렇다면 몽고DB의 한계점은 무엇일까?

대부분은 MongoDB가 메모리 맵(memorymapped) 파일에서 어떻게 데이터를 관리하고 디스크와 메모리 사이에서 데이터를 이동시켰는지에 대한 결과다.

1. 첫 번째로 MongoDB 는 보통 64비트 시스템에서 실행되어야 한다. 32비트 시스템은 4GB의 메모리만 쓸 수 있다.
2. 가상 메모리 매핑을 사용해서 발생하는 두 번째 결과는 MongoDB가 필요한 경우에 메모리를 자동으로 할당한다는 점이다.
3. 이용 가능한 램 크기를 초과하는 데이터 세트를 질의할 때 메모리 스와핑이 발생하는 데이터에 대해 자주 디스크 접근을 요구한다.
   • 작업 세트가 메모리를 초과하고 쿼리가 심각하게 느려지기 전에 모니터링을 통해 알아야겠다.
4. 도큐먼트 구조가 데이터 크기 관점에서는 효율적이지 않다.
   • ‘username’ 이라는 필드 이름을 가진 모든 도큐먼트가 필드 이름을 저장하기 위해 8바이트를 사용함을 뜻한다.
5. SQL 만큼 친숙하거나 쉽지 않다.
6. 대규모의 클러스터를 운영하기 위핸 유지비용이 발생할 수 있다.
   • 클러스터를 구성할 때 복제와 샤딩을 각각 설정되고 관리해야함을 뜻한다.

요약

MongoDB는 오픈소스, 도큐먼트 기반 데이터베이스 관리 시스템이다. 오늘날의 인터넷 애플리케이션에서 필요한 데이터와 확장을 위해 설계된 MongoDB는 동적 쿼리언어와 세컨더리 인덱스가 특징이다. 그 외에도 빠른 원자적 업데이트와 복잡한 집계, 자동 장애조치와 복제, 수평적 확장을 위한 샤딩 등이 있다.