압축은 왜 존재하는가?

디스크의 데이터 파일이 클수록 더 많은 페이지를 InnoDB 버퍼풀로 읽어야 할 수 있다. 백업시간도 오래걸리며, 복구시간도 그만큼 오래 걸린다. 

이런 문제점을 해결하기 위해 데이터 압축 기능을 제공한다. 

 

페이지 압축과 테이블 압축 기능을 제공한다.

 

페이지 압축

작동방식

MySQL 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 반대로 읽어올 때 압축이 해제 된다.

 

 

실제 디스크 공간은 7KB만 차지하지만 운영체제에서 읽을 때는 합쳐서 16KB를 읽는다.

 

페이지 압축의 문제

이런 펀치 홀 기능은 운영체제뿐만 아니라 하드웨어 자체에서도 해당 기능을 지원해야 사용 가능하다. 이런 이유로 실제 페이지 압축은 많이 사용되지 않는다.

 

테이블 압축

운영체제나 하드웨어에 대한 제약 없이 사용할 수 있어 활용도가 높다. 테이블 압축은 우선 디스크의 데이터 파일 크기를 줄일 수 있기 때문에 좋지만, 단점도 있다.

 

  1. 버퍼 풀 공간 활용률이 낮음
  2. 쿼리 처리 성능이 낮음
  3. 빈번한 데이터 변경 시 압축률이 떨어짐.

 

압축 테이블 생성

테이블 압축 사용을 위해, 압축을 사용하려는 테이블이 별도의 테이블 스페이스를 사용해야 한다. 

innodb_file_per_table --시스템 변수가 ON으로 설정된 상태에서 테이블이 생성돼야 한다.

--테이블 압축 사용하려는 테이블 생성 시 
ROW FORMAT=COMPRESSED --옵션을 명시해야 한다.

--추가로, 이 옵션을 이용해 압축된 페이지의 타깃 크기를 명시하는데 2n으로만 설정할 ㅅ ㅜ있다.
KEY_BLOCK_SIZE

--Innodb 스토리지 엔진의 페이지 크기가 16kb면 key_block_size는 4kb 또는 8kb만 설정 가능
--제한사항 페이지 크기가 32, 64kb인 경우는 테이블 압축 적용 불가

 

페이지를 압축한 용량이 얼마가 될지 알 수 없는데, 어떻게 key_block_size를 설정할 수 있나?

 

 

원본 데이터 페이지의 압축 결과가 목표크기(KEY_BLOCK_SIZE_보다 작거나 같을 때까지 반복해서 페이지를 스플릿하는 것이 테이블 압축 방식에서 가장 중요하다.

 

 

📌 목표 크기가 잘못 설정되면 MySQL 서버의 처리 성능이 급격히 떨어질 수 있다.

 

KEY_BLOCK_SIZE 결정

테이블 압축을 적용하기 전, 4KB나 8KB로 테이블을 생성해 샘플 데이터를 저장해보고 적절한지 판단하는 것이 좋다.

테이블의 데이터 페이지가 최소 10개 정도 생성되도록 테스트 데이터를 INSERT해보는 것이 좋다.

 

 

4kb, 8kb 별로 생성하고 조회해보고 실패율 (Compression_failure_pct)를 보고 판단하면 된다. 여기서 실패율이란 압축의 결과가 4kb를 초과해서 데이터 페이지를 스플릿해서 다시 압축을 실행했다는 의미다.

일반적으로, 압축 실패율은 3~5% 미만으로 유지할 수 있게 KEY_BLOCK_SIZE를 선택하는게 좋다.

 

 

압축 실패율이 그다지 높지 않더라도 테이블의 데이터가 매우 빈번하게 조회되고 변경된다면 압축은 고려하지 않는 것이 좋다. 압축 알고리즘은 많은 CPU 자원을 소모한다.

 

압축된 페이지의 버퍼 풀 적재 및 사용

InnoDB 스토리지 엔진은 압축된 테이블의 데이터 페이지를 버퍼 풀에 적재하면 압축된 상태와 압축 해제된 상태 2개 버전을 관리한다. LRU 리스트와 압축 해제 버전인 Unzip_LRU 리스트를 별도로 관리한다. 

 

LRU(Least Recently Used) 는 가장 오랫동안 사용되지 않은 데이터를 제거하는 알고리즘이다.

 

문제점

InnoDB 스토리지 엔진은 압축된 테이블에 대해서는 버퍼 풀의 공간을 이중으로 사용해 메모리를 낭비한다.

압축된 페이지에서 데이터를 읽거나 변경하려면 압축을 해제해야하는데, 이는 CPU를 상대적으로 많이 소모하는 작업이다.

 

그래서 Unzip_LRU 리스트를 별도로 관리하고 있따가 요청 패턴에 따라 적절히 처리를 수행한다.

 

테이블 압축 관련 시스템 변수 설정 

다음은 페이지 압축 실패율을 낮추기 위해 필요한 튜닝 포인트를 제공한다.

 

innodb_compression_failure_threshold_pct 와 innodb_compression_pad_pct_max: 테이블 단위로 압축 실패율이 pct threshold 설정값보다 커지면 압축을 실행하기 전 원본 데이터 페이지의 끝에 의도적으로 빈 공간을 추가한다. 즉, 추가된 빈 공간은 압축률을 높여 압축 결과가 key_block_size보다 작아지게 만드는 효과를 낸다.

 

추가하는 빈공간을 패딩이라고 하고, 압축 실패율이 높아질수록 이 공간이 계속 증가된다. 추가 가능한 최대 패딩 공간은 pct_max 설정값 이상을 넘을 수 없다 (% 단위 사용) 이는 전체 데이터 페이지 크기 대비 패딩 공간의 비율을 의미한다.

 

📌 예시

  1. 압축 실패 상황 (패딩 없음)
    • 데이터 페이지: 8KB
    • 압축 후 크기: 5KB → 실패 (key_block_size: 4KB)
  2. 압축 전 패딩 추가 상황
    • 데이터 페이지: 8KB + 패딩 1KB → 7KB로 간주됨
    • 압축 후 크기: 3.8KB → 성공 (key_block_size: 4KB)

여전히 key_block_size(예: 4KB)를 초과할 수 없다.

'데이터베이스' 카테고리의 다른 글

[MySQL] Index 인덱스란?  (0) 2024.12.30
MySQL InnoDB 트랜잭션과 락, 격리 수준  (1) 2024.12.15
InnoDB 스토리지 엔진 아키텍처, MYSQL 로그파일  (0) 2024.12.10
RealMySQL 4장 아키텍쳐 : MySQL 엔진에 대해 알아보자  (2) 2024.12.06
DB 성능 최적화 방법  (1) 2024.11.12

티스토리툴바