[Real MySQL 8.0] 6. 데이터 압축

디스크 데이터가 크면 안좋다. 버퍼 풀에 LOAD할 때나 백업할 때 등 하여튼 안 좋음

MySQL 서버에서 사용 가능한 압출 방식은 테이블 압축, 페이지 압축 두 가지가 있다.

 

1. 페이지 압축

잘 쓰이지는 않는다.

펀치 홀? 이게 뭐지? 압축 해도 16KB단위 채우려고 빈공간을 꾸역꾸역 남겨 놓는데 이걸 나중에 OS가 펀치 홀 해버리는 것인가

운영체제와 하드웨어의 지원이 필요하다.

 

잘 안 쓴다니까 넘어가자

 

2. 테이블 압축

운영체제, 하드웨어에 대한 제약 없이 사용 가능. 활용도가 높다.

- 어떻게 앞축이 실행되어 디스크에 저장되는가

일단 압축 테이블을 별도로 만들어야 한다. 테이블을 만들 때 부터 innodb_file_per_table=ON으로 해서 만든다. 그러면 ROW_FORMAT=COMPRESSED로 하면 압축 테이블 생성됨.

KEY_BLOCK_SIZE 로 압축된 페이지의 타겟 크기(여기에 명시된 용량보다 작게 될만큼 압축된)를 지정한다. 4이상인 2의 배수임. 

그러면 실제 압축될 때 KEY_BLOCK_SIZE 가 될 때까지 계속 2로 나눠가면서 압축된다. -> 이 과정에서 서버 성능이 떨어질 수 있다.

KEY_BLOCK_SIZE는 어떻게 결정해야 하나. 실제로 테스트를 해보는게 최선. 압축 실패율이 3~5%가 되게 하자. (압축 실패율: 한번 압축 했는데 KEY_BLOCK_SIZE보다 커서 여러번 압축했다는 의미)

압축 실패율이 높을 수록 버퍼 풀에서 디스크에 저장되기 까지 오래 걸린다는 뜻이긴 한데... 무조건 높다고 성능이 낮은 것은 아니다.

- 압축 했을 때 데이터 파일 크기가 큰폭으로 줄어듦

낮다고 좋은 것도 아니다.

- 데이터 조회가 매우 빈번해서 디스크에서 압축해제 하는 오버헤드가 상대적으로 클 수 있음. 이 경우 압축 안하는게 이득

압축 알고리즘은 CPU많이 잡아 먹는다.

압축 관련 상세 설정은 나중에 필요할 때 다시 읽어보자..