4.2 InnoDB 스토리지 엔진 아키텍처
- 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금 제공, 그 때문에 높은 동시성 처리가 가능
안정적이며 성능이 뛰어남
4.2.1 프라이머리 키에 의한 클러스트링
- 프라이머리 키를 기준으로 클러스터링 되어 저장.
- 프라이머리 키를 이용한 레인지 스캔은 빨리 처리됨.
4.2.2 외래 키 지원
- InnoDB 스토리지 엔진 레벨에서 지원하는 기능
- InnoDB 외래 키는 부모 테이블과 자식테이블 모두 해당 커럼에 인덱스 생성 필요. 변경 시에 부모테이블이나 자식테이블에 데이터가 있는지 체크하는 작업이 필요하므로, 그로 인해 데드락이 발생할 수 있으므로 주의 필요
4.2.3 MVCC(Multi Version Concurrency Control)
- 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능,
- 잠금을 사용하지 않는 일관된 읽기를 제공하는데 목적
- InnoDB는 언두 로그(Undo Log)를 이용해 기능 구현
- READ_UNCOMMITTED : 변경된 데이터 반환
- READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE : 변경이전 데이터 반환
4.2.4 잠금 없는 일관된 읽기(Non-Locking Consistent Read)
InnoDb 스토리지 엔진은 MVCC 기술을 이용해 잠금을 걸지 않고 읽기 작업 수행
- SERIALIZABLE이 아닌경우 INSERT와 연결되지 않은 순수한 읽기(SELCECT)작업은 다른 트랜잭션의 변경 작업과 관계없이 바로 실행
- 언두 로그 사용
4.2.5 자동 데드락 감지
- InnoDB 스토리지 엔진은 내부적으로 잠금이 교착 상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록을 그래프(Wait-for List) 형태로 관리한다.
- InnoDB 스토리지 엔진의 데드락 감지 스레드는 주기적으로 잠금 대기 그래프 를 검사해 교착 상태에 빠진 트랜잭션을 찾아 강제 종료 한다.
- 언두 로그 레코드를 적게가진 트랜잭션이 일반적으로 롤백의 대상
4.2.6 자동화된 장애 복구
- InnoDB 데이터 파일은 기본적으로 MySQL 서버가 시작될 때 항상 자동 복구를 수행
4.2.7 InnoDB 버퍼 풀
- 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간
- 쓰기작업을 일괄 작업을 처리하는 버퍼역할도 수행
4.2.7.1 버퍼 풀의 크기 설정
- MySQL 5.7 버전부터 InnoDB 버퍼 풀의 크기 동적 조절 가능
- 내부 잠금 경합을 줄이기 위해 버퍼 풀을 여러 개로 쪼개어 관리할수 있게 가능.
4.2.7.2 버퍼 풀의 구조
4.2.7.3 버퍼 풀과 리두 로그
- 버퍼 풀의 메모리 공간만 늘리는것은 데이터 캐시기능만 향상
- 쓰기 버퍼링 기능 향상을 위해서는 InnoDB 버퍼 풀과 리두 로그와의 관계를 이해아혀야함.
4.2.8 Double Write Buffer
- InnoDB 스토리지 엔진의 리두로그는 공간의 낭비를 막기위해 페이지의 변경된 내용만 기록
일부만 기록되는 현상 - Patial-page or Torn-page
- 이런 현상은 오작동 또는 시스템 비정상 종료를 발생 시킴으로 Double Write 기법을 이용
4.2.9 언두 로그
트랜잭션 보장, 격리수준 보장
- 백업된 데이터
4.2.9.1 언두 로그 레코드 모니터링
4.2.9.2 언두 테이블스페이스 관리
4.2.10 체인지 버퍼
InnoDB는 변경해야할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하지만, 디스크로 부터 읽어와서 업데이트를 해야한다면 이를 임시 공간에 저장해두고 바로 사용자에게 결과를 반환하는 형태로 성능을 향상 시키게 되는데, 이때 사용하는 임시 메모리 공간은 체인지 버퍼(Change Buffer)라고 한다.
Programmer?