[mongoDB] WiredTiger 스토리지 엔진

• 1) 플러그인 스토리지 엔진
  • 스토리지 엔진 특성 비교
• 2) 스토리지 엔진 혼합 사용
• 3) WiredTiger 스토리지 엔진
• 4) WiredTiger 스토리지의 저장 방식
• 5) 데이터 파일 구조
• 6) WiredTiger의 내부 작동 방식
  • 공유 캐시
  • 하자드 포인터(Hazard Pointer)
  • 스킵 리스트(Skip-List)
  • 캐시 이빅션(Cache Eviction)
  • Checkpoint
  • MVCC
  • 데이터 블록(페이지)
  • 운영체제 캐시(페이지 캐시)
  • 압축
  • 암호화
• 참고자료

 

---

 

1) 플러그인 스토리지 엔진

클라이언트 드라이버 (Java, Python, C/C++, Go, Spark, OGG ... )

↕ 네트워크 프로토콜 (Wire Protocol)

쿼리 처리기, 샤드 관리자, 보안 관리자, 레플리케이션 매니저

스토리지 엔진 API (Storage Engine)

MMAPv1, WiredTiger(memory, encrypted로 이뤄짐), RocksDB

[MongoDB 아키텍처]

가장 하위에 위치한 MMAv1, WiredTiger 등을 스토리지 엔진이라고 한다. 스토리지 엔진은 사용자의 데이터를 디스크에 영구적으로 기록하거나 다시 읽어와서 메모리에 적재하는 역할을 담당한다.

사용자가 데이터를 저장하거나 조회하면 MongoDB 서버는 그 쿼리를 분석해서 어떻게 처리하면 효율적인지 판단한다. 이를 옵티마이저라고 부르는 컴포넌트가 처리를 담당한다.

옵티마이저의 가장 중요한 역할은 최적화된 실행 계획을 수립하는 것이다. 옵티마이저가 실행 계획을 수립하면 실제 그 실행 계획에 맞게 디스크에서 데이터를 읽어오고 저장하는 작업을 해야 한다. 이때 디스크에서 데이터를 어떻게 가져오고 어떻게 최적으로 저장할 것인지 결정하는 부분이 스토리지 엔진이다.

즉, MongoDB 서버가 사람의 머리 역할을 한다면, 각 스토리지 엔진은 손과 발의 역할을 맡은 형태다.

MMAPv1 스토리지 엔진은 MongoDB가 처음 출시됐을 떄부터 사용되던 스토리지 엔진이며, WiredTiger 스토리지 엔진은 MongoDB 3.0부터 도입된 새로운 스토리지 엔진이다. In-Memory 스토리지 엔진은 WiredTiger 스토리지 엔진의 변형으로, 데이터를 디스크에 기록하지 않고 메모리에만 보관하는 스토리지 엔진이다. RocksDB 스토리지 엔진은 페이스북에서 levelDB를 커스터마이징하여 개선한 스토리지 엔진이며, TokuDB는 Percona에서 개발 중인 스토리지 엔진이다.

스토리지 엔진 특성 비교

기능MMAPv1WiredTigerRocksDBTokuDB

잠금 수준(lock-level)	컬렉션	도큐먼트	도큐먼트	도큐먼트
데이터 구조	B-Tree	B-Tree	LSM	Fractal-Tree
빌트인 캐시	X (운영체제 캐시)	O	O	O
세컨드리 인덱스	O	O	O	O
데이터 압축	X	O	O	O
인덱스 압축	X	O	O	O
암호화	X	O	X	X
In-Memory 지원	X	O	X	X
컬렉션 파티션	X	X	X	O

• MongoDB와 같이 자동으로 샤딩되고 분산되는 DBMS에서 파티션 기능은 불필요한 기능이라고 생각할 수도 있지만, MongoDB 서버에서도 오래된 데이터를 빠르게 삭제하거나 데이터의 접근을 특정 영역으로 제한할 때에는 여전히 파티션 기능이 필요하다.
• MMAPv1 스토리지 엔진이나 WiredTiger 스토리지 엔진을 사용할 때, 데이터베이스 단위로 디스크의 파티션을 다르게 할당하는 방법은 아직(MongoDB 3.4) 없다. 디스크 파티션을 분리하고자 한다면 컬렉션을 데이터베이스 단위로 구분하고 각 데이터베이스 디렉터리를 리눅스의 심볼릭 링크로 연결시키면 디스크의 여러 파티션을 동시에 사용할 수 있도록 구현할 수 있다.

 

2) 스토리지 엔진 혼합 사용

하나의 MongoDB 서버(인스턴스)에서 동시에 여러 스토리지 엔진을 사용할 수는 없다. 하지만 인스턴스만 다르면 스토리지 엔진을 선택하는 데 있어서 다른 제약은 없다.

• 또한 하나의 레플리카 셋에서 프라이머리 멤버는 WiredTiger 스토리지 엔진을 사용하고, 세컨드리(프라이머리 페일 오버용) 멤버에서는 RocksDB를 사용하는 것도 가능하다.
• 레플리카 셋의 모든 멤버가 셧다운되는 경우에도 데이터 복구가 필요하다면 레플리카 셋의 일부 멤버는 디스크 기반의 스토리지 엔진을 적용하는 구성이 도움이 될 수도 있다.
• 일부 샤드는 RocksDB로 구성하고, 일부 샤드는 WiredTiger 스토리지 엔진을 사용할 수도 있다. 각 샤드가 저장하는 데이터가 다르거나 용도가 다른 경우에는 각 샤드를 다른 스토리지 엔진으로 구성해서 각각의 데이터 특성에 맞게 스토리지 엔진을 선택할 수도 있다.

 

3) WiredTiger 스토리지 엔진

WiredTiger 는 berkeley DB 개발자들에 의해서 개발된 임베디드 데이터베이스 엔진으로 MongoDB의 디폴트 스토리지 엔진으로 도입됐다. MMAPv1 스토리지 엔진의 문제점을 해결하기 위해서 WiredTiger 를 인수하고 MongoDB 서버의 스토리지 엔진으로 내장한 것이다.

특징

• 내부적인 잠금 경합 최소화(Lock-free Algorithm)를 위해서 "하자드 포인터(Hazard-Pointer)"나 "스킵 리스트(Skip-List)" 와 같은 많은 신기술을 채택하고 있다.
• 최신 RDBMS 서버들이 가지고 있는 MVCC(잠금 없는 데이터 읽기)와
• 데이터 파일 압축
• 암호화 기능

을 모두 가지고 있다.

MongoDB 서버는 WiredTiger 스토리지 엔진을 내장함으로써 단번에 상용 RDBMS 가 가지고 있는 고급 기능들을 모두 지원할 수 있게 되었다.

 

4) WiredTiger 스토리지의 저장 방식

3가지 타입의 저장소를 가지고 있다.

1. 레코드(row, record) 스토어
   1. 일반적인 RDBMS 가 사용하는 저장 방식
   2. 테이블의 레코드를 한꺼번에 같이 저장하는 방식
   3. 다양한 서비스 패턴에 적절하게 대응할 수 있는 구조
   4. 기본적으로 B-TREE 알고리즘
2. 컬럼 스토어
   1. 대용량의 분석(OLAP이나 Data WareHouse) 용도로 사용됨
   2. 테이블의 레코드와 상관없이 각 컬럼 단위 또는 컬럼의 그룹 단위(컬럼 패밀리 또는 컬럼 그룹)로 데이터 파일을 관리
   3. 특정 컬럼 단위로 데이터 파일을 생성하므로 데이터 파일 크기가 작아짐
   4. 테이블의 전체 데이터를 읽어 들이는 속도도 매우 빨라서 대용량 분석에 적합한 방식이다.
3. LSM(Log Structured Merge Tree) 스토어
   1. HBase 나 카산드라와 같은 NoSQL 데이터베이스에서 자주 사용하는 저장 방식
   2. 읽기 보다는 쓰기 능력에 집중한 저장 방식
   3. 내부적으로 B-Tree 알고리즘을 사용하지 않고, 순차 파일 형태로 데이터를 저장
   4. 순차 파일들이 시간 순서대로 1개 이상이 관리되는 방식
   5. 메모리에 저장 가능한 크기의 조각(Memtable)으로 데이터 파일을 관리하는데, 데이터가 계속 저장되면서 메모리에 저장 가능한 한계를 넘어서면 이를 디스크에 저장한다.
   6. 디스크로 갓 저장된 파일은 Level-0. level-0이 많아지면 모아서 level-1 데이터 파일 조각을 만든다.
   7. 이렇게 로그처럼 계속해서 기록되는 파일들을 병합하여 level-n까지의 데이터 파일로 계속 성장하는 방식으로 작동하므로 이를 로그 기반의 병합트리(LogStructured Merge Tree)라고 부른다.
   8. 일반적으로 LSM-Tree에서는 레벨이 낮을 수록 최신 데이터, 레벨이 높을수록 오래된 데이터이다.
   9. 그런데 일반적으로 응용 프로그램에서는 최신의 데이터를 자주 참조하기 때문에 레벨이 낮은 최근의 데이터 파일이 크기도 작고 메모리에 상주할 가능성이 크며, 레벨이 높은 데이터 파일일수록 데이터 파일의 크기가 크고 오래된 데이터로 구성되므로 잘 참조되지 않아서 디스크에만 상주할 가능성이 크다.
   10. LSM-Tree 는 조각 파일 단위로 인덱스를 가진다. 데이터 파일을 구성하는 각 블록(페이지) 단위로 키를 샘플링하여 바이너리 트리를 사용.

 

LSM-Tree가 도입된 이유

서비스의패턴이 변경되면서 대용량의 INSERT를 문제없이 처리할 수 있는 솔루션이 필요해졌다.

기존 데이터 크기와 관계없이 거의 동일한 수준의 INSERT 성능을 보장함.

B-Tree는 레코드가 저장될 때마다 B-Tree를 유지해야 하는 비용이 필요하고, 갈 수록 트리가 커지기 때문에 INSERT 성능이 기존 데이터가 크면 클 수록 저장 비용이 더 커지게 되는 구조다. 하지만 LSM-Tree는 새로운 데이터는 메모리에 저장하고, 메모리에 저장된 데이터가 충분히 커지면 이 데이터 파일만 메모리에서 디스크로 저장하면 된다.

 

하지만 데이터를 읽어야 하는 경우에는 매우 심각한 문제가 발생. N개의 데이터 조각이 각각의 파일로 관리된다. 그래서 데이터 하나를 검색하려면 N개의 데이터 파일을 모두 검색해야만 원하는 데이터를 찾을 수 있다.

즉, B-Tree 알고리즘에서는 데이터 파일이 하나이며, 이 하나의 트리만 검색하면 되는데, LSM-Tree 에서는 N개의 데이터 파일을 더 느린 속도로 검색하게 되는 것이다. 그래서 LSM-Tree에서는 검색해야 하는 데이터 파일의 개수를 최소화하기 위해서 계속해서 백그라운드로 조각화된 데이터 파일들을 병합하는 작업(컴팩션)을 실행해야 한다.

문제는 이 백그라운드 병합 작업은 한 번에 매우 많은 디스크와 CPU 자원을 필요로 하는데, 이 작업으로 인해서 사용자의 데이터 저장이나 읽기 속도는 많은 영향을 받게 된다.

 

LSM-Tree는 읽기 성능을 포기하고 그만큼의 저장 성능을 향상시킨 솔루션인 것이다. 쿼리 성능도 B-Tree보다 아주 느린 편이라 보완하기 위해 내부적으로 "블룸 필터(Bloom Filter)"와 같은 기능을 가지고 있다.

 

WiredTiger 스토리지 엔진은 이렇게 3가지의 저장 방식을 가지고 있는데 아직 MongoDB에 내장된 WiredTiger 스토리지 엔진에서는 레코드 기반의 저장소만 사용되고 있다.

 

5) 데이터 파일 구조

WiredTigerLAS.wt

• WiredTiger 스토리지 엔진의 캐시에서 재활용할 수 있는 공간이 부족하면 이빅션 서버(Eviction server thread)는 필요한 만큼의 여유 공간을 만들어야 사용자 요청 쿼리를 원활하게 처리할 수 있다.
• 그런데 캐시에서 제거해야 하는 데이터 페이지들이 더티 페이지 상태(Dirty page)여서 디스크에 기록해야 할 때 필요하다면 임시로 WiredTigerLAS.wt 데이터 파일을 사용하게 된다.
• 이렇게 임시로 기록된 더티 페이지는 나중에 다시 원래 데이터 파일로 기록되거나 쿼리를 처리할 떄 다시 캐시로 읽어와야 하는데, 이런 특성 때문에 이 컬렉션 이름이 Look Aside Table(LAS Table)이라고 붙여진 것이다.

...

6) WiredTiger의 내부 작동 방식

트랜잭션을 지원하는 대부분의 RDBMS와 거의 흡사한 내부 구조로 되어 있다. MongoDB 서버가 트랜잭션을 지원하지 않기 때문에 일반적으로 WiredTiger 스토리지 엔진도 트랜잭션을 지원하지 않는 단순한 저장소 개념으로 생각할 수 있지만, MongoDB 에 인수되기 이전부터 트랜잭션을 지원하는 임베디드 데이터베이스 엔진으로 사용되고 있었으며 MySQL 서버의 InnoDB 스토리지 엔진과 같이 RDBMS 데이터 처리용 스토리지 엔진으로 개발되었다. p.67

• B-Tree 구조의 데이터 파일
• 서버 크래시(비정상 종료)로부터 데이터를 복구하기 위한 저널 로그(WAL, Write Ahead Log)를 가지고 있다.
  • 데이터 디렉터리 하위에 있는 journal 이라는 디렉터리에 저장되며, 다른 RDBMS의 redo 로그(WAL)처럼 로테이션되면서 로그 파일의 로그 슬롯이 재활용되는 방식이 아니라 새로운 로그 파일이 계속 생성된다.
  • 체크포인트 시점 이전의 저널 로그는 더 이상 필요하지 않으므로 체크포인트 이후 시점의 저널 로그만 남기고 이전 저널 로그는 자동으로 삭제한다.
• 내장된 공유 캐시(버퍼 풀)를 가지고 있다. 디스크의 인덱스나 데이터 파일을 메모리에 캐시하여 빠르게 쿼리를 처리 & 데이터의 변경을 모아서 한번에 디스크로 기록하는 쓰기 배치 기능을 가짐.
• 블록 매니저(Block Manager)를 통해서 필요한 데이터 블록을 디스크에서 읽어서 공유 캐시에 적재하여 쿼리를 처리한다.
  • 도큐먼트 변경 내용은 먼저 공유 캐시에 적용되는데, 변경된 데이터가 디스크에 기록되는 과정을 기다리지 않고 변경 내용을 저널 로그에 기록한 다음 사용자에게 작업 처리 결과를 리턴한다. 기본적으로 사용자에게 작업 처리 결과를 반환하는 시점은 저널 로그의 기록이 완료되는 시점이다.
  • 변경되니 데이터 블록을 기록할 때, 프레그멘테이션을 최소화하면서 기록되는 데이터 블록의 크기에 최적인 위치를 찾아서 저장하는 역할을 담당한다. && 데이터 블록의 압축과 암호화 등과 같이 응용 프로그램에 투명하게 작동하는 기능을 모두 내장하고 있다.
• 메모리의 더티 페이지는 디스크에 기록하기 전에 가공 작업을 거치는데 이를 리컨실리에이션(Reconciliation) 모듈이 담당한다.
  • 공유 캐시에서 자주 사용되지 않는 데이터 페이지를 제거하는 작업을 수행할 때 만약 더티 페이지라면 리컨실리에이션 모듈을 이용해 디스크에 데이터를 기록하고, 공유 캐시에서 제거한다. 이런 과정 중에서 어느 한 곳이라도 처리가 느려지거나 문제가 생기면 쿼리의 처리가 느려지게 된다.
• 데이터 블록은 모두 가변 사이즈다. 압축 기능을 구현하기가 어렵다.

 

공유 캐시

WiredTiger 스토리지 엔진에서 사용자의 쿼리는 공유 캐시를 거치지 않고 처리할 수 없으며, 때로는 하나의 쿼리를 처리하기 위해 수천에서 수만 번 공유 캐시의 데이터 페이지를 참조해야 할 수도 있다. 그래서 공유 캐시의 최적와는 MongoDB의 처리 성능에 있어서 매우 중요한 역할을 담당한다.

 

하자드 포인터(Hazard Pointer)

"사용자 쓰레드"는 사용자의 쿼리를 처리하기 위해서 WiredTiger 캐시를 참조하는 쓰레드이며, "이빅션 쓰레드(Eviction Thread)"는 캐시가 다른 데이터 페이지를 읽어 들일 수 있도록 빈 공간을 만들어주는 역할을 담당하는 쓰레드다.

WiredTiger 스토리지 엔진의 모든 "사용자 쓰레드"는 WiredTiger 캐시의 데이터 페이지를 참조할 때, 먼저 하자드 포인터에 자신이 참조하는 페이지를 등록한다. 그리고 '사용자 쓰레드'가 쿼리를 처리하는 동안 '이빅션 쓰레드'는 동시에 캐시에서 제거해야 할 데이터 페이지를 골라서 캐시에서 삭제하는 작업을 실행하게 된다. 이때 '이빅션 쓰레드'는 적절히 제거해도 될 만한 페이지(자주 사용되지 않는 페이지)를 골라서 먼저 하자드 포인터에 등록돼 있는지 확인한다. 하자드 포인터에 등록돼 있으면 그 페이지는 무시하고 하자드 포인터에 등록되지 않는 페이지만 캐시에서 제거한다.

이런 기술 덕분에 WiredTiger 스토리지 엔진의 다양한 쓰레드들이 캐시의 데이터 페이지들에 대해서 잠금 대기 없이 각자의 임무를 수행할 수 있다.

 

스킵 리스트(Skip-List)

Lock-Free 를 구현하기 위한 또 다른 기술이 스킵 리스트 자료 구조이다.

• 평균 검색 성능 B-Tree 와 같은 log(n)
• 구현이 간단하고 메모리 공간도 많이 필요하지 않는다.
• 새로운 노드를 추가하기 위해 별도의 잠금을 필요로 하지 않는다.
• 검색 또한 별도의 잠금을 필요로 하지 않는다.
• 노드 삭제는 잠금을 필요로 하지만, B-Tree 자료 구조 보다는 잠금을 덜 필요로 하므로 큰 성능 저하 이슈는 아니다.
• 그래서 여러 쓰레드가 동시에 하나의 스킵 리스트에 노드를 저장하거나 검색한다고 하더라도 서로 전혀 잠금 경합을 하지 않는다.
• 언두 로그를 스킵 리스트로 관리한다.
  • 언두 로그를 관리하는 이유는 롤백될 때 기존 데이터를 복구하기 위함임. RDBMS 에서는 언두 로그를 잠금 없는 데이터 읽기(MVCC) 용도로도 같이 사용한다.
  • 공유 캐시의 변경 이력(언두 로그)가 어떻게 관리되는지 살펴보자.
  • 데이터가 변경되면 변경된 내용을 스킵 리스트에 차곡차곡 기록해둔다. 그리고 사용자 쿼리가 데이터를 읽을 때에는 변경 이력이 저장된 스킵 리스트를 검색해서 원하는 시점의 데이터를 가져간다. 이렇게 변경된 내용을 직접 데이터 페이지에 덮어쓰지 않고 별도의 리스트로 관리되는 이유는 쓰기 처리를 빠르게 하기 위함이다.
  • 변경되는 내용을 스킵 리스트에 추가하기만 하면 된다.
  • 여러 쓰레드가 하나의 페이지를 동시에 읽거나 쓸 수 있어서 동시 처리 성능이 매우 향상된다.

 

캐시 이빅션(Cache Eviction)

WiredTiger 스토리지 엔진의 공유 캐시를 사용하는데 있어, 새로운 디스크 데이터 페이지를 읽어서 공유 캐시에 적재할 수 있도록 빈 공간을 항상 적절히 유지해야 하는데, 이렇게 빈 공간을 유지하기 위해 WiredTiger 스토리지 엔진은 이빅션 모듈을 가지고 있으며, 이를 “이빅션 서버(Eviction Server)”라고도 부른다.

이빅션 서버는 백그라운드 쓰레드로 실행되는데 공유 캐시에 적재된 데이터 페이지 중에서 자주 사용되지 않는 데이터 페이지 위주로 공유 캐시에서 제거하는 작업을 한다. 이 과정에서 공유 캐시 스캔이 빈번히 발생하며 B-Tree의 브랜치 노드는 자주 접근되는 비율에 관계없이 공유 캐시에 유지하려는 경향이 있다. 이전에는 SSD를 사용해도 이빅션이 데이터 페이지의 읽기 성능을 따라가지 못해서 캐시가 가득차는 경우가 발생했는데, 이러한 현상은 버전업이 되면서 점차 나아졌고 현재는 MongoDB에서 SSD를 사용하는 것이 최적의 저장매체로 사용을 권장하고 있다.

 

Checkpoint

체크포인트는 모든 데이터베이스에 존재하는 개념으로 데이터 파일과 트랜잭션 로그가 동기화 되는 시점을 의미하며, WiredTiger 엔진은 버전 3.6부터 MongoDB는 60초 간격으로 체크포인트를 생성(스냅샷 데이터를 디스크에 기록)한다. 사용자 데이터에 대해 60초 간격으로 또는 2GB의 저널 데이터가 기록된 경우 중 먼저 발생하는 체크포인트를 생성한다. 사용자 요청을 빠르게 처리하면서 커밋된 트랜잭션의 영속성을 보장하기 위해서 트랜잭션 로그(WAL, Write Ahead Log = 저널로그)를 먼저 기록하고, 데이터 파일에 기록하는 것은 트랜잭션에 상관없이 뒤로 미뤄 작업 한다.

체크포인트는 DBMS가 서버가 크래시되거나 재구동 되었을때, 복구를 시작할 시점을 결정하는 기준이 된다. 체크포인트의 간격이 길면 복구 시간이 길어지게 되고, 또 반대로 너무 짧으면 쿼리를 처리하는 성능이 떨어지게 된다. Oracle이나 MySQL의 INNODB가 Fuzzy 방식의 체크포인트를 사용하는 것과는 다르게 MongoDB의 WiredTiger 스토리지 엔진은 Sharp 체크포인트 방식을 사용한다. 평상시에는 디스크 쓰기가 없지만, 체크포인트가 실행되는 시점에 한 번에 모아서 더티 페이지를 기록하는 방식이다.

WiredTiger의 체크포인트는 절대 기존의 B-Tree 구조를 덮어 쓰지 않는다. 새로운 leaf 페이지가 추가될때 새로운 공간을 할당 받고, 새로운 브랜치 노드가 구성되면 root 노드를 삭제하지 않고 새로운 브랜치 노드가 기존 leaf부터 새로 생성된 leaf를 바라보는 B-Tree 구조가 생성되며, 만약 사용하지 않는 leaf가 있다면 해당 부분은 쳐내고 전체적으로 다시 B-Tree 구조를 완성한다. 새로운 B-Tree구조가 완성되면 기존의 B-Tree를 삭제하고 사용하던 공간을 반납한다.

 

MVCC

WiredTiger 스토리지 엔진은 세가지의 격리 수준을 제공하는데,

• REPEATABLE-READ
• READ_COMMITTED
• SNAPSHOT

SNAPSHOT 수준의 격리 수준을 기본으로 선택하고 있다.

WiredTiger 스토리지 엔진의 SNAPSHOT 격리 수준은 REPEATABLE-READ와 동일한 수준이다. 예전 3.x 버전에서는 트랜잭션을 엄격하게 유지하지는 않았지만, 4버전 부터는 RDBMS 수준의 트랜잭션을 지원한다.

 

데이터 블록(페이지)

WiredTiger 스토리지 엔진은 고정된 크기의 블록을 사용하지 않는다. 하지만 하나의 페이지가 너무 커지는 것을 방지하기 위해 최대 크기에 대해서는 제한을 두고 있다. B-Tree의 브랜치 노드와 leaf 노드의 페이지 크기를 다르게 설정할 수 있으며, 또 컬렉션 별로, 인덱스 별로 다르게 설정할 수도 있다.

하지만 컬렉션 별로 미세하게 설정을 변경하게 되면 관리의 어려움이 생기고 운영 비용을 높이는 결과를 가져올 수도 있다.

분석이나 대량의 Insert 작업이 많다면 페이지를 크게, 소규모의 데이터에 Random access가 잦고 빈번하게 Update가 발생한다면 가능한 페이지 크기를 작게 설정하는 것이 좋다.

 

운영체제 캐시(페이지 캐시)

WiredTiger 스토리지 엔진은 Cached IO를 기본 옵션으로 사용하고 있다.

WiredTiger 스토리지 엔진이 참조하고자 하는 데이터 페이지는 리눅스 페이지 캐시에 있는 데이터를 다시 자신의 공유 캐시에 복사하는 것이다. OS의 페이지 캐시에도 있고, WiredTiger 스토리지 엔진에도 같은 데이터가 있는데 이것을 더블 버퍼링이라고 하며, RDBMS에서는 이러한 더블 버퍼링 문제를 해결하기 위해 Direct IO 방식을 주로 사용한다. Cached IO를 사용하는 경우 리눅스 서버가 디스크 데이터 쓰기를 전담해서 처리한다. 이때 페이지 캐시 처리에서 가끔식 문제를 발생하기도 하지만, 성능적인 부분에서는 Cached IO가 Direct IO보다 빠른 속도를 보여줍니다.

 

압축

WiredTiger 스토리지 엔진의 가장 큰 장점 중 하나는 압축 기능이다. RDBMS와 비교 했을때 크게 3가지 장점이 있다.

• 가변 사이즈의 페이지 사용: 페이지가 가변 사이즈이기 때문에 압축 결과를 그대로 디스크에 기록하기때문에 RDBMS들처럼 페이지를 스플릿하여 여러번 압축하는 과정을 가질 필요가 없다.
• 데이터 입출력 레이어에서의 압축지원: WiredTiger의 블록 매니저가 디스크 데이터 페이지를 읽어오면서 공유 캐시에 적재할 때 압축을 해지한 상태에서 적재하고, 공유 캐시에서 디스크로 기록되는 페이지에 대해서만 압축을 실행해서 저장한다.
• 다양한 압축 알고리즘 지원: 4.2버전부터 Zstd를 지원하지 시작했으며, zlib과 Snappy를 지원하고 있다. 압축률이 높을수록 공간 절약이 되지만 압축하고 해제할 때 속도는 성능에 영향을 미친다.

	압축률	압축속도 (MB/sec)	압축해제 속도 (MB/sec)
zstd	2.9	330	940
zlib	2.7	95	360
Snappy	2.1	480	1600

WiredTiger 스토리지 엔진에서는 압축 알고리즘 뿐만 아니라 컬렉션과 인덱스 그리고 저널로그에 대해서 각각 압축을 적용할 것인지 결정할 수 있다. 저널 로그와 데이터 파일은 Snappy로, 인덱스는 Prefix 압축을 적용해서 많이 사용한다. Prefix 압축이란 인덱스 키에서 왼쪽 부분의 중복 영역을 생략하는 압축 방식이다. 프리픽스 압축은 블록 압축과 다르게 공유 캐시에 적재된 상태에서도 압축상태를 유지한다. 프리픽스 압축은 데이터를 읽을 때, 항상 완전한 키 값을 얻기 위해서 조립과정을 거치는데, 페이지 첫번째에 있는 인덱스 키부터 재조립 과정을 거치게 되면 효율이 떨어지기도 한다. 압축률이 좋으면 인덱스를 읽는 속도가 떨어질수도 있고, 인덱스를 역순으로 읽을때는 더 심해진다.

 

암호화

엔터프라이즈 버전에서만 암호화 기능을 사용할 수 있는데, 커뮤니티 버전의 소스 코드에도 암호화 처리를 위한 인터페이스가 그대로 남아 있기 때문에 간단한게 플러그인 형태의 모듈을 개발한다면 커뮤니티 버전에서도 데이터 암호화 기능을 사용할 수 있다.

 

---

참고자료

rastalion.me

RealMongoDB