[Real MySQL 8.0] 4장 아키텍처 (2) (3일차)

4.2 InnoDB 스토리지 엔진 아키텍처

• InnoDB 는 MySQL 에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반 잠금을 제공한다
  • 즉, 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다
• 프라이머리 키 클러스터링
  • 모든 테이블은 프라이머리 키를 기준으로 클러스터링되어 저장된다
• 외래 키 지원
  • MyISAM 이나 MEMORY 테이블은 불가능
  • 부모, 자식 테이블에서 해당 칼럼에 인덱스 생성이 필요
  • 변경 시 부모, 자식 테이블에서 해당 데이터를 확인
  • 데드락 가능성도 존재
• MVCC (Multi Version Concurrency Control)
  • 레코드 레벨의 트랜잭션을 지원하는 DBMS 가 지원하는 기능이다
  • 잠금을 사용하지 않는 일관된 읽기를 제공하는 것이 목적
  • 하나의 레코드에 여러 버전이 동시에 관리된다는 의미
  • Update
    • Update 쿼리가 실행되면 커밋의 실행 여부와 관계없이 InnoDB 버퍼 풀은 새로운 값으로 업데이트 된다
    • 디스크(데이터 파일) 은 커밋 여부나 동기화에 따라 업데이트 여부를 확인할 수 있다
    • Undo 로그에는 변경 이전의 데이터가 존재한다.
    • 즉, 3가지 영역이 존재하며 InnoDB 는 Undo 로그와 버퍼 풀이 따로 존재하기에 여러 버전이 동시에 관리될 수 있다
• 잠금 없는 일관된 읽기 (Non-Locking Consistent Read)
  • InnoDB 는 MVCC 를 사용해 잠금 없이 읽기를 수행한다
• 자동 데드락 감지
  • 잠금 대기 목록을 그래프 형태로 관리한다
  • 데드락 감지 스레드를 별도로 가져 주기적으로 그래프를 검사해 해당 트랜잭션 중 하나를 강제 종료한다
    • 트랜잭션 선택 기준은 언두 로그 양이 적은 트랜잭션이다
    • 롤백 시 서버의 부하가 적기 때문
• 자동화된 장애 복구
  • 서버 시작 시 완료되지 못한 트랜잭션이나 복구 작업이 자동으로 진행
  • 설정 파일에 innodb_force_recovery 시스템 변수를 통해 선별적으로 복구 진행
  • 그래도 안되면 백업 데이터베이스 + 바이너리 로그
• InnoDB 버퍼 풀
  • 가장 핵심적인 부분
  • 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해두는 공간
  • 거대한 메모리 공간을 페이징 처리
  • LRU + MRU 알고리즘으로 메모리 관리
  • 리두 로그
    • 리두 로그 파일의 공간은 계속 순환되어 사용된다
    • 매번 기록할 때마다 로그 포지션은 LSN (Log Sequence Number) 라는 계속 증가되는 값을 가진다
    • 스토리지 엔진은 주기적으로 체크포인트 이벤트를 발생시켜 리두 로그와 버퍼 풀의 더티 페이지를 디스크로 동기화한다
      • 이때 가장 최근 체크포인트 지점의 LSN 이 활성 리두 로그 공간의 시작점이 된다 
      • 해당 LSN 이전은 모두 동기화 되었으므로 비활성이라 볼 수 있다.
    • 리두 공간을 재사용하기 위해서는 반드시 오래된 리두 로그 엔트리를 지워야한다
      • 이를 위해서 반드시 더티 페이지가 먼저 디스크로 동기화되어야한다
      • 스토리지 엔진이 플러시 리스트 함수를 통해 순서대로 동기화 작업을 진행한다
      • 디스크 I/O 작업이기 때문에 한 번에 얼마나 많은 더티 페이지를 기록하느냐가 성능에 큰 영향을 미친다
  • Double Write
    • 데이터의 안정성을 위한 옵션
    • 플러시를 진행할 때 더티 페이지들을 모두 묶어 한 번의 디스크 쓰기로 DoubleWrite 버퍼에 기록한다
    • 이후 플러시가 중간에 실패할 경우 해당 버퍼와 디스크를 비교해 복구하는 방법이다
• 언두 로그
  • 트랜잭션과 격리 수준을 보장하기 위해 이전 버전의 데이터를 별도로 백업하며 이 데이터를 언두 로그라 한다
  • 용도 1. 트랜잭션의 롤백 대비용
  • 용도 2. 트랜잭션의 격리 수준을 유지하며 높은 동시성 제공
  • 대용량 데이터 트랜잭션, 오랜 시간 실행되는 트랜잭션이 언두 로그의 양을 급증시킴
    • 하나의 트랜잭션이라도 A 시점부터 계속 활성화된다면 A 시점부터 언두 로그가 쌓이기 때문
    • 언두 로그의 레코드를 모니터링하며 관리해야한다
  • 테이블 스페이스 관리
    • 언두 로그가 저장되는 공간
    • 1개 이상의 언두 슬롯을 가진 1~128 개의 롤백 세그먼트
• 체인지 버퍼
  • 변경할 인덱스 페이지가 디스크에 있다면 임시 공간에 저장해두는 공간
• 리두 로그와 로그 버퍼
  • 리두 로그
    • 서버가 비정상적으로 종료되었을 때 데이터 파일에 기록하지 못한 데이터를 잃지 않게해주는 안전장치
    • 대부분은 데이터 변경 내용을 로그로 먼저 기록
      1. 커밋됐지만 데이터 파일에 기록되지 않은 데이터
      2. 롤백됐지만 데이터 파일에 기록된 데이터
    • 2번의 경우 리두 + 언두 로그가 필요하다
• 어댑티브 해시 인덱스
  • 사용자가 직접 생성한 인덱스가 아닌 InnoDB 에서 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스
  • B-Tree 검색 시간을 줄이기 위한 기능
  • 자주 읽히는 데이터 페이지의 키 값을 이용해 해시 인덱스를 만든다
  • 이를 통해 B-Tree 를 통하지 않고 그 즉시 데이터 페이지를 찾아갈 수 있다
• InnoDB vs MyISAM vs MEMORY
  • 전문 검색이나 공간 좌표 검색 기능
    • MyISAM 만 지원했다가 8.0 부터 InnoDB 에서도 지원
  • 하나의 스레드에서만 데이터를 읽고 쓴다면 MEMORY 가 InnoDB 보다 빠를 수 있다
    • 하지만 그러한 환경이 없다