MySQL 데이터 압축

ollie·2024년 3월 18일

MySQL

목록 보기
2/4

배경 🐈

책 'Real MySQL 8.0'과 'MySQL을 더 빠르게, 성능 최적화 선택과 집중' 이라는 책을 가지고 현업 개발자 2분과 스터디를 진행하고 있습니다.
오늘은 'Real MySQL 8.0'의 '데이터 압축'을 읽고 진행했던 스터디의 핵심 내용과 스터디를 하며 고민했던 부분 위주로 정리하고자 합니다.

📍 데이터 압축

MySQL 서버가 가진 저장 공간은 한정되어 있다. 이 한정된 공간에 더 많은 데이터를 넣고, 디스크에서 InnoDB 버퍼 풀(메모리)로 데이터를 가져올 때 한번에 더 많은 데이터를 가져오기 위해서 쓰이는 기술이 데이터 압축이다.

📌 페이지 압축

Transparent Page Compression이라고 불리는 페이지 압축은 말 그대로 페이지 단위로 데이터를 압축하는 기술이다. 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 디스크에서 데이터 페이지를 읽어올 때 압축이 해제되는 방식으로 동작한다.

그런데 페이지 압축은 활용에 제한이 있어 잘 안 쓰인다.
페이지 단위로 압축되면 각 페이지마다 빈 공간이 생기는데 이걸 펀치 홀(punch hole) 로 메꿔서 저장해야 한다. 이런 펀치 홀 기능을 파일 시스템 쪽에서 지원하지 못하기 때문이다. 그리고 데이터 압축은 저장 공간을 줄이거나 한번에 더 많은 데이터를 전송하기 위해 쓰이는데 펀치 홀을 이용해 빈 공간을 채워야 한다면 데이터 압축으로써의 기능을 충분히 다 하지 못하기 때문이다.

📌 테이블 압축

페이지 압축과 달리 사용에 제약이 없어 일반적으로 사용되는 기술이다.

테이블 압축은 어떻게 동작할까?

KEY_BLOCK_SIZE 는 압축된 데이터의 목표 사이즈를 지정하는 설정이다. 보통은 4KB나 8KB로 지정해보고 성능 테스트를 통해 조절한다.

만약 KEY_BLOCK_SIZE가 8KB라고 했을 때, 테이블 압축은 테이블 단위로 압축하는 방식으로 데이터가 압축된 결과가 8KB 이하면 디스크에 저장하고 8KB 초과면 페이지를 스플릿(split)해서 8KB 이하인지 확인하고 8KB 이하면 저장하는 과정을 반복한다.

압축 데이터 사이즈가 커서 스플릿 작업을 할 때마다 압축 실패율이 높아지는데, 이 압축 실패율이 높다는 건 InnoDB 버퍼 풀에서 디스크로 기록되기까지 걸리는 시간이 길다는 것이다.

그럼 어떤 경우에 데이터 압축을 하는 게 적절할까?

저장 공간을 더 효율적으로 사용할 수 있다고해서 무조건 데이터 압축을 적용하는 것은 적절치 않다. 매번 InnoDB 버퍼 풀과 디스크 사이를 이동할 때마다 데이터를 압축/해제하는 건 CPU를 많이 잡아먹는 일이고 시간도 더 걸리는 일이다. 그리고 InnoDB 스토리지 엔진은 버퍼 풀에 압축된 데이터나 압축 해제된 데이터를 같이 저장하기 때문에 메모리 낭비가 발생하기도 한다. 그래서 데이터 압축을 할 때 데이터 압축을 할만한 데이터인지 아닌지에 대한 고민이 필요하다.

InnoDB 스토리지 엔진은 버퍼 풀에서 압축 해제된 버전의 데이터 페이지를 적절한 수준으로 유지하기 위해 adaptive 알고리즘을 사용하는데, 이 알고리즘의 동작 방식으로 데이터 압축이 필요한 경우와 아닌 경우를 유추할 수 있다.

  • CPU 사용량이 높은 서버에서는 압축과 압축 해제를 피하기 위해 Unzip_LRU의 비율을 높여서 유지하고
  • Disk I/O 사용량이 높은 서버에서는 가능하면 Unzip_LRU 리스트의 비율을 낮춰서 InnoDB 버퍼 풀의 공간을 더 확보하도록 작동한다.

디스크 I/O를 줄이고자 하면 데이터 압축이 유용하나 CPU 사용량이 이미 높은 경우는 데이터 압축을 사용하는 것이 적절하지 않다.
그리고 데이터를 효율적으로 저장하고자 한다면 데이터 압축을 사용하기보다 필요 없는 데이터를 삭제하는 등의 방식으로 데이터 최적화를 하는 것이 더 적합할 것이다.

이번 챕터는 읽으면서 이 기술을 쓰는 게 맞는지 쓴다면 언제 써야할지 계속 고민하면서 읽은 챕터였다. 그렇기 때문에 스터디에서도 그런 의문을 제시했었고, 데이터 압축의 장단점과 데이터 압축이 쓰이는 케이스를 중심으로 스터디가 진행되었었다. 장점이 명확해서 왠만하면 쓰는 게 좋은 기술에 비해 장점 못지않게 단점도 명확하여 충분히 고민해보고 적용해야 하는 기술이라 꽤 어려웠던 것 같다. 압축을 적용할 경우와 적용하지 않을 경우의 성능 테스트에 대해 충분히 하고 써야겠다.


[참고 자료]
Real MySQL 8.0 (1권)

profile
생각하는 개발자가 되겠습니다 💡

0개의 댓글