복제
mongodb.png

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

태그
MongoDB
Configuration
compressor
snappy
zlib
zstd
공개여부
작성일자
2020/05/11
mongodb.png
Compressor 에 대해 알아보자
어느 DB를 다루든 늘 성능은 예민한 문제이다. 먼저 쿼리 튜닝을 포함해 다양한 방법이 있지만, 그에 앞서 필요한 설정을 해두고 쿼리 튜닝을 한다면 더욱 효과적인 성능을 기대할 수 있지 않을까?
config 파일에 보면
storage.wiredTiger.engineConfig.journalCompressor storage.wiredTiger.collectionConfig.blockCompressor
YAML
라는 부분에서 내가 필요한 방식으로 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-compressor-chart.png
내가 선택한 압축 방식이다. zlib과 비교했을때 더 높은 압축률과 더 낮은 CPU 사용을 한다. 페이스북에서 만든 알고리즘이다.
무손실과 실시간 압축 시나리오를 목표로 하여 zlib 에 비해서 더 높은 압축률을 제공한다.
나의 니즈는 2d sphere index 로서 좌표 계산을 위한것이다. 좌표는 대한민국 내의 지역에 대한 좌표이며 문서 갯수는 약 4만개이다.
TPS 테스트를 진행해보았다. 결론부터 이야기 하자면, 눈에 띄는 차이는 없었다. 아마 데이터가 더 많아야 하지 않을까 생각한다.
테스트를 했던 목적은 좌표 검색을 하는데 TPS 가 너무 낮았던것이 이유였다.
1.
zlib
zlib-performance-test.png
2.
zstd
zstd-performance-test.png
확인해보면 큰 차이가 없다 정말로.. ㅠㅠ 하지만 선택을 해야하는데 zlib 는 위에 서술했듯이 목적이 분명히 다르다.
결론
TPS 테스트로 일단 두 압축방법을 선택하지 못하겠다. 물론 지금에서야 이 문제를 해결하여 TPS를 훨씬 향상시켰지만, 일단 압축 알고리즘을 무엇으로 선택하느냐에 대한 질문엔 테스트 만으로는 정확한 답변을 할 수 없었다.
그래서 다음의 의사결정 과정을 거쳤다.
1.
저장속도가 중요한가? -> no
2.
읽는 속도가 중요한가? -> yes
3.
데이터의 변경은 빈번한가? -> no (좌표는 그렇게 자주 변경되지 않는다.)
4.
cpu 사용률을 낮추고 싶은가? -> yes
그리고, 이러한 그래프를 접하게 되었다.
compress-algoritm-chart.png
출처는 stack over flow 이다.
이러한 생각을 거치고 나면, zlib 는 자연스럽게 제외가 되었고 snappy 와 zstd 중에서 선택을 해야한다.
snappy는 default 였고, 테스트 결과는 캡쳐로 보관해 두지 않았지만, 일단 zstd 쪽이 아주 약간 빠른 결과를 주었다.
일단 가장 중요한 것이 find query 를 실행할 때 속도이고, 이 속도에 의존해 API 성능이 정해지기 때문에 나는 zstd 를 선택했다.
Made with 💕 and Oopy