[DB] MySQL 아키텍처: 스토리지 엔진

🔍 스토리지 엔진

   MySQL의 스토리지 엔진에서 가장 많이 사용되는 InnoDB에 대해서 알아보자. 앞으로 스토리지 엔진이라고 하면 InnoDB 스토리지 엔진이다.

InnoDB 스토리지 엔진 아키텍처

다음은 InnoDB 스토리지 엔진의 아키텍처 도식도이다. 세부적으로 표현되어야 할 부분은 뒤에서 자세히 설명할 것이다. 

 

🔍 InnoDB의 특징

✏️ 프라이머리 키에 의한 클러스터링

   InnoDB의 모든 테이블은 PK를 기준으로 클러스터링되어 저장된다. 클러스터링이란 특정 열의 값을 기준으로 데이터를 정렬하여 디스크 상에서 서로 인접하게 저장해주는 기술이다. 즉, InnoDB의 모든 테이블은 PK값을 기준으로 비슷한 값들이 모여 있다. 이는 범위 검색을 빠르게 처리할 수 있게 해준다. 

 

✏️ MVCC(Multi Version Concurrency Control)

   Multi Version이란 하나의 레코드에 대해서 여러 버전의 레코드 값이 존재함을 의미할 수 있음을 의미한다. 예를 들면 다음과 같은 테이블이 있고 학생의 grade가 잘못 되어 수정한다고 해보자. 

테이블 예시

다음과 같은 UPDATE 쿼리문을 날리 수 있다.

UPDATE student SET studnet.grade = 1 WHERE student.id = 2

 

InnoDB가 이를 처리하는 과정에 다음과 같은 쿼리문을 날리면 Mango의 학년은 1로 나올까 ? 2로 나올까?

SELECT * FROM student WHERE student.id = 2;

이는 트랜잭션 격리 수준에 따라 달라질 것이다. 격리 수준이 READ_UNCOMMITTED인 경우에는 2로 나올 것이다. 만약 READ_COMMITED나 그 이상의 격리 수준이라면 1로 나올 것이다. 이것이 어떻게 가능할까?

 

이를 이해하기 위해 InnoDB 스토리지 엔진의 구조를 좀 더 자세히 살펴보자.

InnoDB 스토리지 엔진의 세부 아키텍처

• 언두 페이지 : InnoDB 트랜잭션의 롤백을 지원하기 위해 사용되는 메커니즘. 롤백이 필요한 경우, 언두 페이지를 이용하여 변경된 데이터를 이전 상태로 복원하고, 해당 변경 사항을 디스크에 반영하지 않고 삭제하여 롤백한다.
• 체인지 버퍼 : InnoDB는 데이터를 페이지 단위로 디스크에 기록하는데, 변경된 데이터가 바로 디스크에 기록되는 것이 아니라, 먼저 체인지 버퍼에 기록된다. 
• 데이터 페이지 버퍼 : 데이터를 메모리에 캐싱하여 데이터베이스의 성능을 향상시키는 데 사용된다. 

 

이제 UPDATE 쿼리문이 날라갔을 때 InnoDB의 언두 로그에 다음과 같은 레코드가 생긴다. 

InnoDB 버퍼 풀과 언두 로그

이때, SELECT문을 날리면 READ_UNCOMMITED는 언두 로그에서 데이터를 읽어오고 READ_COMMITED 이상의 트랜잭션 락은 버퍼 풀에서 데이터를 읽어온다. 

UPDATE 이후 COMMIT 명령을 내리면 InnoDB는 변경 작업 없이 지금의 상태를 영구적인 데이터로 만들어 버린다. 롤백이 필요한 경우에는 언두 영역에 있는 백업 데이터를 InnoDB 버퍼 풀로 복구하고, 언두 영역의 데이터를 삭제한다. 

 

✏️자동 데드락 감지

    InnoDB 스토리 엔진은 데드락 감지 스레드를 가지고 있어서 잠금 대기 그래프를 주기적으로 체크하고, 교착 상태에 빠진 트랜잭션들을 찾아서 그 중 하나를 종료시킨다. 기준은 언두 로그 레코드를 더 적게 가진 트랜잭션이 일반적으로 롤백이 된다.

 

✏️ 자동화된 장애 복구

   InnoDB에는 손실이나 장애로부터 데이터를 보호하기 위한 여러 가지 메커니즘이 있다. 이러한 메커니즘을 이용해 MySQL 서버가 시작될 때 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지 등에 대한 일련의 복구 작업이 자동으로 이루어진다.

 

🔍 InnoDB 버퍼 풀

    디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할을 하기도 한다. InnoDB 버퍼 풀은 내부적으로 128MB 청크 단위로 쪼개어 관리되며, 이는 버퍼 풀의 크기를 줄이거나 늘리기 위한 단위 크기로 사용된다. 

✏️ 버퍼 풀의 구조 

스토리지 엔진은 버퍼 풀이라는 거대한 메모리 공간을 페이지 크기의 조각으로 쪼개어 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 데이터 페이지를 읽어서 각 조각에 저장한다.

버퍼 풀은 LRU 리스트를 관리함으로써 한 번 읽어온 데이터를 메모리에 유지해서 디스크 읽기를 최소화한다. LRU가 동작하는 방식은 다음과 같다.

버퍼 풀 동작 방식 (LRU 리스트)

1. 필요한 데이터가 버퍼 풀에 있는지 검사한다. 
   • 이때 InnoDB 어댑티브 해시 인덱스를 이용하여 페이지를 검색한다.
   • 버퍼 풀이 이미 데이터 페이지에 있다면 해당 페이지의 포인터를 MRU 방향으로 승급한다. 
2. 디스크에서 필요한 데이터 페이지를 버퍼 풀에 적재하고, 적재된 페이지에 대한 포인터를 LRU 헤더 부분에 추가한다. 
3. 버퍼 풀의 LRU 헤더 부분에 적재된 데이터 페이지가 실제로 읽히면 MRU 헤더 부분으로 이동한다. 
4. 버퍼 풀에 상주하는 데이터 페이지는 사용자 쿼리가 얼마나 최근에 접근했었는지에 따라 나이가 부여되고, 오랫동안 사용되지 않으면 해당 버퍼 풀에서 제거 된다. 

 

✏️ 버퍼 풀과 리두 로그

   InnoDB 버퍼 풀은 데이터베이스 서버의 성능 최적화를 위해 데이터 캐시와 버퍼링이라는 두 가지 옵션을 제공한다. 버퍼 풀의 메모리 공간만 단순히 늘리는 것은 데이터 캐시 기능만 향상시키는 것이다. 버퍼링 기능을 향상시키기 위해서는 버퍼 풀과 리두 로그와의 관계를 이해해야 한다.

InnoDB의 버퍼 풀은 디스크에서 읽은 상태로 변경되지 않은 클린 페이지와 변경된 더티 페이지를 가지고 있다. 더티 페이지는 디스크와 메모리의 데이터 상태가 다르기 때문에 디스크에 기록되어야 한다. 버퍼 풀의 더티 페이지는 특정 리두 로그 엔트리와 관계를 가지고, 주기적으로 디스크에 동기화된다.

버퍼 풀과 리두 로그

버퍼 풀이 50GB이며 리두 로그 파일의 전체 크기가 50MB인 경우에는 버퍼링 효과를 전혀 못게 되고, 버퍼 풀이 50Mb이고 리두 로그 파일의 전체 크기가 50GB라면 최대 허용 가능한 더티 페이지는 대략 50MB가 된다. 후자의 경우에는 급작스러운 디스크 쓰기가 발생할 가능성이 높다. (메모리의 90%가 사용되어 InnoDB가 데이터를 대량으로 처리하는 현상). 따라서 적절한 리두 로그 파일의 크기를 선택하는 것이 중요하다.

 

🔍 언두 로그

   트랜잭션과 격리 수준을 보장하기 위해 데이터 변경 쿼리가 오면 변경되기 이전 데이터를 백업한다. 이렇게 백업된 데이터를 언두 로그라고 한다. 

이런 언두 로그는 대용량의 데이터를 처리하는 경우 또는 오랜 시간 동안 실행될  때 양이 급격히 증가할 수 있다. 예를 들어 다음과 같은 경우 트랜잭션 B와 C는 작업이 끝났음에도 불구하고 트랜잭션 A가 끝날 때까지 언두 로그는 정리할 수 없다.

T(A) : BEGIN --> SELECT ---------------------------------------------->
T(B) :             BEGIN -> UPDATE -> COMMIT
T(C) :                       BEGIN -> DELETE -> COMMIT

이런 문제점은 MySQL 8.0부터는 언두 로그의 디스크 공간을 조절기능이 도입되면서 사라졌다.

 

🔍 체인지 버퍼

   데이터베이스에 새로운 레코드가 Insert되거나 Update될  때는 인덱스를 업데이트하는 작업도 필요하다. 인덱스를 업데이트하는 작업은 랜덤하게 디스크를 읽는 작업이 필요하므로 임시 저장 공간인 체인지 버퍼에 저장해 두고 나중에 한 번에 업데이트 한다.