4.3 MyISAM 스토리지 엔진 아키텍처

InnoDB와 MyISAM의 비교

InnoDB가 MyISAM보다 많은 기능이 있고 MyISAM이 더 좋았던 것들도 MYSQL 8.0 이후로 모든 면에서 거의 다 따라잡았으며,
8.0이후에서는 MYISAM을 제거하는 중.
결론 : InnoDB를 쓰자.

키 캐시

InnoDB의 버퍼 풀과 비슷한 역할을 하는 것이 MyISAM의 키 캐시(Key cache, 키 버퍼)다.
그러나 키 캐시는 인덱스만을 대상으로 작동하고, 인덱스가 아닌 데이터에 대해서는 캐시나 버퍼링 기능이 존재하지 않는다.
데이터의 읽기나 쓰기 작업은 항상 운영체제의 I/O 작업으로 요청될 수 밖에 없다.
대부분의 운영체제에는 디스크로부터 읽고 쓰는 작업을 위해 매번 디스크의 파일을 읽지는 않는다. (하단의 OS 캐시 구조 참고)
그러나 전체 메모리를 다른 프로세스에서 사용하고 있다면, 캐시용도로 사용할 수 있는 메모리 공간이 없어지고,
MyISAM 테이블의 데이터를 캐시하지 못하며, 쿼리 처리가 느려지게 된다.

따라서 MyISAM이 주로 사용되는 MySQL에서 일반적으로 키 캐시는 최대 물리 메모리의 40% 이상을 넘지 않도록 설정하고,
나머지 메모리 공간은 운영체제가 자체적인 파일 시스템을 위한 캐시 공간을 마련할 수 있게 해주는 것이 좋다.

OS 캐시 구조

OS는 메모리를 이용해서 디스크 엑세스를 줄일 수 있다.
Linux의 경우에는 페이지 캐시라고 하는 캐시 구조를 갖추고 있다.

페이지 캐시

프로세스가 디스크로부터 데이터를 읽어 내는 과정은
OS는 디스크로부터 페이지(4KB | 8KB) 블록을 읽어내서 메모리에 쓰고,
그 메모리 주소를 프로세스에게 알려주면 프로세스가 해당 메모리에 접근하는 것이다.

그 이후엔, 프로세스가 그 데이터를 읽고 난 후에, 필요하지 않은 데이터라 하더라도, OS는 페이지를 해제하지 않고 남겨두게 된다.
그러면 다른 프로세스가 같은 데이터를 읽게 될 경우, 디스크에 접근할 필요 없이, 캐시된 페이지를 읽어온다.
페이지 캐시 라고 하며 커널이 한 번 할당한 메모리를 해제하지 않고 남겨두는 것이 페이지 캐시의 기본이다.

메모리의 여유분이 없다면, LRU로 메모리 관리를 하게 된다.

스레드

공통 - 포그라운드 스레드(사용자 스레드)는 클라이언트와 커넥션을 연결하고, 버퍼나 캐시로부터 데이터를 가져오며, 버퍼나 캐시가 없는 경우,
디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.

InnoDB는 버퍼에서 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.

MYISAM은 포그라운드 스레드가 쓰기 작업까지 함께 처리되도록 설계되어 있다.

따라서 CUD가 일어나는 경우, InnoDB에서는 쓰기 작업을 버퍼링해서 일괄 처리하기 때문에 쓰기 지연으로 처리 된다.
MYISAM은 쓰기 지연이 처리 되지 않아, 디스크의 데이터 파일로 완전히 저장될 때까지 기다려야 한다.