All Articles

MongoDB Configuration Compressor 무엇으로 하면 좋을까?

MongoDB index configuration

Compressor 에 대해 알아보자

어느 DB를 다루든 늘 성능은 예민한 문제이다. 먼저 쿼리 튜닝을 포함해 다양한 방법이 있지만, 그에 앞서 필요한 설정을 해두고 쿼리 튜닝을 한다면 더욱 효과적인 성능을 기대할 수 있지 않을까?

config 파일에 보면

storage.wiredTiger.engineConfig.journalCompressor
storage.wiredTiger.collectionConfig.blockCompressor

라는 부분에서 내가 필요한 방식으로 index와 collection 압축을 선택할 수 있다. 이런 부분에서 압축을 선택하는 목적은 CPU에 효율을 가져오기 위해서 이다.

storage.wiredTiger.collectionConfig.blockCompressor

collection 의 데이터를 기본으로 압축하는 타입을 결정한다

선택 가능한 값으로는

  • none
  • snappy
  • zlib
  • zstd (MongoDB 4.2 부터 가능)

4가지 옵션이 있다. 이 옵션으로 압축을 선택하면 collection 의 모든 데이터에 압축을 결정할 수 있다.

만약 이미 live 인 상태에서 이 옵션을 수정하게 된다면, 기존에 저장 된 데이터는 기존 압축 방법대로 저장되어 있으며, 새로 저장하는 데이터는 변경된 옵션의 압축 방식을 적용받게 된다.

1. none

말 그대로 압축을 하지 않는다. 별로 살펴볼게 없다.

2. snappy

MongoDB를 설치하고 별도의 설정값을 변경하지 않았다면 snappy 가 default 이다. MongoDB는 WiredTiger 엔진을 사용하는데 이 엔진에서 사용하는 기본값이다.

압축, 압축해제에 효율적인 rate 로 압축한다. 즉 최대 값으로 압축을 하지 않는다는 것이다. 다른 compression library 와 호환성과 빠른 속도, 합리적은 압축을 목표로 한다.

가장 빠르다고 하는 zlib과 비교를 하자면 대부분의 입력에서 빠른 속도를 자랑하지만 압축된 파일의 용량은 zlib 에 비해 20% ~ 100% 까지 크다고 한다.

Single core i7 processor 64bit mode 에서 250MB/sec 이상으 로 압축을 하고 압축 해제는 500MB/sec 이상으로 수행한다.

3. zlib

snappy 와 비교했을 때 CPU를 더 사용해 높은 압축률을 제공한다. 데이터를 차곡차곡 저장하는 warehouse 같은 역할에 적합하다 생각한다.

OS에 의존하지 않도록 설계 되어 데이터를 이동하기도 좋으며, 손실 없는 압축이 목표이다.

4. zstd

zstd performance chart

내가 선택한 압축 방식이다. zlib과 비교했을때 더 높은 압축률과 더 낮은 CPU 사용을 한다. 페이스북에서 만든 알고리즘이다.

무손실과 실시간 압축 시나리오를 목표로 하여 zlib 에 비해서 더 높은 압축률을 제공한다.

나의 니즈는 2d sphere index 로서 좌표 계산을 위한것이다. 좌표는 대한민국 내의 지역에 대한 좌표이며 문서 갯수는 약 4만개이다.

TPS 테스트를 진행해보았다. 결론부터 이야기 하자면, 눈에 띄는 차이는 없었다. 아마 데이터가 더 많아야 하지 않을까 생각한다.

테스트를 했던 목적은 좌표 검색을 하는데 TPS 가 너무 낮았던것이 이유였다.

  1. zlib

    zlib tps test

  2. zstd

    zstd tps test

확인해보면 큰 차이가 없다 정말로.. ㅠㅠ 하지만 선택을 해야하는데 zlib 는 위에 서술했듯이 목적이 분명히 다르다.


결론

TPS 테스트로 일단 두 압축방법을 선택하지 못하겠다. 물론 지금에서야 이 문제를 해결하여 TPS를 훨씬 향상시켰지만, 일단 압축 알고리즘을 무엇으로 선택하느냐에 대한 질문엔 테스트 만으로는 정확한 답변을 할 수 없었다.

그래서 다음의 의사결정 과정을 거쳤다.

  1. 저장속도가 중요한가? -> no
  2. 읽는 속도가 중요한가? -> yes
  3. 데이터의 변경은 빈번한가? -> no (좌표는 그렇게 자주 변경되지 않는다.)
  4. cpu 사용률을 낮추고 싶은가? -> yes

그리고, 이러한 그래프를 접하게 되었다.

compress chart algorithm

출처는 stack over flow 이다.

이러한 생각을 거치고 나면, zlib 는 자연스럽게 제외가 되었고 snappy 와 zstd 중에서 선택을 해야한다.

snappy는 default 였고, 테스트 결과는 캡쳐로 보관해 두지 않았지만, 일단 zstd 쪽이 아주 약간 빠른 결과를 주었다.

일단 가장 중요한 것이 find query 를 실행할 때 속도이고, 이 속도에 의존해 API 성능이 정해지기 때문에 나는 zstd 를 선택했다.