MongoDb | Notion

Real 몽고 디비를 읽고 요약한 요약본입니다

책에서는 3.6버전 까지를 베이스로 작성되었으므로 최신 버전의 릴리즈 노트를 참고하여 내용을 일부 수정하였습니다
MMAP 스토리지 엔진, 전문 검색에 관한 내용은 빠져있습니다

MongoDb란?
- 비 관계형 NoSQl DBMS로써 분산 처리, 샤딩, 리 밸런싱 등에 특화된 데이터베이스
- 보조 인덱스는 스키마 프리가 아니므로 인덱스를 먼저 지정해야 한다
- 가능하다면 홀수 개의 노드로 구성해야 효율적이다 → 리더 선출 및 장애 복구에 효과적
- 샤딩된 클러스터는 MongoDB Router(mongos) 로 연결하고 컨피그 서버로 부터 메타데이터를 참조하여 실제 쿼리를 수행한다 → 샤딩되어 있다면 여기로 접속해서 쿼리해야 한다
- JSON의 변형인 BSON을 이용하여 저장한다
스토리지 엔진
- Mysql에서의 InnoDB와 같이 스토리지 엔진이 존재하며 가장 많이 쓰이는 것은 WiredTiger이다
- 하나의 서버에서 여러 스토리지 엔진을 같이 사용 할 수 없다
- 저자는 Read Ahead 알고리즘 때문에 리눅스 페이징 옵션(ATTR{bdi/read_ahead_kb}="16")을 16~32kb 정도로 유지하는 것을 권장한다 → https://www.percona.com/blog/2016/08/12/tuning-linux-for-mongodb/ 참조
- WAL(Write Ahead Log)를 이용하여 손실된 데이터를 재 시작 시에 복구 할 수 있다
- 공유 캐시의 크기는 서버 메모리의 50~60% 정도를 권장한다
- 데이터 저장 방식
  - 레코드 스토어: 테이블의 레코드를 한꺼번에 같이 저장하는 방식. Wired Tiger에서 사용
  - 컬럼 스토어: 컬럼 그룹(패밀리)로 데이터 파일을 관리하여 대용량 분석에 적합
  - LSM(log structured merge tree): 작은 조각으로 데이터를 메모리에 가지고 있다가 저장 한계를 넘어서면 디스크로 저장한다. 이 저장된 조각들을 지속적으로 병합하면서 데이터 파일로 성장시킨다
    - 일반적으로 레벨이 낮을 수록 최신 데이터이다
    - 데이터를 저장하는데 있어 B-Tree보다 훨씬 성능이 좋다
    - 읽기 성능이 느리다 → 여러 조각들을 전부 읽어야 한다
- Wired Tiger
  - MongoDb의 기본 스토리지 엔진
  - 데이터베이스 별로 디렉토리가 구분된다
  - 아키텍쳐
  - 저널: WAL 저널 로그. 데이터베이스 크래시로부터 데이터를 복구하기 위함
  - 리컨실링: 디스크에 기록하기 전에 기존 데이터와 비교하여 원본 레코드와 병합
  - 커서: 쿼리의 결과를 커서로 반환하여 클라이언트는 반복문을 통해 데이터를 가져온다
  - 에빅션: 자주 사용되지 않는 데이터 페이지를 캐시에서 제거하는 역할
  - 블록 매니져: 데이터를 디스크로 부터 읽어들이기 위한 역할
  - 체크포인트: 트랜잭션을 위해 지원됨. 데이터 파일과 WAL 로그가 동기화 되는 시점
    - 퍼지 방식: 오라클, Mysql 에서 채택하며, 조금 오래전 시점에 발생했던 트랙잭션을 기준점으로 삼는 방식. 과도한 디스크 IO를 방지하나 느리다
    - 샤프 방식: 몽고디비에서 쓰이며 체크 포인트 실행 시점에 디스크에 한번에 모아서 쓰기를 진행하므로 디스크 IO가 크게 발생한다
  - 버퍼 풀(공유 캐시): 인덱스나 데이터를 메모리에 캐시하고, 데이터의 변경을 한번에 배치 처리하는 기능 담당
    - 사용자의 쿼리는 모두 이 캐시를 거친다
    - 공유 캐시의 잠금 경합을 최소화 하기 위해 Lock-Free 알고리즘을 채택하고 있다
      - 하자드 포인터: 사용자 스레드가 참조하는 페이지를 등록하고, 없는 경우 이빅션 스레드가 페이지를 비울 수 있도록 지원
      - 스킵 리스트: 레코드의 변경 이력을 이 리스트에 저장하여 캐시된 데이터 페이지를 바로 변경하기 보다 리스트를 참조하기 때문에 락을 줄인다
  - MVCC(Multi Version Concurrency Control) 지원
    - Repeatable-read(Mongo에서는 SnapShot 으로 표현) 수준의 격리를 지원하여 같은 트랜잭션에서는 항상 같은 데이터가 읽히기 위한 기술
  - 운영체제 캐시(페이지 캐시)
    - 운영체제의 캐시를 통해 공유 버퍼에 들어가기 때문에 캐시가 두 군데 생기는 더블 버퍼링 현상이 일어난다
    - 스토리지 엔진의 기본 방식이며, 이 페이지 캐시를 제외하고 운영하는 Direct IO 방식은 현재 추천되지 않는다
    - 성능 역시 현재는 캐시 방식보다 떨어진다
- Percona 메모리 스토리지
  - 메모리에 데이터를 적재하는 스토리지 엔진. 휘발성이다
  - 체크포인트, 페이지 이빅션이 불필요하다

복제
- 서버 간 데이터를 동기화하는 논리적 복제 방식을 선택
- 레플리카 셋: 데이터를 공유하는 노드 그룹
- 컨센서스 알고리즘: 데이터를 동기화하고 특정 노드가 응답 불능일 때 대처하는 합의 알고리즘
  - Raft: 하나의 데이터를 레플리카셋의 특정 맴버만 변경할 수 있는 방식. MongoDB 채택
    - 리더( 프라이머리 노드)와 팔로워 (세컨더리 노드) 를 선출하여 이용하는 방식
  - Paxos: 동일한 데이터를 레플리카 셋의 아무 맴버나 변경 할 수 있는 방식. Mysql 채택
- 프라이머리 노드는 한 시점에 단 한 개만 존재가능하다
- 세컨더리 노드는 읽기 전용으로 사용 가능하다
- 스플릿 브레인(Split-brain) 현상: 맴버 간의 연결이 끊어졌을 때 프라이머리 노드가 사용자의 요청을 전부 처리하는 현상
  - MongoDB에서는 이를 방지하기 위해 과반수 이상의 맴버와 통신이 되지 않으면 세컨더리로 강등된다
- 세컨드리 맴버는 다른 세컨드리 맴버로부터 데이터를 동기화 할 수 있는데 이를 체인 레플리케이션이라 한다
- 롤백
  - 프라이머리 맴버에 장애가 발생하면서 동기화를 위해 이미 저장된 데이터를 다시 삭제하는 과정
  - 세컨더리 맴버가 프라이머리로 선출 될 시 기존 프라이머리 데이터의 일관성을 위해 삭제된다
- 복제 아키텍처
  - 복제 로그(OpLog)
    - 프라이머리 맴버는 데이터의 변경을 저장하고, 이 컬렉션의 데이터를 세컨더리 맴버가 재생하여 데이터를 복제하는데 이 때 쓰이는 별도의 컬렉션
    - local 이라 불리는 시스템 데이터베이스에 저장된다
    - 최대 크기는 50GB
  - 초기 동기화
    - 처음 레플리카 셋에 추가되거나 기존 맴버를 재 시작 할 때 발생
    - 단일 스레드로 진행되며 매우 느리다
    - 중간부터 재 시작이 존재하지 않는다.
    - 시작되면 복제 동기화 대상 서버를 변경할 수 없다
  - 실시간 복제
    - 최종 일관성 방식으로 운영된다 → 어느 시점에는 다를 수 있으나 결국에는 같은 데이터를 가짐
    - Cap 컬렉션: 일반 컬렉션과 달리 큐 형태로 저장되어 데이터를 조회하는 작업 역시 큐처럼 동작하는 컬렉션. Cursor Tail이 가능하다
    - 프라이머리 맴버는 모든 맴버의 복제 상태 정보를 가지고 있다
    - 세컨드리 맴버 읽기 일관성
      - 세컨드리 맴버가 OpLog를 멀티스레드로 재생하기 때문에 프라이머리 맴버와 다른 상태를 보여 줄 수 있어 사용자의 읽기 쿼리를 블록킹함
청크(Chunks)
- 각 샤드의 데이터는 작은 조각으로 나뉘어 저장되며, MinKey/MaxKey에 의해 분해된다
- 논리적인 개념으로만 존재하며, 데이터 이동의 기준이 된다
- 인덱스까지 파티셔닝하지 않는다
- 청크 사이즈는 도큐먼트의 크기가 작으면서 전체 컬렉션 용량이 큰 컬렉션을 기준으로 삼는 것을 추천한다
- 청크 밸런싱
- 청크 스플릿
- 청크 머지
- 청크 마이그레이션
샤딩

릴리즈 노트

리눅스에서는 데이터 파일 페이지의 주변 페이지 일부가 캐시에 적재되어 있다면 Read-Ahead 알고리즘에 의해 주변의 데이터도 읽어들여 캐시로 적재한다
대량의 Insert나 분석을 위해서는 페이지 사이즈를 크게 가져가는 것이 좋다