본 포스트는 Real MySQL 8.0 1권을 읽은 뒤 정리하는 글입니다.
4.1 MySQL 엔진 아키텍처
4.1.1 MySQL의 전체 구조
MySQL 엔진
MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행한다.
클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러, SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룬다.
MySQL은 표준 SQL(ANIS SQL) 문법을 지원하므로 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다.
스토리지 엔진
스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분을 전담한다.
테이블이 사용할 스토리지 엔진을 지정하면 해당 테이블의 모든 읽기 작업 및 변경 작업은 정의된 스토리지 엔진이 처리한다.
mysql> CREATE TABLE test_table (fd1 INT, fd2 INT) ENGINE=INNODB;각 스토리지 엔진은 성능 향상을 위해 키 캐시(MyISAM) 혹은 InnoDB 버퍼 풀(InnoDB)과 같은 기능을 내장하고 있다.
핸들러 API
핸들러(Handler) 요청이란 MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽는 경우 스토리지 엔진에 보내는 요청을 의미하며, 사용되는 API를 핸들러 API라고 한다.
4.1.2 MySQL 스레딩 구조
포그라운드 스레드 (클라이언트 스레드)
포그라운드 스레드는 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리하며, 이를 위해 최소한 MySQL 서버에 접속된 클라이언트 수만큼 존재한다.
클라이언트 사용자가 작업을 마치고 커넥션을 종료하는 경우 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread cache)로 되돌아간다. 이때 스레드 캐시에 일정 개수 이상 대기 중인 스레드가 있는 경우 스레드 캐시에 넣지 않고 종료시켜 일정 개수의 스레드만 존재할 수 있도록 한다.
포그라운드 스레드는 데이터를 MySQL 데이터 버퍼나 캐시로부터 가져오거나 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어 작업을 처리한다.
MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만 InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운스 스레드가 처리하고, 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.
백그라운드 스레드
InnoDB 백그라운드에서 처리되는 작업
- 인서트 버퍼를 병합하는 스레드
- 로그를 디스크로 기록하는 스레드
- InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
- 데이터를 버퍼로 읽어 오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
InnoDB의 경우 쓰기 작업을 버퍼링해서 일괄 처리할 수 있어 INSERT, UPDATE, DELETE 쿼리로 데이터가 변경되는 경우 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다. 하지만 MyISAM에서 일반적인 쿼리는 쓰기 버퍼링 기능을 사용할 수 없다.
4.1.3 메모리 할당 및 사용 구조
글로벌 메모리 영역
일반적으로 클라이언트 스레드 수와 무관하게 하나의 메모리 공간만 할당되며, 필요에 따라 2개 이상의 메모리 공간을 할당받을 수 있지만 클라이언트 스레드 수와 무관하며 모든 스레드에 의해 공유된다.
대표적인 글로벌 메모리 영역
- 테이블 캐시
- InnoDB 버퍼 풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB 리두 로그 버퍼
로컬 메모리 영역
MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역이며 클라이언트 스레드가 사용하는 메모리 공간으로 클라이언트 메모리 영역 혹은 클라이언트와 MySQL 서버와의 커넥션을 세션이라고 하기 때문에 세션 메모리 영역이라고도 표현한다.
로컬 메모리는 각 클라리언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는 다는 특징이 있다. 또한 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차 하지 않을 수 있다.
대표적인 로컬 메모리 영역
- 정렬 버퍼(Sort Buffer)
- 조인 버퍼
- 바이너리 로그 캐시
- 네트워크 버퍼
4.1.4 플러그인 스토리지 엔진 모델
MySQL의 독특한 구조 중 대표적인 플러그인 모델로, 스토리지 엔진 뿐만 아니라 전문 검색 엔진을 위한 검색어 파서를 플러그인 형태로 개발해 사용할 수 있으며, 사용자의 인증을 위한 Native Authentication과 Caching SHA-2 Authentication 등도 모두 플러그인으로 구현되어 제공된다.
MySQL 쿼리가 실행되는 과정에서 대부분의 작업은 MySQL 작업에서 처리되고, 마지막 데이터 읽기/쓰기 작업만 스토리지 엔진에서 처리된다.
MySQL 엔진이 스토리지 엔진을 조정하기 위해 핸들러(Handler)를 사용하는데, 이는 프로그래밍 언어에서 어떤 기능을 호출하기 위해 사용하는 객체이며, MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통제해야 한다.
MySQL에서 MyISAM이나 InnoDB와 같이 다른 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라도 MySQL 처리 내용은 대부분 동일하며, 단순히 데이터 읽기/쓰기 영역의 처리만 차이가 존재하며, 실질적인 GROUP BY, ORDER BY 등 복잡한 처리는 MySQL 엔진의 쿼리 실행기에서 처리된다.
MySQL 서버에서는 스토리지 엔진뿐만 아니라 인증이나 전문 검색 파서, 쿼리 재작성과 같은 플러그인이 있으며 비밀번호 검증과 커넥션 제어 등에 관련된 다양한 플러그인이 제공된다. 뿐만 아니라 MySQL 서버의 기능을 확장할 수 있게 플러그인 API가 메뉴얼에 공개돼 있으므로 제공된 기능을 확장하거나 새로운 기능들을 플러그인을 이용해 구현할 수 있다.
4.1.5 컴포넌트
MySQL 8.0부터는 기존 플러그인 아키텍처의 단점을 보완한 컴포넌트 아키텍처가 지원된다.
플러그인 아키텍처의 단점
- 플러그인은 오직 MySQL 서버와 인터페이스할 수 있고, 플러그인끼리는 통신할 수 없음
- 플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음(캡슐화 안 됨)
- 플러그인은 상호 의존 관계를 설정할 수 없어 초기화가 어려움.
4.1.6 쿼리 실행 구조
쿼리 파서
쿼리 파서는 사용자 요청으로 들어온 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조로 만들어 내는 작업을 의미한다. 쿼리 문장의 기본 문법 오류는 이 과정에서 발견되며 사용자에게 오류 메세지를 전달한다.
전처리기
파서 트리를 기반으로 각 토큰의 테이블 혹은 칼럼의 이름, 또는 내장 함수와 같은 개체를 매핑해 해당 객체의 존재 여부와 접근 권한 등을 확인하며 토큰을 걸러낸다.
옵티마이저
옵티마이저란 사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할로, DBMS의 두뇌에 해당한다.
실행 엔진
실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.
핸들러 (스토리지 엔진)
핸들러는 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당한다.
4.1.8 쿼리 캐시
쿼리 캐시는 SQL 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환해 매우 빠른 성능을 보였지만 테이블의 데이터가 변경되면 캐시의 저장된 결과를 모두 삭제해 동시 처리 성능 저하를 유발하기도 하였다. 이로 인해 MySQL 8.0부터 제거하게 되었다.
4.1.9 스레드풀
스레드 풀은 내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여 동시 처리되는 요청이 많더라도 MySQL 서버의 CPU가 재한된 개수의 스레드 처리에만 집중할 수 있게 해서 CPU의 프로세서 친화도(Processor affinity)를 높이고 운영체제 입장에서 불필요한 컨텍스트 스위치(Context switch)를 줄여 오버헤드를 낮출 수 있다.
스레드 풀의 사용으로 성능 향상을 보여준 경우는 드물며, 오히려 스케줄링 과정에서 CPU 시간을 제대로 확보하지 못하는 경우 쿼리 처리가 더 느려질 수도 있다.
4.1.10 트랜잭션 지원 메타데이터
데이터베이스 서버에서 테이블 구조 정보와 스토어드 프로그램 등의 정보를 데이터 딕셔너리 또는 메타데이터라고 하는데, MySQL 5.7까지 이를 파일 기반으로 관리했으나, 이는 생성 및 변경 작업이 트랜잭션을 지원하지 않아 문제가 발생하기도 하여 MySQL 8.0 버전부터는 관련 정보를 모두 InnoDB 테이블에 저장하도록 개선했다.
