데이터 압축

데이터 파일의 크기

• MySQL 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연결된다.
• 디스크의 데이터 파일이 크면 클수록
  • 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고
  • 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록돼야 한다.
• 데이터 파일이 크면 클수록 백업 시간이 오래 걸리며, 복구하는 데도 그만큼의 시간이 걸린다.
  • 물론 그만큼의 저장 공간이 필요하기 때문에 비용 문제도 있을 수 있다.

데이터 압축 기능

• 많은 DBMS가 이러한 문제점을 해결하기 위해 데이터 압축 기능을 제공한다.
• MySQL 서버에서 사용 가능한 압축 방식은 크게 두 가지 종류로 구분할 수 있다.
  • 페이지 압축
  • 테이블 압축

페이지 압축

페이지 압축

• “Transparent Page Compression”이라고도 불린다.
  • MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고,
  • 반대로 MySQL 서버가 디스크에서 데이터 페이지를 읽어올 때 압축이 해제되기 때문이다.
• 버퍼 풀에 데이터 페이지가 한 번 적재되면 InnoDB 스토리지 엔진은 압축이 해제된 상태로만 데이터 페이지를 관리한다.
  • 그래서 MySQL 서버의 내부 코드에서는 압축 여부와 관계없이 “투명(Transparent)”하게 작동한다.

페이지 압축의 문제점

• 16KB 데이터 페이지를 압축한 결과가 용량이 얼마나 될지 예측이 불가능한데 적어도 하나의 테이블은 동일한 크기의 페이지(블록)로 통일되어야 한다.
  • 그래서 ‘펀치 홀’ 기능을 사용한다.

펀치 홀(Punch hole)

• 페이지 압축 기능은 운영체제별로 특정 버전의 파일 시스템에서만 지원되는 ‘펀치 홀’이라는 기능을 사용한다.
• 운영체제(파일 시스템)의 블록 사이즈가 512바이트인 경우, 페이지 압축이 작동하는 방식을 간단히 살펴보면 다음과 같다.

  1. 16KB 페이지를 압축 (압축 결과를 7KB로 가정)
  2. MySQL 서버는 디스크에 압축된 결과 7KB를 기록 (이때 MySQL 서버는 압축 데이터 7KB에 9KB의 빈 데이터를 기록)
  3. 디스크에 데이터를 기록한 후, 7KB 이후의 공간 9KB에 펀치 홀(Punch-hole)을 생성
  4. 파일 시스템은 7KB만 남기고 나머지 디스크의 9KB 공간은 다시 운영체제로 반납

  • MySQL 서버는 특정 테이블에 대해 16KB 크기의 페이지를 유지하면서도 압축된 다양한 크기의 데이터 페이지를 디스크에 저장하고 압축된 만큼의 공간을 절약할 수 있다.

펀치 홀의 문제점

• 펀치 홀 기능은 운영체제뿐만 아니라 하드웨어 자체에서도 해당 기능을 지원해야 사용 가능하다.
• 아직 파일 시스템 관련 명령어(유틸리티)가 펀치 홀을 지원하지 못한다.
• MySQL 서버의 데이터 파일은 해당 서버에서만 머무는 것이 아니다.
  • 백업했다가 복구하는 과정에서 데이터 파일 복사 과정이 실행되고,
  • 그 외에도 많은 파일 관련 유틸리티들을 사용한다.
• 예를 들어, 펀치 홀이 적용되어 실제 데이터 파일의 크기가 1GB라고 하더라도 “cp” 같은 파일 복사 명령 또는 XtraBackup 같은 툴이 파일일 복사하면 펀치 홀이 다시 채워져서 데이터 파일의 크기는 원본 크기인 10GB가 될 수도 있다.
• 이러한 이유로 실제 페이지 압축은 많이 사용되지 않는 상태다.

페이지 압축 이용

• 페이지 압축을 이용하기 위해서는 테이블을 생성하거나 변경할 때 다음과 같이 COMPRESSION 옵션을 설정하면 된다.

  -- 테이블 생성 시
  CREATE TABLE t1 (c1 INT) COMPRESSION="zlib";
  
  -- 테이블 변경 시
  ALTER TABLE t1 COMPRESSION="zlib";
  OPTIMIZE TABLE t1;

Reference

참고 서적

📔 Real MySQL 8.0