서론
MyISAM 스토리지 엔진 성능에 영향을 미치는 요서인 키 캐시와 운영체제의 캐시/버퍼에 대해 살펴보자
MyISAM 특징
- 트랜잭션 없음
- 레코드 단위 잠금 없음(=테이블 잠금만 존재)
- 데이터 캐시 없음 -> 운영체제 캐시에 의존
- 인덱스는 자체 키 캐시가 따로 있음
4.3.1 키 캐시
키 캐시(Key cache, 키 버퍼라고도 불림)
- InnoDB의 버퍼 풀과 비슷한 역할을 하지만, 인덱스만을 대상으로 작동
- MyISAM은 데이터 캐시 기능이 없음 -> 인덱스만이라도 빠르게 하려고 만든 캐시
특징
- 인덱스의 디스크 쓰기 작업에 대해서만 부분적으로 버퍼링
- 키 캐시 히트율 계산식:
100 - (Key_reads / Key_read_requests * 100)
-Key_read_requests: 캐시에서 인덱스 요청한 횟수Key_reads: 디스크에서 읽은 횟수
- 일반적으로 99% 이상의 히트율 권장(디스크 I/O 최소화)
작동 방식
1. MyISAM 인덱스는 디스크에 B-Tree 구조로 저장됨
2. 쿼리를 실행하면 인덱스 블록을 키 캐시에서 먼저 찾음 (hit)
3. 없으면 디스크에서 읽어 키 캐시에 적재하고 사용 (miss)
-> 그래서 키 캐시의 효율 = 인덱스 검색 속도
키 캐시 여러 개 만들 수 있음
MyISAM은 여러 개의 키 캐시를 만들어 특정 테이블 인덱스를 특정 캐시에 매핑 가능
=> 인덱스를 여러 캐시에 나눠 병목을 줄이는 구조
4.3.2 운영체제의 캐시 및 버퍼
핵심 포인트
- MyISAM은 데이터에 대한 자체 캐시가 전혀 없음
- 인덱스만 키 캐시로 캐싱하고, 데이터는 전부 운영체제(OS)의 파일 시스템 캐시에 의존
차이(InnoDB vs MyISAM)
| 항목 | InnoDB | MyISAM |
|---|---|---|
| 데이터 캐시 | Buffer Pool(전문적, 고성능) | 없음 |
| 운영체제 캐시 사용 | 제한적 | 대부분 의존 |
| 동시 처리 성능 | 높음 | 매우 낮음(테이블 락) |
-> 결국 동시성 & 캐싱 성능 모두 InnoDB가 압도적
운영체제 캐시의 문제
운영체제 파일 캐시는 전문 DB 캐시가 아님
- 데이터 패턴 고려 X
- 페이지 핫 스팟 고려 X
- 어떤 데이터가 자주 쓰이는지 판단 X
=> 따라서, 데이터 캐싱을 직접 하는 InnoDB가 훨씬 빠름
4.3.3 데이터 파일과 프라이머리 키(인덱스) 구조
핵심 포인트
MyISAM 데이터 파일 구조는 힙 파일(Heap) 형태
- 데이터는 INSERT 순서대로 저장
- 프라이머리 키를 기준으로 정렬되거나 클러스터링 X
-> InnoDB와 결정적으로 다른 부분
InnoDB VS MyISAM 저장 구조 차이
| 항목 | InnoDB | MyISAM |
|---|---|---|
| 프라이머리 키 기반 클러스터링 | O | X |
| 데이터 저장 방식 | PK 순서대로 정렬된 B+Tree | Heap(삽입 순서대로) |
| 세컨더리 인덱스 | PK 포함 | RowID 포함 |
| RowID | 숨겨진 PK | 물리적 포인터 |
MyISAM에서 ROWID 구조
MyISAM 테이블의 모든 레코드는 ROWID(파일 내부 offset)을 가짐
-> PK든 인덱스든 "데이터 파일의 물리적 위치"를 가리킴
=> 인덱스 레벨에서는 빠름(단순 포인터)
=> 하지만 데이터 파일이 Heap이기 때문에 레인지 스캔은 InnoDB보다 느림
ROWID 저장 방식 두 가지
1. 고정 길이 ROWID (4바이트)
→ MAX_ROWS 옵션으로 최대 개수를 지정한 경우
- 가변 길이 ROWID (2~7바이트)
→ 기본값
→ 파일 최대 크기 256TB까지 가능
→ myisam_data_pointer_size=8 로 하면 64PB까지 가능
기술 블로그