[MongoDB] [Study-2-1] Wired Tiger (WT엔진)

[MongoDB] 웨비나 - mongodb 에 대한 8가지 오해

1. 작년 10월 에  MongoDB 웨비나에서 소개된 자료를 정리한 것이 있어서 직접 다시 집중적으로 정리하였습니다.

• 소개

https://www.mongodb.com/presentations/korea-top-misunderstanding-of-mongodb

• 비디오

https://vimeo.com/468475015

• PPT

https://view.highspot.com/viewer/5f882ff5a2e3a96b5627dc39

 

[ WiredTiger Engine ]

 

• 2014 년 Wired Tiger 업체를 인수
• 3.0 에서 MMAPv1 -> WT 으로 변경 진행 (MMAPv1 4.0 이하에서는 사용 가능 / 4.2에서는 제거)\
• 본질적으로 Transaction Storage Engine 이며, Read & Write 에 우수(MMAPv1 은 Insert 에 최적화된 Engine)
• 4.0 에서 부터는 분산 Multi Transaction 을 지원
• 특징
  • WiredTiger에서 압축은 기본 옵션
  • v4.2 부터 총 3개의 압축 옵션을 제공 (snappy, zlib, zstd)
  • 호환성 성능상 아직 이슈가 있어서 snappy 이용
  • 압축률은 zstd(zlib와 대등) 가 더 좋으나, 성능은 snappy 와 zlib 사이로 판단
  • 인덱스는 prefix 압축을 사용
    • 데이터는 WT의 Cache 상태에서는 non 압축 상태 즉, 데이터를 저장 시 Document로 bson 형태로 저장되는데, bson 은 non압축상태로 WT cache 에 존재하며 Disk 와 os file cache 에는 압축 상태로 저장.
    • 만약 find 하는 경우 먼저 cache 의 non 압축 상태에서 먼저 확인 후, Disk 의 압축 상태에서 찾아봐 압축을 해제하며 cache 에 적재
  • prefix 압축이란?
  • 그런데 Index 는 메모리 상 뿐만 아니라 디스크에도 prefix 압축된 상태로 사용(메모리의 효율성을 증대 가능)
  • 삭제된 공간을 재활용 못하기 때문에 Disk size가 무한대로 증가하는 과거 버전과 달리, 현재는 재활용 가능
  • 그래서, collection 에서 사용되지 않는 공간을 확인 가능하며, WT 에서 수동으로 compaction 을 할 수 있음
  • DDL 작업을 제외하고는 4.4 부터 온라인 Compaction 할 수 있음
  • 기존에는 Database level lock 을 잡는것과 달리, 4.4 부터는 CRUD 작업에 대해서는 Lock을 잡지 않음.
  • 그래서 운영간 Primary에서도 가능
  • 초기 버전에는 Global -> Database -> collection Level Lock 을 잡았음 (몇 백개의 Collection이 존재하는 과거 운영)
  • 현재는 Document Level Locking
  • Write no longer block all other writes
  • More CPU cores, instead of faster CPU speeds (하드웨어의 자원을 최대로 사용 가능 - 성능 향상 가능 - 고 사양 서버를 사용 가능하며 유리)
  • Avoid need to "micro-shard"
  • WT에서는 메모리 Cache size , Check point Interval time 등을 조정 가능 (파라메터 튜닝 가능)
1. 압축
2. 온라인 Compaction
3. 향상된 Concurrency
4. 최신 하드웨어 활용
5.  조정 가능한 설정 파라메터
• MMAPv1 와 비교한 레퍼런스 (amadeus , book my show, FaceIT 등의 글로벌 업체)
• 스토리지 공간을 80% 절감
• 최대 5~10 배 향상된 성능

[암호화]

• 3.6 부터 Binding 을 Localhost 가 Default 로 되어 있어서, 설치 시 Localhost 에서만 접속 가능
• 아래 내역들에 대해 Community 와 Enterprise 등 모두 사용 가능

 

[Check Point]

• 스토리지 상의 일관된 데이터 페이지 셋으로, 내구성 / 원자성을 지닌 디스크의 데이터 스냅 샷이라고 정의
• 쉽게 말하면, 데이터를 DML 하는 가운데 메모리 Page상으로 존재하는데, 매 1분 또는 메모리 Dirty 영역이 일정 임계치 이상이 되는 경우 해당 Page들을 Disk로 저장

 

[Journaling]

• 체크 포인트 간의 발생하는 모든 데이터 수정 사항을 신속하게 유지할 수 있는 write-ahead 로그 (journal)
• write-ahead 로그 : 디스크에 쓰기 전에 한번 더 별도의 공간에 저장 (파일시스템 내에 저널파일이-100mb 단위/ 존재하며 체크 포인트 발생하면 모두 삭제 됨)
• 데이터 뿐만 아니라 인덱스 에서 발생하는 로그들 모두 기록
• 저널링 버퍼가 존재하는데, 저널링 버퍼에서 저널링 파일로 저장되는 시간이 1oms  (10ms 의 유실 가능성 존재)
• 체크 포인트 간에 장애가 발생하면 저널을 사용하여 마지막 체크 포인트 이후 수정 된 모든 데이터를 적용

＊ Journaling 없이도 MongoDB는 손실 없이 마지막 체크 포인트로 복구 가능하나, 마지막 체크 포인트 이후의 변경 사항을 복구하려면 저널링을 활성화해야 가능

 

[Write Concerns]

• Write 작업을 위해 MongoDB cluster에서 Client Application Ack 요청을 제어
• Write 작업을 할때 Primary 에 적용 하고 응답을 받고 Session 을 종료 할 것인지, Secondary 까지 적용이 완료 된 후 응답을 받아 종료를 할것인지, Primary 에서 조차도 응답을 안받고 작업을 종료 할 것인지에 대한 Level 제어
• 또한 wtimeout 을 적용하여 해당 시간 보다 오래 소요되는 경우 Error return (단위 ms)
• Write Concern Option
• 1 : Written to Primary - Default
• 2 : written to Primary and at least one Secondary
• majority : Written to majority of nodes
• ex) 과반수 노드가 write 된 후에 ack 를 달라고 하는데, 단 5초 이상 소요 시 error return
• db.products.insert({name : "Louis.Kim"}, {writeConcern:{w:"majority", wtimeout:5000}})

[Multi-Document Distributed ACID Transactions]

• Single/ Multi Document, Shard  등 Transaction 지원
• RDBMS와 동일한 형태
  • Transaction Default Timeout 60초
• 다중 구문, 유사한 문법
• 어플리케이션에 쉽게 추가 가능
• 여러 컬렉션에 대한 다중 구문 트랜잭션
• ACID 보장
• All or nothing execution
• Snaphost isolaction ( Serializable Snapshot Isolaction의 공동 발명자인 Michael Cahill 포함한 Wired Tiger 회사 인수-와 연관 )

Causal Consistency