'MongoDB in Action'로 정리해보는 플러그형 스토리지 엔진

MongoDB in Action https://book.naver.com/bookdb/book_detail.nhn?bid=6876243

MongoDB in Action 몽고디비 인 액션

10장 WiredTiger와 플러그형 스토리지 파트를 요약 정리했습니다.

 

---

 

플러그형 스토리지 엔진 API

API

• Application Programming Interface
• 소프트웨어 애플리케이션 프로그램을 작성하기 위한, 상대적으로 엄격한 루틴, 프로토콜 및 도구 세트
• MongoDB 드라이버들은 MongoDB가 제공하는 API를 사용하여 드라이버 기능을 구현한다
• 각 외부 어플리케이션이 MongoDB와 통신하고, DB 내 문서에 대한 CRUD 연산을 수행할 수 있게 함

스토리지 엔진

• 데이터베이스와 하드웨어 간의 인터페이스
  • 쿼리 수행이나, 클러스터 등에 개입하지 않음
• 데이터를 디스크에 기록/수정/삭제하거나 디스크에서 읽어오기, 데이터의 저장되는 자료 구조에 간섭한다
• MongoDB의 기존 스토리지 엔진은 MMAPv1만 있었음
  • 메모리 메핑을 기반으로 하는 MongoDB의 안정적인 솔루션
  • 단점:
    저장할 데이터가 많으면 데이터 세트가 증가하면서 서버 디스크 공간을 너무 빠르게 많이 소비할 가능성
    e.g. 만약 사전 할당되는 블록이 2GB보다 커지면, 그 다음에는 같은 2GB씩 사전 할당된다
  • MMAPv1의 대안이 WiredTiger

왜 또다른 스토리지 엔진이 필요한가?

• 시스템마다 목적이 다르고 필요한 성능이 다르기 때문
• 예를 들어 뉴스 사이트:
  많은 방문객들이 동일한 첫 화면을 보고,
  쿼리 캐시를 활용해 몇 분 전 요청된 동일한 기사를 반복적으로 신속하게 전달할 수 있다
  멤캐시디 또는 Redis 등 외부 메모리 캐시 시스템을 활용해 동일 데이터를 고속 전달할 수 있음
• 그러나 소셜 미디어 사이트, 예를 들어 트위터:
  사용자별로 수백만 건의 트윗/상태 업데이트 및 저장이 가능하도록 높은 쓰기 성능이 필요하고,
  사용자마다 다르게 필터링한 데이터를 읽어서 보여줘야 하므로 더 높은 읽기 성능도 필요하다

WiredTiger

• 멀티 코어 확장성과 최적의 램 사용에 초점을 맞춘, 고성능의 확장 가능한 오픈 소스 데이터 엔진
• 멀티 코어 스케일링(확장)은
  멀티 스레딩 프로그래밍에서 중요한 개념인 hazard pointers, lock-free algorithm 기반이므로
  각 CPU 코어에서 더 많은 작업 수행이 가능하다
  • hazard pointers:
    스레드가 액세스 중인 메모리 블록의 포인터 목록으로
    목록에 있는 포인터 자체나, 그 포인터가 가리키는 메모리 블록을 다른 스레드가 수정/삭제할 수 없다
  • lock-free algorithm:
    여러 스레드가 서로 resource locking 해제를 기다리게 되면서 프로그램이 정지하는 상황을 피하여
    프로그램 전체가 진행되도록 보장하기 위한 프로그래밍 패턴
    • MMAPv1는 컬렉션 이하의 잠금을 제공하지 않는다 (v3.0~)
      WiredTiger는 도큐먼트 수준의 잠금기능을 제공한다
• Key-Value Storage System: 컬렉션의 키를 조회하여 레코드에 대한 빠른 액세스를 보장함, 인덱싱 가능
  • 일반적인 KV 스토리지 시스템에서 데이터 저장에 사용되는 데이터 구조는 B-Tree
  • 디스크 기반 스토리지는 데이터를 '노드' 개념으로 파일 시스템에 블록 단위로 저장함:
    대부분의 FS 기본 블록은 4KB(4096 Byte)
    • 각 노드에 담기는 인덱스 정보는 key 기준으로 정렬되어 있음
    • 한 노드에 담길 수 있는 인덱스 갯수를 초과하면,
      각 값을 경계로 하는 범주의 사이값들로 구성된 자식 노드를 가리키는 포인터를 사이마다 생성한다
• snappy, zlib 압축 기능이 있음
  snappy: 구글에서 개발, 최대한의 압축보다는 합리적 수준의 압축을 고속으로 수행 가능함
• MMAPv1(기존)과의 비교했을 때, 디스크 사용 측면에서 이득이 크다
  • 삽입 성능: 디스크 사용량 차이
  • 압축하지 않은 상태에서 기존의 15% 미만을 사용, 압축 추가되면 10%미만
  • snappy 압축 구성 → 삽입 속도와 디스크 사용 간 중간지점을 찾는다
  • zlib 압축 구성 → 더 많이 압축하지만, 시간은 snappy보다 더 걸린다
  • 읽기 성능:
    cold fetch의 경우 기존보다 훨씬 빠르다: 특히 압축(snappy, zlib) 구성이 더 빠르다
    하지만 캐시를 사용한 읽기 성능은 MMAPv1이 약간 더 빠르다
    • 특히 cold fetch가 오래 걸리면 방문객마다 필터링 조건을 갖는 SNS에서는 cache miss가 발생하므로 중요하다
  • 하지만 특정 운영체제 설정에 따라 성능이 더 향상될 수도, 저하될 수도 있어 환경적 요소도 간과하면 안 됨