- 06 데이터 압축
- 페이지 압축
- 펀치홀이라는 빈공간을 사용해 페이지별로 압축하지만, 운영체제나 하드웨어의 도움으 많아야 하므로 많이 사용되지 않는다.
- 테이블 압축 - 테이블 단위로 압축을 실시한다.
- 압축 테이블 생성
- innodb_file_per_talbe = on이 설정된 상태에서 테이블이 생성되야 한다.
- 테이블 스페이스 : 테이블이 저장되기 위한 파일 공간
- KEY_BLOCK_SIZE 옵션을 기입 해주면, ROW_FORMAT=COMPRESSED 옵션이 자동으로 적용된다.
- 압축의 메커니즘에서 가장 중요한 것은 KEY_BLOCK_SIZE 값이다. 주어진 데이터를 압축 해보고, 이 압축된 결과값이 KEY_BLOCK_SIZE을 넘으면, 저장되지 않고 페이지 스플릿 단계로 넘어가, 데이터를 쪼개고 다시 압축을 실시한다. 쪼개진 부분들을 또 이러한 과정을 반복하여 KEY_BLOCK_SIZE 범위에 드는 압축 데이터만을 디스크에 저장하게 된다.
- innodb_file_per_talbe = on이 설정된 상태에서 테이블이 생성되야 한다.
- KEY_BLOCK_SIZE 결정
- 데이터를 압축 했을 때, 그 압축된 데이터의 결과가 얼마가 될지 예측하는 값이다.
- KEY_BLOCK_SIZE가 적절하게 설정되지 않는다면, 디스크에 기록되기 전에 위에 설명한 압축 메커니즘을 계속해서 거치면서 작업이 더디게 된다.
- 데이터를 압축하는 과정에서 조회 처리를 적절하게 처리 할 수 없으므로 빈번한 조회 처리가 일어나는 곳에선 사용을 자제한다.
- 변경이 많이 일어나는 데이터도 자제한다. 변경이 일어나면 다시 압축을 실시 해야하므로
- 압축 알고리즘 자체는 CPU 자원을 많이 사용한다
- 압축된 페이지의 버퍼 풀 적재 및 사용
- InnoDB의 버퍼풀은 LRU 리스트에 원본 데이터(압축된)를 보관하고, UnZip_LRU에 압축 해제된 데이터를 이중 보관한다. → 이중 보관이기에 메모리 공간을 낭비 할 수 있다.
- 메모리 공간 낭비를 최소화하기 위해 Apdative한 처리 전략을 사용한다.
- 버퍼 풀의 공간이 부족해지면 LRU보단 UnZip_LRU의 비중을 줄인다. (어차피 LRU엔 전부 들어가 있으니깐, 대신 LRU에서 압축된 데이터를 사용할 경우엔 압축 해제가 들어가야 하므로, CPU 자원 사용 비용이 증가 할 수 있다.)
- 압축된 데이터가 자주 사용될 경우는 CPU 사용 비용을 아끼기 위해 미리 압축 해제 해놓은 UnZip을 계속해서 활용한다.
- LRU 리스트에서 제거된 데이터 페이지는 UnZip에서도 사용되지 않을 것이기에 같이 제거된다.
- 테이블 압축 관련 설정
-
innodb_cmp_per_index_enabled : 인덱스별로 압축 성공, 압축 실패율 등을 보여준다.
-
innodb_compression_level : 압축의 정도를 설정한다. 값이 커질 수록 압축의 정도를 빡쎄게 가져가지만, 그만큼 압축 시간은 오래 걸린다
-
innodb_compression_filure_threshold_pct : 실패율에 대한 한계치를 의미한다. 실패율이 이 값을 넘어 갈 경우 페이지 맨뒤에 빈공간(패딩)을 추가하여 실패율을 낮추고자 한다.
-
innodb_compression_pad_pct_max : 패딩 값을 무한정 증가시키지 않기 위해 한계 값을 설정한다.
-
innodb_log_compressed_pages : 압축된 데이터 페이지를 리두 로그에 넣어둘게
기본적으로 On으로 설정되어 있다.
-
- 압축 테이블 생성
- 페이지 압축
좋은 영향력과 교류를 위하여