MySQL 엔진 아키텍처

728x90

MySQL의 구조

MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분되어 있다.

MySQL 엔진

Connection Handler : 커넥션 및 쿼리 요청을 담당
SQL Interface : DML, DDL, Procedure, View 등 SQL의 인터페이스 제공 담당
SQL Parser : SQL 문법 오류 탐지 및 SQL 쿼리 문장을 MySQL이 처리하기 좋은 토큰 단위로 나눠서 트리 형태로 파싱하는 작업 담당
SQL Optimizer : 쿼리의 최적화된 실행 담당
캐시와 버퍼 : 성능 향상을 위한 보조 저장소 기능 담당

스토리지 엔진

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분을 전담
MySQL 엔진과 플러그인 형태로 연동/분리 가능하고 핸들러 API(핸들러 요청)를 통해 스토리지 엔진에 읽기/쓰기 요청이 가능

MySQL 스레딩 구조

Foreground Thread

클라이언트 사용자가 요청하는 쿼리 문장을 처리
데이터 조회 스레드(데이터 버퍼나 캐시 또는 직접 디스크나 인덱스 파일로 접근하여 데이터를 가져오는 스레드)
포그라운드 스레드의 경우 'thread-cache-size' 설정 값에 따라 일정 스레드 개수로 유지됨

Background Thread

MyISAM의 경우 별로 해당 사항이 없는 부분이지만 InnoDB는 다음과 같은 작업이 백그라운드로 처리됨
- Insert Buffer를 병합하는 스레드
- 로그 기록 스레드
- InnoDB 버퍼 풀의 데이터를 디스크로 기록하는 스레드
- 데이터를 버퍼로 읽어 오는 스레드
- 잠금이나 데드락을 모니터링 하는 스레드

InnoDB vs MyISAM
InnoDB
- 트랜잭션 처리가 필요하고 대용량의 데이터를 다루는 부분에서 효율적
- 데이터의 변화가 많은 서비스에 적합
- 트랜잭션에 안전한 테이블을 제공하는 트랜잭션-세이프 스토리지 엔진
- MyISAM과 비슷하지만 ORACLE 처럼 많은 기능을 지원
- commit, rollback, 장애복구, row-level locking, 외래키 등
- CPU 효율은 어느 디스크 기반의 데이터 베이스와 비교해도 우수하고, 자체적으로 메인 메모리 안에 데이터 캐싱과 인덱싱을 위한 버퍼 풀을 관리
- MyISAM과 다른 점으로 테이블과 인덱스 테이블스페이스에 저장을 하고 테이블스페이스는 몇 개의 서버파일이나 디스크 파티션으로 구성되어 있음
- InnoDB 테이블은 OS의 파일 사이즈가 한계가 2GB이더라도 상관없이 어느 크기나 가질 수 있다. 따라서 높은 퍼포먼스가 필요한 대용량 사이트에 적합

MyISAM
- 트랜잭션 처리가 필요 없고, Read only 기능이 많은 서비스일수록 효율적
- 비-트랜잭션-세이프(Non-transaction-safe)테이블을 관리
- 전체 문장 검색 능력 뿐만 아니라, 고성능 스토리지 및 복구기능을 제공
- 모든 MySQL 구성에서 지원되며, 다른 타입의 엔진으로 디폴트 구성하지 않는 한 이 엔진이 디폴트 스토리지 엔진 으로 구성됨
- 블로그, 게시판처럼 한 사람이 글을 쓰면 다른 많은 사람이 글을 읽는 방식에 최적의 성능을 발휘함

메모리 구조와 할당

MySQL 메모리 구조는 크게 글로벌 메모리 영역과 로컬(세션) 메모리 영역으로 나눌 수 있다. 글로벌 영역은 많은 스레드에 의해 공유되는 영역이고, 로컬 영역은 많은 스레드에 의해 공유되지 않는 독립적인 영역이다.

글로벌 메모리
- MySQL 서버를 실행할 때 운영체제로부터 설정한 만큼 할당받는 영역
- 모든 스레드로부터 공유되는 영역

로컬(세션) 메모리
- 클라이언트 스레드가 쿼리를 처리하는 데 쓰이는 영역
- 스레드 별로 독립적이라 절대 공유되지 않는 영역
- 쿼리의 용도 별로 할당이 될 때도 있고 아예 할당이 되지 않을 때도 있음

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

MySQL의 독특한 구조 중 대표적인 것이 플러그인 모델이다.

수 많은 사용자의 요구 조건을 만족시키기 위해 기본적으로 제공되는 스토리지 엔진 외에 부가적인 기능을 더 제공하는 스토리지 엔진을 개발하여 플러그인 형태로 제공할 수 있다. 따라서 플러그인 형태로 빌드된 스토리지 엔진 라이브러리를 다운로드해서 끼워 넣기만 하면 손쉽게 부가적인 기능도 사용할 수 있게 된다.

MySQL 서버에는 스토리지 엔진뿐만 아니라 다양한 기능을 플러그인 형태로 지원한다.

인증이나 전문 검색 파서 또는 쿼리 재작성과 같은 플러그인이 있으며, 비밀번호 검증과 커넥션 제어 등에 관련된 다양한 플러그인이 제공된다. 이뿐만 아니라 MySQL 서버의 기능을 커스텀하게 확장하거나 새로운 기능을 플러그인을 이용해 구현할 수도 있다.

쿼리 실행 구조

쿼리 실행 관점에서 MySQL 의 구조를 그림으로 표현하면 다음과 같다.

파서(Parser)가 들어온 쿼리 문장에 대해서 문법을 확인하고 적절한 단위로 분할하여 파서 트리를 만든다.
전처리기(pre-processor)가 앞에서 만들어진 파서 트리를 보고 구조적으로 문제가 있는지 확인한다. (예를 들면, 없는 테이블, 컬럼 등에 접근한다거나 테이블에 접근하려고 보니 권한이 없다거나 하는 등..)
옵티마이저가 요청받은 쿼리를 어떻게 하면 가장 적은 비용으로 빠르게 즉, 최적으로 처리할지를 결정한다. 앞으로 개발자가 해야 할 일은 이 옵티마이저가 더 나은 결정(실행 계획 생성)을 할 수 있도록 쿼리를 작성하는 것
실행 엔진은 옵티마이저에 의해 결정된 실행 계획대로 핸들러에게 지시한다.
핸들러(스토리지 엔진)는 실행 엔진이 내려준 지시대로 작업을 수행한다.

쿼리 캐시

쿼리 캐시는 빠른 응답을 필요로 하는 웹 기반 응용 프로그램에서 매우 중요한 역할을 담당했지만, 테이블의 데이터가 변경되면 캐시에 저장된 결과에서 해당 테이블과 연관된 모든 것들을 삭제해야 하므로 동시 처리 성능 저하를 유발하는 문제점이 있었다.

결국 MySQL 8.0에서는 쿼리 캐시에 대한 기능이 완전히 제거되었고 관련된 시스템 변수도 모두 제거됐다.

스레드 풀

내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이는 것이 목적이다.

스레드 그룹의 모든 스레드가 일을 처리하고 있다면 스레드 풀은 해당 스레드 그룹에 새로운 작업 스레드를 추가할지, 아니면 기존 작업 스레드가 처리를 완료할 때까지 기다릴지를 판단해야 한다. 스레드 풀의 타이머 스레드는 주기적으로 스레드 그룹의 상태를 체크해서 thread_pool_max_threads 시스템 변수에 설정된 개수를 넘어설 수 없다.