: 테이블 압축은 운영체제나 하드웨어에 대한 제약 없이 사용할 수 있기 때문에 일반적으로 더 활용도가 높은 편
: 디스크의 데이터 파일의 크기를 줄일 수 있기 때문에 그만큼의 이득은 있으나 다음과 같은 단점이 있다.
•
버퍼 풀 공간 활용률이 낮음
•
쿼리 처리 성능이 낮음
•
빈번한 데이터 변경 시 압축률이 떨어짐
1. 압축 테이블 생성
: 테이블 압축을 사용하기 위한 전제 조건으로 압축을 사용하려는 테이블이 별도의 테이블 스페이스를 사용해야 함, 이를 위해선 innodb_file_per_table 시스템 변수가 ON이어야 함
: 테이블 압축을 사용하는 테이블은 다음과 같이 테이블을 생성할 때 ROW_FORMAT=COMPRESSED 옵션을 명시해야 함, 추가로 KEY_BLOCK_SIZE 옵션을 사용해서 압축될 페이지의
타깃 크기를 설정하는 데, 2n으로만 설정할 수 있음, InnoDB 스토리지 엔진의 페이지 크기가 16KB라면 KEY_BLOCK_SIZE는 4KB, 8KB만 설정할 수 있음, 32KB, 64KB인 경우는
사용할 수 없음
: KEY_BLOCK_SIZE만 명시를 해주어도 ROW_FORMAT=COMPRESSED는 자동으로 추가되어 생성
데이터 페이지를 압축한 용량이 얼마가 될지 알 수 없는데, 어떻게 KEY_BLOCK_SIZE를 테이블을 생성할 때 설정할 수 있을까?
1.
16KB의 데이터 페이지를 압축
a.
압축된 결과가 8KB 이하이면 그대로 디스크에 저장(압축 완료)
b.
압축된 결과가 8KB 초과하면 원본 페이지를 스플릿해서 2개의 페이지에 8KB씩 저장
2.
나뉜 페이지 각각에 대해 1번 단계를 반복 실행
스토리지 엔진 내부에서만 일어나며 가장 중요한 것은 원본 데이터 페이지의 압축 결과가 목표 크기보다 작거나 같을 때까지 반복해서 페이지를 스플릿하는 것
2. KEY_BLOCK_SIZE 결정
: 테이블 압축에서 가장 중요한 부분은 압축된 결과가 어느 정도가 될지를 예측해서 KEY_BLOCK_SIZE를 결정하는 것, 일반적으로 테이블 압축을 적용하기 전에 KEY_BLOCK_SIZE를 4KB,
8KB로 생성해서 샘플 데이터를 저장해보고 적절한지 판단하는 것이 좋음, 이때 샘플 데이터가 많으면 많을수록 더 정확한 테스트가 가능한데, 데이터 페이지가 10개는 생성되도록
테스트 데이터를 INSERT해보는 것이 좋다.
3. 압축된 페이지의 버퍼 풀 적재 및 사용
: InnoDB 스토리지 엔진은 압축된 테이블의 데이터 페이지를 버퍼 풀에 적재할 때, 압축 버전과 압축이 해제된 버전 2개로 관리, 즉 LRU 리스트와 Unzip_LRU 리스트를 별도로 관리
MySQL 서버에는 압축된 테이블과 압축되지 않은 테이블이 공존하므로 결국 LRU 리스트는 다음과 같이 압축된 페이지와 압축되지 않은 페이지를 모두 가질 수 있음
•
압축이 적용되지 않은 테이블의 데이터 페이지
•
압축이 적용된 테이블의 압축된 데이터 페이지
: 그런데 Unzip_LRU 리스트는 압축이 적용되지 않은 테이블의 데이터 페이지를 가지지 않으며 압축이 적용된 테이블에서 읽은 데이터 페이지만 관리
⇒ 이는 InnoDB 스토리지 엔진이 압축된 테이블에 대해서는 버퍼 풀의 공간을 이중으로 사용함으로써 메모리를 낭비하는 효과를 가짐
⇒ 압축된 페이지에서 데이터를 읽거나 변경하기 위해 압축을 해제해야한다는 것인데, 이는 CPU를 상대적으로 많이 소모하는 작업
: 이를 Unzip_LRU 리스트를 별도로 관리하고 있다가 MySQL 서버로 유입되는 요청 패턴에 따라 적절히 다음과 같은 처리를 수행
•
INnoDB 버퍼 풀의 공간이 필요한 경우는 LRU 리스트에서 원본 데이터 페이지는 유지하고, Unzip_LRU 리스트의 압축 해제된 버전을 제거해서 버퍼 풀의 공간을 확보
•
압축된 데이터 페이지가 자주 사용되는 공간일 경우 Unzip_LRU 리스트에 압축 해제된 페이지를 계속 유지하면서 압축 및 압축 해제 작업을 최소화
•
압축된 데이터 페이지가 사용되지 않아서 LRU 리스트에서 제거되는 경우에는 Unzip_LRU 리스트에서도 제거
: InnoDB 스토리지 엔진은 버퍼 풀에서 압축 해제된 버전의 데이터 페이지를 적절한 수준으로 유지하기 위해 Adaptive 알고리즘을 사용
•
CPU 사용량이 높은 서버에서는 가능하면 압축과 압축 해제를 피하기 위해 Unzip_LRU의 비율을 높여서 유지
•
Disk IO 사용량이 높은 서버에서는 가능하면 Unzip_LRU 리스트의 비율을 낮춰서 InnoDB 버퍼 풀의 공간을 더 확보
4. 테이블 압축 관련 설정
: 테이블 압축을 사용할 때 연관된 시스템 변수가 몇 가지 있는데, 이는 모두 페이지의 압축 실패율을 낮추기 위한 튜닝 포인트를 제공
•
innodb_cmp_per_index_enalbed
•
innodb_compression_level
•
innodb_compression_failure_threshold_pct와 innodb_compression_pac_pct_max
•
innodb_log_compressed_pages
