Inno DB란?
Transaction-safe 한 기본 MySQL Storage Engine이다.
높은 안정성과 고성능을 가지고 균형을 이룬 범용 스토리지 엔진이다. CREATE TABLE문을 실행하면 자동으로 InnoDB 테이블 생성된다.
※ MyISAM와의 차이점: InnoDB와 다르게 table과 index를 각각의 다른 파일로 관리함, Read Only기능면에서는 효율적인 서비스
InnoDB 엔진 주요 특징
□□ Tablespace : Segment(오브젝트)라는 □□의 논리적 저장공간의 집합, 크기조절 가능
- InnoDB 테이블은 기본 키를 기반으로 쿼리를 최적화하기 위해 디스크의 데이터를 정렬한다. 각 InnoDB 테이블에는 기본 키 조회를 위한 I/O를 최소화하기 위해 데이터를 구성하는 클러스터형 인덱스라는 기본 키 인덱스가 있다.
클러스터링 : 여러개를 하나의 기준으로 묶는다. - Row Lv 락은 멀티 유저의 동시성과 성능을 향상시켜준다.
- 락을 걸지않고 작업을 수행하면서, 다른 트랜잭션이 갖고있는 락을 기다리지않고 읽기 작업이 가능함 (MVCC라고도 한다. Multi verson Concurrency Control)
- In-memory 구조로 데이터와 인덱스를 메모리에 캐싱하기 위한 Buffer Pool이 있다.
- 데이터의 무결성을 지키기 위해 외래키 제약조건을 지원한다. 외래키를 사용하면 관련 테이블간에 불일치가 발생하지 않도록 CRUD를 검사한다.
Buffer Pool
버퍼풀은 InnoDB를 엑세스할때 테이블과 인덱스 데이터를 캐시하는 메인메모리 영역이다.
자주 사용하는 데이터를 메모리에서 직접 접근할 수 있도록 해서 처리속도를 높인다. 전용서버에서는 물리적 메모리의 최대 80%를 버퍼 풀에 할당한다고 한다.
버퍼풀은 LRU (Least Recently Used) 알고리즘으로 가장 최근에 사용되지 않은 페이지를 제거하고 새페이지를 풀러오는 방식으로 데이터를 관리한다.
Buffer Pool이 커지면 커질수록 캐싱되는 데이터 양이 늘어나므로 I/O를 상대적으로 적게하면서 성능이 향상된다.
Change Buffer
Change Buffer는 해당 페이지가 버퍼 풀에 없을때 secondery index 페이지에 대해 변경 사항을 캐시하는 구조이다. 페이지가 다른 읽기 작업에 의해 버퍼풀에 반영될때, Change Buffer는 DML(Insert, update, delete)의 결과값을 병합시킨다. Periodic merge(주기적 병합)을 하는 secondary index는 정렬된 순서로 삽입하는 클러스터형 인덱스와는 다르게 고유하지않고 삽입과정 또한 Randomly 하게 진행된다. 이는 최신 상태로 유지하기 위해서는 디스크에 상당한 I/O를 발생시킨다. 이러한 문제점을 해결하기 위해 DML작업이 발생하면 실시간으로 업데이트 하지않고 체인지 버퍼를 통해 변경사항을 캐시하는것이다.
체인지 버퍼의 경우 DML 후 보조 인덱스를 최신 상태로 유지하는데 사용되는 상당한 I/O를 줄일 수 있는 장점이 있지만, 다만 과거 디스크가 느린 시절에 큰 효과가 있었지 SSD 등 디스크의 성능이 개선됨에 따라 극적인 성능 개선을 가져오지는 않는다. 또한 변경 사항이 많을 경우 재부팅, 복구 작업이 지연될 수 있기에 주의해야한다. 이러한 이유 때문인지 Aurora MySQL의 경우 체인지 버퍼를 사용하지 않는다고 함.(None으로 설정되어있으며 변경 불가)
Log Buffer 와 Redo Log
Log Buffer는 디스크의 로그 파일을 기록할 데이터 보관 메모리영역이다. 기본크기는 16MB이고 주기적으로 디스크에 FLUSH된다.
Redo Log는 장애시 Buffer Pool에 저장되어 있던 데이터의 유실을 방지, 데이터를 복구 하기 위해 사용된다.
DML 문장이 수행되면 데이터가 변경되기 전에 우선 메모리에 변경할 내용을 기록한다. 변경할 내용을 기록하는 메모리 영역을 Redo Log Buffer라고 한다. 메모리 영역은 용량이 제한적이기 때문에 Checkpoint 이벤트 발생시점에 Redo Log Buffer에 있던 데이터들을 Disk에 File로 저장하게 된다. 이 파일을 Redo Log File이라 한다.
Redo Log File은 두 개의 파일로 구성되는데, 하나의 파일이 가득차면 ‘log switch’가 발생하며 다른 파일에 쓰게 된다. ‘log switch’가 발생할 때마다 Checkpoint 이벤트도 발생하는데, 이때 InnoDB Buffer Pool Cache에 있던 데이터들이 백그라운드 스레드에 의해 디스크에 기록된다. 다시말하자면, Checkpoint 이벤트가 발생하기전 장애가 발생한다면 Buffer Pool에 있던 데이터들은 유실되지만 마지막 Checkpoint가 수행된 시점 or log switch까지의 데이터가 Redo Log File로 남아있기 때문에 이 파일을 사용하여 데이터를 복구할수 있다.
Undo log의 작동 예시
Undo log는 디비 작업이 잘못되었을때 되돌리는것
DISK 내에 ID 3의 데이터가 저장되어있는 상황에 ID 3을 저장하려고 했을때를 가정
INSERT INTO test (ID) VALUES (1), (2), (3); // TEST 테이블에 명령어를 입력했을때
- DISK 에는 TEST ID가 3 값을 지니고 있는 상황. VALUES의 값들을 버퍼 풀에다가 넣음
| Buffer Pool | Disk | Undo Log |
|---|---|---|
| ID | ID | |
| 1 | 3 | |
| 2 | ||
| 3 |
- DISK에 해당 작업을 수행하기전 Undo Log에 DISK 내용을 기록을 남겨둔다.
| Buffer Pool | Disk | Undo Log |
|---|---|---|
| ID | ID | ID |
| 1 | 3 | 3 |
| 2 | ||
| 3 |
- 그 후 버퍼 풀 작업을 아래와같은 작업을 수행함 하지만 수행중 기본키 중복조건으로 롤백하는 상황이 발생함
| Buffer Pool | Disk | Undo Log |
|---|---|---|
| ID | ID | ID |
3 | 1 | 3 |
| 2 | ||
3 |
- 기존 DISK 작업을 날리고(123) Undo Log의 데이터(3)를 가져오면서 롤백이 되고 해당 트랜잭션이 종료된다.
| Buffer Pool | Disk | Undo Log |
|---|---|---|
| ID | ID | |
| 3 | 3 | |
참고자료
https://dev.mysql.com/doc/refman/8.0/en/
https://jojoldu.tistory.com/243