[NoSQL] Document, MongoDB

Collection안에 존재하는 (RDB의 카탈로그DB) Document(RDB의 테이블)는 JSON과 유사형식의 구조이다.

스키마 구조가 정해져있지 않고 유동적으로 변경하여 사용할 수 있음.

 

 

몽고DB

 

4.0 버전부터 다중 문서 트랜잭션 기능 제공

4.2 버전부터 분산 트랜잭션 도입.

 

3.0 버전의 MONGOB 아키텍처 현재는 MMAP V1은 지원 X (https://www.mongodb.com/blog/post/whats-new-mongodb-30-part-3-performance-efficiency-gains-new-storage-architecture)

 

WiredTiger 스토리지 엔진

dbpath : 데이터 파일이 저장되는 경로.
journal : 서버의 저널로그(=트랜잭션 로그) 활성화 여부 결정.
WiredTiger 엔진은 3가지 타입의 저장소를 가지고 있음.
레코드 스토어 : 일반적인 RMDS가 저장하는 방식. B-Tree 알고리즘 사용(몽고에서 사용하는 방식).
컬럼 스토어 : 대용량 분석 용도로 사용. 데이터 파일의 크기가 작고 속도가 빨라 대용량 분석에 적합.
LSM(Log Structured Merge Tree) 스토어 : NoSQL에서 가장 자주 사용하는 저장방식. write에 집중한 방식으로 b-tree가 아닌 순차 파일 형태로 데이터 저장.

B-TREE 구조의 데이터 파일과 데이터 복구를 위한 저널로그를 가지고 있음. 새로운 로그 파일을 생성하고 지난 사용하지 않는 파일은 자동으로 삭제하는 방식.
공유캐시 : WiredTiger 엔진은 내부에서 캐시를 사용. 디스크의 데이터 페이지가 캐시로 공유될 때 메모리에 적합한 트리 형태로 재구성되어 별도의 맵핑 없이 메모리 주소를 이용해 바로 검색 가눙.
Hazrad Pointer : WiredTiger에서 필요 없어진 캐시를 삭제하는 방식
Skip-List : RDMS의 Undo와 비슷한 역할. 다만 데이터 페이지의 레코드를 직접 변경하지 않고 변경된 데이터를 skip-list에 추가. 사용자는 쿼리가 데이터를 읽을 때 변경 이력이 저장된 skip-list를 검색해서 원하는 시점의 데이터를 읽음 → 쓰기 작업의 처리 속도를 높여서 동시 처리 성능을 향상
Checkpoint : 3.6 버전부터 60초 간격으로 체크포인트 생성. 
데이터 블록(페이지) : WiredTiger는 고정된 크기의 페이지를 사용하지 않지만 최대 크기에 대해서는 제한이 있음.

Aggregation
pipeline과 Map-Reduce 방식이 있는데 주로 pipeline 방식으로 사용된다.

pipeline : 이전 단계의 연산 결과를 다음 단계에 이용하는 것

https://docs.mongodb.com/manual/aggregation/

 

Replication

OpLog(Operation Log) : MongoDB의 복제를 위해서 만 사용. 컬렉션의 레코드 형태로 저장.
MongoDB는 Secondary(구독)가 Primary(게시)에서 OpLog를 가져와 재생하여 데이터를 동기화 함.
OpLog 구조
Local 데이터베이스에 oplog.rs 컬렉션에 기록
ts(Timestamp) : 동기화를 잠시 중단하거나 재시작할 때 기준.
t(Primary Term) : 복제 셋의 Primary 선출하는 투표가 실행 시 증가.
h(Hash): OpLog의 도큐먼트는 Primary 멤버에서 실행된 데이터 변경작업을 의미, 각각의 작업에는 OpLog의 해시 값을 이용해서 식별자가 할당되는데 이 식별자를 h 필드에 저장.
v(Version): 도큐먼트의 버전을 의미.
op(Operation Type): i(Insert),d(Delete),u(Update),c(Command),n(No Operation) 등 오퍼레이션 종류를 저장. n은 단순 정보 저장.
ns(Namespace): 데이터가 변경된 컬렉션의 네임스페이스가 저장.
o(Operation): op필드에 저장된 오퍼레이션 타입별로 실제 변경된 정보가 저장
o2(Operation 2): op필드가 u인 경우에만 o2 필드가 존재. 업데이트 될 대상 도큐먼트의 _id 정보를 저장.
MongoDB는 Primary가 죽었을 때 Secondary에서 자동으로 하나가 Primary로 선출됨 이 과정을 투표라 함.
복제지연 : 복제하는데 걸리는 시간. 4.2 버전부터 지연 시간 제한 가능
아비터서버 : 감시용 서버로 문제가 생긴 서버를 대신해서 primary 동작할 서버를 지정하는 서버

 

 

PSS 구조

https://docs.mongodb.com/manual/core/replica-set-architecture-three-members/

하나의 Primary와 여러 개의 Secondary로 이루어진 Replica Set
Primary가 죽을 경우 투표를 통해 남은 Secondary 중 새로운 Primary를 선출한다.
만약 Secondary가 하나만 남았다면 새로운 Primary를 선출할 수 없어 서버 장애가 발생

 

 

PSA 구조

https://docs.mongodb.com/manual/core/replica-set-architecture-three-members/

하나의 Primary와 Arbiter 그리고 여러 개의 Secondary로 이루어진 Replica Set
Primary가 죽은 경우 Arbiter가 Secondary와 함께 투표해서 Secondary 중 새로운 Primary를 선출한다.
P-S-A 시스템에선 Secondary가 하나만 남았더라도 Arbiter가 남아있어서 남은 Secondary를 Primary로 선출 할 수 있어서 정상적으로 서비스가 동작