MySQL

MySQL 아키텍처

MySQL의 전체 구조

MySQL 엔진

클라이언트로부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룹니다. 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS 두뇌에 해당하는 처리를 수행합니다.

스토리지 엔진

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분을 전담합니다. MySQL 서버에서 MySQL 엔진은 하나지만 스토리지 엔진은 동시에 여러 개를 사용할 수 있습니다.

핸들러 API

MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에게 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러 요청이라고 하고 여기서 사용되는 API를 핸들러 API 라고 합니다.

MySQL 스레딩 구조

포그라운드 스레드

포그라운드 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리하는 것이 임무입니다.사용자가 작업을 마치고 커넥션을 종료하면, 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시로 돌아갑니다. 이때 이미 스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만 캐시에 존재하게 합니다.

백그라운드 스레드

인서트 버퍼를 병합하는 스레드 로그를 디스크로 기록하는 스레드, InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드, 데이터를 버퍼로 읽어들이는 스레드, 그리고 기타 여러 가지 잠금이나 데드락을 모니터링하는 스레드가 있습니다.

메모리 할당 및 사용 구조

글로벌 메모리 영역

글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 무조건 운영체제로부터 할당됩니다. 글로벌 메모리 영역은 하나의 메모리 공간만 할당되며 모든 스레드에 의해 공유됩니다.

로컬 메모리 영역

MySQL 서버상에 존재하는 포그라운드 스레드가 쿼리를 처리하는데 사용되는 메모리 영역입니다. 로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는다는 특징이 있습니다. 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다는 점입니다.

MySQL 엔진과 스토리지 엔진의 영역 처리

SQL 파서 <-> SQL 옵티마이저 <-> SQL 실행기 <-> 데이터 읽기/쓰기 <-> 디스크 스토리지

MySQL에서 쿼리가 실행되는 과정을 크게 나눈다면 거의 대부분의 작업이 MySQL 엔진(SQL 파서, 옵티마이저, 실행기)에서 처리되고, 마지막 "데이터 읽기/쓰기" 작업만 스토리지 엔진에 의해 처리됩니다.하지만, 실질적인 GROUP BY나 ORDER BY등 많은 복잡한 처리는 스토리지 엔진 영역이 아니라 MySQL 엔진의 처리 영역인 쿼리 실행기에서 처리됩니다.

쿼리 실행 구조

파서

사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어내는 작업을 의미합니다. 쿼리 문장의 기본 문법 오류는 이 과정에서 발견되며 사용자에게 오류 메시지를 전달하게 됩니다.

전처리기

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

옵티마이저

사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지 결정하는 역할을 합니다.

실행 엔진

실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행합니다.

MySQL의 특징

단일 코어에서 Nested Loop Join 처리(MySQL 8버전 이전)

MySQL 8버전 이전에는 모든 SQL 처리를 단일 코어에서 Nested Loop Join 방식으로만 데이터를 처리했습니다. 그리고 기본적인 스토리지 엔진은 단을 코어로 수행했습니다. 그렇기 때문에 MySQL의 성능을 높이기 위해서는 CPU 코어 개수를 늘리기 보다 Scale-Up을 하는 것이 훨씬 유리합니다. Nested Loop Join에 대한 설명은 아래 링크를 참고하시면 됩니다.

JOIN 설명 링크

다양한 스토리지 엔진

MySQL 스토리지 엔진

데이터 복제 기능

MySQL은 물리적으로 독립적인 디스크 영역에 데이터를 복제하여 데이터를 이중화할 수 있습니다.

위의 이미지는 가장 대표적인 MySQL의 Master-Salve 구조를 나타낸 그림입니다. Master에서 데이터 변경 작업이 일어나면, 해당 내역이 자동으로 슬레이브로 비동기적으로 전송되어 실제 Master의 데이터 복사본을 유지하는 것을 의미합니다. 특정 데이터 디스크 Fail 시에도 다른 무리적으로 독립적인 디스크 데이터가 존재하기 때문에 DB 버그가 아니라면 유실은 거의 없습니다. 게다가 디스크 읽기 분산이 가능하기 때문에 읽기 트래픽이 상당히 큰 효율을 갖습니다. 다만, 데이터 갱신은 오직 Master에서만 가능하기 때문에 쓰기에 관련된 부하 분산이 불가능합니다.