[RealMySQL 8.0] 6장 데이터 압축

• 디스크 데이터 파일의 크기는 쿼리 성능과 백업 및 복구 시간에도 영향을 미친다.
• 더 큰 크기의 데이터가 버퍼풀에 적재되므로 버퍼풀 사용의 효율성이 떨어지고, 더 많은 IO가 발생한다.
• 데이터 압축은 테이블 압축과 페이지 압축 두 가지로 구분된다.

6.1 페이지 압축

• 페이지 압축과 해제는 디스크 <-> 스토리지 엔진 간에 일어나기 때문에 MySQL 서버 내부적으로는 압축 유무를 신경쓸 필요가 없다.
• 이를 Transparanet Page Compression 이라고 한다.
• 한 페이지가 얼마나 압축될지 모르기 때문에, 페이지 압축은 특정 버전의 파일 시스템에서만 지원되는 펀치홀이라는 기능을 사용한다.
• 펀치홀은 압축되어 빈 공간에 대해 일부만 OS에 반납하는 기능이다.
• 이런 제약으로 잘 사용되지 않는다. 테이블 생성 시 COMPRESSION="zlib"을 추가하여 생성한다.

6.2 테이블 압축

• 운영체제나 하드웨어에 대한 제약 없이 사용할 수 있기 때문에 활용도가 더 높다.
• 디스크를 효율적으로 사용할 수 있으나, 버퍼풀 공간 활용이 떨어지고, 쿼리 성능 저하 및 잦은 데이터 변경 시 압축률이 떨어진다는 단점이 있다.
• 테이블 압축을 사용하려는 테이블이 별도의 테이블 스페이스를 사용해야한다.
  • 테이블 스페이스란 데이터와 인덱스를 물리적으로 저장하는데 사용되는 공간이다.
  • innodb_file_per_table 시스템 변수가 ON으로 설정되어 있어야 한다.
  • 테이블 생성 시 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=n 설정이 필요하다.
  • n은 4이상의 짝수, kb 단위. 페이지 크기가 32 or 64 kb 인 경우 압축을 적용할 수 없다.
• KEY_BLOCK_SIZE 옵션은 압축된 페이지가 저장될 페이지 크기를 지정한다.
• 페이지 압축은 분할정복 식으로 원본 페이지를 split을 반복하여 압축되고, split 은 압축 결과가 KEY_BLOCK_SIZE 보다 작을 때 멈춘다.
• 따라서 KEY_BLOCK_SIZE는 처리 성능에 영향을 미친다.
  • information_schema.innodb_cmp_per_index 에서 압축 실패율을 알 수 있으며,
  • 쓰기만 이뤄지는 로그성 테이블에서 압축 실패율이 높아도 데이터 파일 크기가 크게 줄어든다면 손해는 아닐 것이다.
  • 빈번하게 조회되고 변경된다면 압축은 고려하지 않는게 좋다.
  • 따라서 압축률과, 압축 실패율, 데이터의 특성을 고려하는 것이 좋다.
• 버퍼풀은 압축된 상태와 압축이 해제된 상태 2개 버전의 데이터를 관리한다.
  • 따라서 버퍼풀 eviction을 위한 LRU 리스트는 두개 존재한다.
  • 버퍼풀은 Adaptive하게 버퍼풀의 공간이 모자르면 압축된 형태는 유지하고, 압축 해제된 상태는 제거한다.
  • 데이터가 자주 사용되면 압축된 형태는 제거하고, 압축 해제된 상태는 유지한다.
  • 압축된 데이터페이지가 삭제되는 경우 압축 해제된 버전도 제거한다.
  • CPU 사용률이 높다면 Unzip_LRU 의 비율을 높이고, Disk IO 가 높다면 Unzip_LRU 비율을 낮추자.
• 압축 관련 테이블 설정
  • innodb_cmp_per_index_enabled: 압축 성공 및 실패 횟수를 수집한다.
  • innodb_compression_level: 압축률을 설정한다. 높을 수록 압축률이 크다.
  • innodb_compression_threshold_pct, innodb_compression_pad_pct_max: 전자의 값보다 압축 실패율이 커지면 압축 성공률을 높일 수 있도록 최대 후자의 값(퍼센트단위)만큼 패딩을 추가한다.
  • innodb_log_compressed_pages: 비정상적 종료 후 재기동 시 압축 알고리즘의 변화가 있어 복구가 실패하지 않도록 압축된 페이지를 리두로그에 기록한다. 리두 로그 증가량에 영향을 미칠수 있으나, 가능하면 기본값인 ON을 유지하자.