MongoDB 시험 정보

몽고디비 구조

MQL(MongoDB Query Language)

SQL을 생각하면 쉽다. RDBMS의 SQL 대신 MQL을 사용한다

클라이언트 라이브러리에서 전달되는 BSON 프로토콜 메세지를 번역한다.

MongoDB Document Data Model

모든 CRUD 명령어가 반드시 실행되고 DBMS의 설정에 따라 결과의 구조를 결정 하는 부분이라고 한다.

네임스페이스, 인데스, 데이터 스트럭쳐, 콜렉션등의 요청에대해 응답을 작성하는 부분.

또한 작성된 가용성 요구사항을 처리하기 위해 write concerend, readconcerns 등 레플리케이션 메커니즘이 동작하는 부분이다.

Storage Layer

데이터의 영속성을 보장해야 하는 부분!

시스템 요청, 디스크 플러시, 파일 구조, 압축 레벨을 지정하는 레이어

데이터 압축, 저수준 시스템 접근이 발생하는 부분

스토리지 엔진

MySQL의 InnoDB와 같은 스로리지 일까?

어떻게 구성되었는지에 따라 다른 속성을 지정하게 되는 몇몇 스토리지 엔진이 있다. 기본적으로 WiredTiger를 사용한다고 함.

Security & admin

강의에서는 계층 구조(상하)구조로보여주지 않고 양옆에 세워져 있는 레이어로 보여준다.

유저 관리, 인증, 네트워크, 암호화/복호화 관련 작업은 Security 레어어에서 담당한다.

반명에 어드민 레어어는 데이터베이스 생성, 콜렉션 이름 변경, 로그 등 관리자 측면에서 해야하는 모든일을 담당한다.

몽고디비

지금까지는 MongoD라는 하나의 데이터베이스에 대해 간략히 작성해 보았다. 하지만 MongoDB는 단지 MongoD들을 말하는것이 아니다.

몽고디비는 분산 데이터베이스 시스템이다.

레플리카 그룹은 높은 가용성과 빠른 복구를 위해 같은 데이터를 가지고 있는 `들의 집합이다. 하나의 주(primary) 데이터베이스와 여러개의 백업(secondary) 데이터베이스로 구성된다.

빠른 복구를 위해 raft 합의프로토콜을 기반으로 작성된 failover 프로토콜을 가지고 있다고 한다. 따라서 프라이머리 데이터베이스에 이상이 생긴 경우 자동으로 백업 데이터베이스 중 하나가 주 데이터베이스로 설정된다

이런 방법으로 서비스 장애를 매우 빠르게 대응할 수 있다. 두번째 데이터베이스가 서비스를 담당하는 사이 문제가 생긴 데이터베이스를 처리하면 된다.

사용할수 있는 머신에 구애받지 않고 세계 곳곳에 배포할수 있도록 각 데이터베이스는 롤, 하드웨어, 운영체제를 통일하지 않아도 됨.

몽고디비는 확장 가능한(scalable) 데이터베이스이다

몽고디비는 데이터들을 샤드 클러스터에 데이터를 저장할수 있는데, 샤드 클러스터에 새로운 샤드를 추가하면 확장이 가능하다.

샤드는 전체 클러스터에 데이터를 복제하지 않고 일부 클러스터에만 내용을 복제하는 방식. 이런 샤드를 몽고디비에서 이용한다면 MongoS를 사용해야 하며 MongoS는 모든 샤드를 관리하는 만큼 모든 명령어가 샤드에 도달할수 있게 해야함. 당연한 말이지만 어플리케이션의 요청도 처리해야 함.

샤드를 구성한다면 MongoD는 직접 접근할 이유가 없음.

몽고디비는 클러스터의 메타데이터를 저장하는 컨피스 서비스를 제공한다. 샤드와 데이터를 매핑한 정보, MongoS의 수, 어떤 콜렉션이 분산되어있는지 등등… 에 대한 정보를 관리하는 레플리카