Database/MySQL

MyISAM 스토리지 엔진 아키텍처

Debin 2022. 11. 27.

MyISAM 스토리지 엔진의 성능에 영향을 미치는 요소인 키 캐시와 운영체제의 캐시/버퍼에 대해 살펴보자.

InnoDB 버퍼 풀과 비슷한 역할을 하는 것이 MyISAM의 키 캐시다.

하지만 이름 그대로 키 캐시는 인덱스만을 대상으로 작동하며, 또한 인덱스의 디스크 쓰기 작업에 대해서만 부분적으로 버퍼링 역할을 한다.

키 캐시가 얼마나 효율적으로 작동하는지는 다음 수식으로 확인할 수 있다.

Key_reads는 인덱스를 디스크에서 읽어 들인 횟수를 저장하는 상태 변수이며,

Key_read_requests는 키 캐시로부터 인덱스를 읽은 횟수를 저장하는 상태 변수다.

메뉴얼에서는 키 캐시를 이용한 쿼리의 비율을 99% 이상으로 유지하라고 권장한다.

히트율이 99% 미만이라면 키 캐시를 조금 더 크게 설정하는 것이 좋다.

하지만 32 비트 운영체제에서는 하나의 키 캐시에 4GB 이상의 메모리 공간을 설정할 수 없다.

64비트 운영체제에서는 OS_PER_PROCESS_LIMIT 값에 설정된 크기 만큼의 메모리를 할당할 수 있다.

제한 값 이상의 키 캐시를 할당하고 싶다면 기본 키 캐시 이외에 별도의 명명된 키 캐시 공간을 설정해야 한다.

MyISAM 테이블의 인덱스는 키 캐시를 이용해 디스크를 검색하지 않고도 충분히 빠르게 검색할 수 있다.

하지만 MyISAM 테이블의 데이터에 대해서는 디스크로부터의 I/O를 해결해 줄 만한 어떠한 캐시나 버퍼링 기능도 MyISAM 스토리지 엔진은 가지고 있지 않다.

그래서 MyISAM 테이블의 데이터 읽기나 쓰기 작업은 항상 OS의 디스크 읽기 또는 쓰기 작업으로 요청될 수 밖에 없다.

물론 대부분의 OS에는 디스크로부터 읽고 쓰는 파일에 대한 캐시나 버퍼링 메커니즘을 탑재하고 있기 때문에

MySQL 서버가 요청하는 디스크 읽기 작업을 위해 매번 디스크의 파일을 읽지는 않는다.

운영체제의 캐시 기능은 InnoDB처럼 데이터의 특성을 알고 전문적으로 캐시나 버퍼링을 하지는 못하지만, 그래도 없는 것보다 낫다.

OS의 캐시 공간은 남는 메모리를 사용하는 것이 기본 원칙이다.

전체 메모리가 8GB인데 MySQL이나 다른 애플리케이션에서 메모리를 모두 사용해 버린다면 운영체제가 캐시 용도로 사용할 수 있는 메모리 공간이 없어진다.

이런 경우에는 MyISAM 테이블의 데이터를 캐시하지 못하며, 결론적으로 MyISAM 테이블에 대한 쿼리가 느려진다.

데이터베이스에서 MyISAM 테이블을 주로 사용한다면 운영체제가 사용할 수 있는 캐시 공간을 위해 충분한 메모리를 비워둬야 이러한 문제를 방지할 수 있다.

MyISAM이 주로 사용되는 MySQL에서 일반적으로 키 캐시는 최대 물리 메모리의 40% 이상을 넘지 않게 설정하고,

나머지 메모리 공간은 OS가 자체적인 파일 시스템을 위한 캐시 공간을 마련할 수 있게 해주는 것이 좋다.

InnoDB 스토리지 엔진을 사용하는 테이블은 프라이머리 키에 의해서 클러스터링되어 저장되는 반면,

MyISAM 테이블은 프라이머리 키에 의한 클러스터링 없이 데이터 파일이 힙 공간처럼 활용된다.

즉 MyISAM 테이블에 레코드는 프라이머리 키 값과 무관하게 INSERT되는 순서대로 데이터 파일에 저장된다.

그리고 MyISAM 테이블에 저장되는 레코드는 모두 ROWID라는 물리적인 주솟값을 가지는데,

프라이머리 키와 세컨더리 인덱스는 모두 데이터 파일에 저장된 레코드의 ROWID 값을 포인터로 가진다.

MyISAM 테이블에서 ROWID는 가변 길이와 고정 길이의 두 가지 방법으로 저장될 수 있다.

댓글