[MySQL] MySQL 엔진 아키텍처

MySQL 스레딩 구조

MySQL 서버는 스레드 기반으로 작동하며, 포그라운드(Foreground)와 백그라운드(Background) 스레드로 구분할 수 있습니다.

포그라운드 스레드(클라이언트 스레드)

포그라운드 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며, 각 클라이언트가 요청하는 쿼리 문장을 처리합니다. 클라이언트가 작업을 마치고 커넥션을 종료하면 스레드는 스레드 캐시(Thread cache)로 돌아갑니다.

스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면 스레드를 종료시켜 일정 개수의 스레드만 유지합니다. 스레드 캐시에 유지할 수 있는 최대 스레드 개수는 thread_cache_size 시스템 변수로 결정합니다.

포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우 디스크 또는 인덱스로부터 데이터를 읽어와서 작업을 처리합니다. 디스크 쓰기 작업의 경우 InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리합니다.

백그라운드 스레드

InnoDB는 여러 가지 작업을 백그라운드 스레드로 처리합니다.

• 인서트 버퍼(Insert Buffer)를 병합하는 스레드
• 로그를 디스크로 기록하는 스레드
• InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
• 데이터를 버퍼로 읽어 오는 스레드
• 잠금이나 데드락을 모니터링하는 스레드
  
  

이 중 백그라운드 스레드의 가장 중요한 역할은 로그 스레드(Log thread)와 버퍼의 데이터를 디스크로 내려쓰는 작업을 처리하는 쓰기 스레드(Write thread)입니다.

InnoDB를 포함한 일반적인 DBMS는 쓰기 작업을 버퍼링해서 일괄처리하기 때문에 쓰기 작업이 완료될 때까지 기다릴 필요가 없습니다.

메모리 할당 및 사용 구조

글로벌 메모리 영역

일반적으로 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당됩니다. 필요에 따라 2개 이상의 공간을 할당받을 수 있지만 모든 스레드에 의해 공유됩니다.

대표적인 글로벌 메모리 영역은 다음과 같습니다.

• 테이블 캐시
• InnoDB 버퍼 풀
• InnoDB 어댑티브 해시 인덱스
• InnoDB 리두 로그 버퍼
  
  

로컬 메모리 영역

MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역입니다. 대표 적인 것이 커넥션 버퍼와 소트 버퍼입니다. 클라이언트와 MySQL 서버와의 커넥션을 세션이라고 하기 때문에 로컬 메모리 영역을 세션 메모리 영역이라고도 표현합니다.

• 로컬 메모리 영역은 각 클라이언트 스레드별로 독립적으로 할당
• 필요에 따라 할당하거나 할당하지 않을 수 있음
• 커넥션이 열려 있는 동안 계속 할당된 상태로 있을 수도 있고(커넥션 버퍼, 결과 버퍼) 쿼리 실행 후 곧바로 해제하는 공간(소트 버퍼, 조인 버퍼)도 있음
  
  

대표적인 로컬 메모리 영역은 다음과 같습니다.

• 소트 버퍼
• 조인 버퍼
• 바이너리 로그 캐시
• 네트워크 버퍼
  
  

플러그인 스토리지 엔진 모델

MySQL은 스토리지 엔진 뿐만 아니라 필요에 따라 여러 플러그인을 선택 또는 개발할 수 있습니다.

핸들러(handler): MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하는 역할을 수행

컴포넌트

MySQL 8.0부터는 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원됩니다. 플러그인은 다음과 같은 단점을 가지고 있으며, 컴포넌트는 이러한 단점을 보완하여 구현됐습니다.

• 플러그인은 오직 MySQL 서버와 인터페이스할 수 있고, 플러그인끼리는 통신 불가
• 플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 안 됨)
• 플러그인은 상호 의존 관계를 설정할 수 없어서 초기화가 어려움
  
  

쿼리 실행 구조

쿼리 파서

• 요청 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조(파서 트리)로 만들어 내는 작업을 수행
• 문법 오류가 발견되면 사용자에 오류 메시지를 전달
  
  

전처리기

• 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인
• 각 토큰을 테이블 이름, 컬럼 이름, 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 수행
• 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러짐
  
  

옵티마이저

• 옵티마이저는 사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리하기 위한 방법을 결정하는 역할을 담당
• DBMS의 두뇌에 해당
  
  

실행 엔진

• 실행 엔진은 옵티마이저의 실행 계획에 따라 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행
  1. 실행 엔진이 핸들러에게 임시 테이블을 만들라고 요청
  2. 다시 실행 엔진은 WHERE 절에 일치하는 레코드를 읽어오라고 핸들러에게 요청
  3. 요청 -> 요청 결과를 다시 다른 요청의 입력으로 전달하는 과정을 반복
  4. 최종적으로 실행 엔진은 결과를 사용자나 다른 모듈로 넘김
     
     

핸들러(스토리지 엔진)

• 핸들러는 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당
• InnoDB 테이블을 조작하는 핸들러가 바로 InnoDB 스토리지 엔진
  
  

쿼리 캐시

MySQL 8.0부터 쿼리 캐시는 MySQL 서버의 기능에서 완전히 제거되었습니다.

쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하여 매우 빠른 성능을 보였습니다. 그러나 테이블의 데이터가 변경되면 변경된 테이블과 관련된 캐시 데이터는 모두 삭제해야 하기 때문에 동시 처리 성능 저하를 유발합니다.

스레드 풀

스레드 풀 기능은 MySQL 커뮤니티 에디션에서는 제공하지 않으며 엔터프라이즈 에디션에서 제공됩니다.

스레드풀을 통해 CPU가 제한된 수의 스레드 처리에만 집중하도록 유도하면 운영체제의 불필요한 컨텍스트 스위치를 줄여 오버헤드를 줄일 수 있습니다.

트랜잭션 지원 메타데이터

MySQL 8.0 버전부터는 테이블의 구조 정보나 스토어드 프로그램의 코드 관련 정보를 모두 InnoDB의 테이블에 저장하도록 개선되었습니다. 시스템 테이블과 메타데이터를 모두 모아 mysql DB에 저장합니다.

MySQL 8.0 버전 이전까지는 메타데이터를 파일로 관리하였습니다. 파일 기반의 메타데이터는 트랜잭션을 지원하지 않아 작업 도중 MySQL 서버가 종료되면 일관되지 않은 상태로 남는 문제가 있었습니다.

참고

Real MySQL 8.0 4장 아키텍처_4.1 MySQL 엔진 아키텍처