InnoDB의 Buffer Pool, MVCC

mysql 에서도 I/O 연산을 줄이기 위한 Buffer Pool을 이용해 속도차이를 개선했다는 것이 신기하다.

Redis 도 in-memory 기반의 cache 서버로 DB 부하를 줄일다는 것이 기억났다.

기술발전에 따라 다양한 방법으로 속도 개선이 이루어지는 것을 알 수 있다.

 

또한 생각해볼 점은 Buffer Pool 이 메모리를 사용한다는 점이다. 

만약 Buffer Pool보다 큰 작업을 수행하게 되면 이점없이 I/O 작업이 늘어나게 될 것이다. 

Buffer Pool 사이즈를 변경하거나, 쿼리문, index 또는 unique 작업 등을 수정해봐야 겠다는 생각이 들었다. 

 

---

MySQL

• 크게 MySQL 엔진과 Storage 엔진으로 구분

MySQL 엔진

• 요청 쿼리에 대해 어떻게 실행할지 결정하는 역할

InnoDB

특징

• 버퍼풀, 데드락 감지, MVCC, 클러스터링 인덱스, 등등 기능 지원
• 버퍼풀과 MVCC에 대해 알아보고자 한다. 

버퍼풀

• MySQL엔진에서 사용하는 메모리 영역
• 쓰기 작업 최적화
  
  • 요청 데이터가 버퍼풀에 있다면 바로 I/O 작업하지 않고 모았다가 실행한다. 
  • 물론 예외도 존재한다. 
• 테이블과 인덱스 데이터를 캐싱
• 디스크 저장단위인 page 단위로 데이터 관리
  • index는 공간 지역성 이점
  • 인덱스나 데이터가 클러스터형 인덱스를 통해 정렬된 상태로 page에 저장
  • 따라서 물리적으로 인접한 페이지에 있는 데이터도 논리적으로 연속된 데이터일 가능성이 높음
  • 예를 들어, 테이블의 기본 키로 정렬된 행이 저장된 페이지가 메모리에 로드되면, 해당 페이지에서 바로 인접한 데이터를 읽는 연산도 버퍼풀 이용
• LRU 알고리즘으로 데이터를 관리
  • 제일 많이 사용하지 않은 데이터를 탈락. (시간 지역성 관리)
  • new sub set과 old sub set으로 나뉘어 관리

 

 

MVCC (Multi-Version Concurrency Version)

• 원본 데이터를 여러 version으로 관리하여 동시성 처리
• 대량 요청에 따른 성능 감소 방지

1) 현재 버퍼풀 상태 

 

 

2) 두 Transaction A, B가 동시에 수행되는 상황

 

• transaction A: 음식 이름을 ‘파스타’에서 ‘라면’으로 변경
  • 버퍼 풀은 변경된 데이터 저장
  • 언두 로그는 변경 전 데이터 저장
• transaction A가 commit 전, 다음 isolation의 transaction B 가 수행된다면?
  • 만약 tx B가 read_uncommited 격리수준 일때, ‘파스타’이름으로 조회하면?
    • 버퍼풀 데이터를 조회하여 아무값도 조회 불가
  • 만약 tx B가 read_commited / repeatable_read 격리수준 일때, ‘파스타’ 이름을 조회하면?
    • 언두 로그를 조회하여 데이터 조회 가능