InnoDB만 고집하지 말고 때로는 스토리지 엔진을 바꿔보자
InnoDB는 MyISAM과 달리 인덱스뿐만 아니라 데이터까지 버퍼 풀에 저장한다. 이 때문에 데이터가 메모리에 있으면 디스크를 읽지 않아도 된다는 큰 장점이 있다.
하지만 인덱스와 데이터 모두 메모리에 적재한다는 점에서 메모리 사용 효율이 좋지는 않다. 게다가 PK를 제외한 보조 인덱스는 인덱스 칼럼 + PK의 구조를 가지기 때문에 인덱스 자체의 사이즈가 상당히 커질 수 있다.
이러한 특성 때문에 테이블 용도가 로그 수집과 같이 단순하다면 오히려 메모리 사용 효율이 크게 떨어질 수밖에 없다.
위 그림과 같이 단순 로그 수집을 위한 테이블 데이터가 InnoDB 버퍼 풀을 가득 채운다면 서비스와 연관된 데이터에 할당할 메모리 공간까지 차지하지 때문에 서비스에 직접적인 영향을 준다.
이런 경우라면 로그 수집에 적합한 스토리지 엔진을 선정하여 메모리의 효율을 높일 수 있다.
MySQL에는 로그 수집에 적합한 Archive 스토리지 엔진과 MyISAM 스토리지 엔진이 있다.
Archive 스토리지 엔진은 행 단위 잠금으로 동작하며, 데이터를 압축하여 디스크에 저장한다. 그러므로 동시 데이터 저장에도 큰 무리가 없으며, 디스크 사용량도 줄일 수 있다.
그러나 데이터 INSERT/UPDATE 만 가능하고 UPDATE/DELETE 는 사용할 수 없다. 게다가 인덱스를 지원하지 않으므로 단일 데이터 접근 및 제어 시에는 적당하지 않다.
MyISAM 스토리지 엔진은 테이블 잠금 형식으로 동작하기 때문에 동시 로그 적재 서비스에는 적합하지 않지만, 데이터 크기가 InnoDB에 비해 작고, 인덱스를 지원한다.
특히 저사양 서버에 사용하기 위해 고안된 스토리지 엔진이기 때문에 메모리 사용 효율이 아주 좋다.
아래는 스토리지 엔진별로 10만 건의 데이터가 있을 때 차지하는 용량을 나타낸 표이다.
InnoDB 대비 Archive는 1/8, MyISAM은 1/4 정도로 디스크를 적게 차지한다.
테이블의 스토리지 엔진을 선정하기 전 위와 같이 테이블 용도에 따라 다양한 스토리지 엔진을 고려해볼 수 있다.
단, MyISAM과 Archive는 트랜잭션을 지원하지 않기 때문에 리플리케이션 환경에서 Master-Slave 간 데이터 변경 이슈가 발생할 수 있으니 주의해야 한다. (Slave에서 Master의 변경사항을 적용하면 오류가 발생해도 데이터 롤백을 수행하지 않는다.)
'DB' 카테고리의 다른 글
| MySQL 퍼포먼스 최적화를 읽고(5) - 스키마 레벨에서의 접근법 (0) | 2023.10.24 |
|---|---|
| MySQL 퍼포먼스 최적화를 읽고(4) - SQL 레벨에서의 접근법 (0) | 2023.10.24 |
| MySQL 퍼포먼스 최적화를 읽고(3) - WHERE 조건 이해 (1) | 2023.10.24 |
| MySQL 퍼포먼스 최적화를 읽고(2) - 쿼리 성능 진단은 최적화의 기초 (1) | 2023.10.24 |
| MySQL 퍼포먼스 최적화를 읽고(1) - MySQL의 특징 (0) | 2023.10.21 |
