MySQL 엔진 아키텍처
Last updated
Last updated
MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구성된다.
MySQL 엔진은 사람의 머리 역할을 담당하고, 스토리지 엔진은 손과 발의 역할을 담당한다.
SQL을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행한다.
커넥션 핸들러(클라이언트로부터의 접속 및 쿼리 요청을 처리), SQL 파서, 전처리기, 옵타마이저, 캐시 & 버퍼 등등이 중심을 이룬다
실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 MySQL의 손발 역할을 전담한다.
MySQL 엔진은 하나지만, 이와 다르게 스토리지 엔진은 여러 개를 동시에 사용할 수 있다.
MySQL 엔진의 핸들러 API를 통해 호출되며, 대표적으로 InnoDB, MyIsam, Memory 등 스토리지 엔진이 존재한다.
테이블이 사용할 스토리지 엔진을 지정하면, 이후 해당 테이블의 모든 읽기 작업이나 변경 작업은 스토리지 엔진이 수행한다.
MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진으로 쓰기 또는 읽기를 요청하는데, 이를 핸들러 요청이라고 한다.
여기서 사용되는 API를 핸들러 API라고 한다.
InnoDB 스토리지 엔진도 핸들러 API 를 이용해 MySQL 엔진과 데이터를 주고 받는다.
MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 동작하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있다.
최소한 MySQL 서버에 접속된 클라이언트 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.
클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread Cache)로 되돌아 간다.
이 때 이미 스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면, 스레드 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만 스레드 캐시에 존재하게 한다.
포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시에서 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.
MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리
InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 작업은 백그라운드 스레드가 처리
사용자의 요청을 처리하는 도중 데이터 쓰기 작업은 지연되어 처리될 수 있지만, 읽기 작업은 절대 지연될 수 없다.
일반적인 상용 DBMS에는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재되어 있으며, InnoDB 또한 이러한 방식으로 처리한다.
이러한 이유로 InnoDB에서는 쓰기 쿼리로 데이터가 변경되는 경우, 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다.
MyISAM은 그렇지 않고 사용자 쓰레드가 쓰기 작업까지 함께 처리하도록 설계되어 있다.
MySQL에서 사용 되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분 할 수 있다.
글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 운영체제로부터 할당된다.
실제로는 엄청 복잡하지만, 단순하게 MySQL 시스템 변수로 설정해 둔 만큼 운영체제로부터 메모리를 할당받는다고 생각하면 된다.
클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당된다.
필요에 따라 2개 이상의 메모리 공간을 할당받을 수도 있지만 클라이언트 스레드 수와는 무관하다.
MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역이다.
클라이언트 MySQL 서버에 접속하면 MySQL 서버에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 스레드를 하나씩 할당하는데, 클라이언트 스레드가 사용하는 메모리 공간이라고해서 클라이언트 메모리 영역이라고도 한다.
또한, 서버와의 커넥션 섹션이라고도 하기 때문에 로컬 영역이라고 표현한다.
로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며, 절대 공유되어 사용되지 않는다.
각 쿼리마다 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다.
또한, 커넥션이 열려있는 동안 계속 할당된 상태로 남아있는 공간(커넥션 버퍼나 결과 버퍼)도 있으며, 그렇지 않고 쿼리를 실행하는 순간만 할당하는 소트 버퍼나 조인 버퍼가 있다.
쿼리를 실행하는 관점에서 MySQL 구조를 기능별로 나눌 수 있다.
SQL 요청을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)로 분리해 트리 형태의 구조로 만들어내는 작업을 수행한다
쿼리의 문법 오류는 이 과정에서 발견되고, 오류가 있을 경우 사용자에게 오류 메시지를 전달하게 된다.
이전의 파서 과정에서 만들어진 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인한다.
이후 토큰을 테이블 이름, 컬럼 이름 또는 내장 함수와 같은 개체를 매핑해 개체 존재 여부와 개체 접근 권한을 확인하는 과정을 수행한다
실제로 존재하지 않거나 권한 상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다.
쿼리 문장을 저렴한 비용으로 가장 빠르게 처리 할지를 결정하는 역할과 실행계획을 작성을 담당하며, DBMS의 두뇌에 해당한다.
대표적인 종류
RBO(Rule-Based Optimizer): 우선 순위에 따라서 스코어를 매겨서 실행 계획을 수립한다.
CBO(Cost-Based Optimizer): 수행 가능한 방법의 비용 과 테이블 통계 정보를 통한 비용에 따른 실행 계획을 수립한다.
MySQL 에서는 CBO를 사용하며, 최근의 대부분 RDB에서의 기본 옵티마이저는 CBO를 사용하고 있다.
옵티마이저가 계획한대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 손발 역할을 수행한다.
실행 엔진은 만들어진 실행 계획대로 각 핸들러에게 요청을 하게 되고, 또 다시 받은 결과를 또 다른 핸들러를 요청하여 입력으로 연결하는 역할을 한다.
MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당한다.
핸들러는 결국 스토리지 엔진을 의미하며, InnoDB의 테이블일 경우 핸들러는 InnoDB 스토리지 엔진이 된다.
