목차
- MySQL 서버 아키텍처 개요
- MySQL 엔진
- 스토리지 엔진
- MySQL 스레드 구조
- MySQL 메모리 할당 및 사용구조
- 쿼리 실행과정
MySQL 서버 아키텍처 개요
MySQL 서버는 두뇌 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진으로 구분됩니다.
스토리지 엔진은 핸들러 API를 만족하면 누구든지 스토리지 엔진을 구현해서 MySQL 서버에 추가해서 사용할 수 있습니다. MySQL에서 기본으로 제공되는 InnoDB 스토리지 엔진과 MyISAM 스토리지 엔진이 있습니다.
MySQL 엔진
MySQL 엔진은 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리의 최적화된 실행을 위한 옵티마이저가 중심을 이룹니다.
스토리지 엔진
MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행하고, 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분을 스토리지 엔진이 전담합니다.
MySQL 서버에서 MySQL 엔진은 하나이지만, 스토리지 엔진은 동시에 여러 개를 가질 수 있습니다. 아래처럼 테이블이 사용할 스토리지 엔진을 지정하면 이후 해당 테이블의 모든 읽기 작업이나 변경 작업은 정의된 스토리지 엔진이 처리합니다. (디폴트 : InnoDB)
# 엔진 명시 안해줘도, InnoDB가 스토리지 엔진으로 동작합니다.
# MyISAM 스토리지 엔진을 쓰고 싶으면 직접 명시하면 됩니다.
CREATE TABLE test_table(fd1 INT, fd2 INT) ENGINE=INNODB;각 스토리지 엔진은 성능 향상을 위해 버퍼 풀(InnoDB)나 키 캐시(MyISAM 스토리지 엔진)과 같은 기능을 내장하고 있습니다.
MySQL 스레드 구조
MySQL 서버는 프로세스 기반이 아닌, 스레드 기반으로 동작하며 크게 포그라운드 스레드와 백그라운드 스레드로 구분됩니다.
- 또한 스레드의 병렬 처리를 위해, 동일한 이름을 가지는 스레드가 존재할 수 있습니다.
포그라운드 스레드 (클라이언트 스레드)
포그라운드 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리합니다.
- 사용자가 작업을 마치고 커넥션을 종료하면, 해당 커넥션을 담당하던 스레드는 다시
스레드 캐시(Thread cache)로 돌아갑니다. - 이미
스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면,스레드 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만스레드 캐시에 존재하게 합니다.- 스레드가 많이 만들어져 있으면, 메모리 자원 낭비!
스레드 캐시에 유지할 수 있는 최대 스레드 개수는 시스템 변수thread_cache_size로 설정합니다.
포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리합니다.
InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리합니다.
MyISAM 스토리지 엔진은 모두 포그라운드 스레드가 처리합니다
백그라운드 스레드
InnoDB 스토리지 엔진에서는 다음 작업들을 백그라운드 스레드가 처리합니다.
- 인서트 버퍼를 병합하는 스레드
- 로그를 디스크로 기록하는 스레드
- InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
- 데이터를 버퍼로 읽어오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
InnoDB에서도 읽기 작업은 주로 포그라운드 스레드에서 처리되기 때문에, 읽기 스레드는 많이 설정할 필요 없지만, 쓰기 스레드는 아주 많은 작업을 백그라운드로 처리하기 때문에 여유롭게 설정해주는 것이 좋습니다.
데이터의 쓰기 작업은 JPA의 쓰기 지연 저장소처럼 지연될 수 있지만, 읽기 작업은 지연될 수 없습니다.
그렇기에 InnoDB에서도 INSERT, UPDATE, DELETE 와 같이 데이터를 변경하는 작업의 경우에는, 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 됩니다.
MySQL 메모리 할당 및 사용구조
MySQL에서 사용되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 나뉩니다.
글로벌 메모리 영역
글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 운영체제로부터 할당된다는 특징을 가집니다.
그리고 일반적으로, 포그라운드 스레드와 무관하게 하나의 메모리 공간만 할당하고 생성된 글로벌 메모리 영역이 N개라고 하더라도, 모든 스레드에 의해 공유됩니다.
대표적인 글로벌 메모리 영역은 다음과 같습니다.
- 테이블 캐시
- InnoDB 버퍼풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB 리두 로그 버퍼
로컬 메모리 영역 (세션 메모리 영역)
MySQL 서버 상에 존재하는 포그라운드 스레드가 쿼리를 처리하는 데 사용되는 메모리 영역입니다. 대표적으로 위의 그림처럼 커넥션 버퍼와 정렬(소트) 버퍼 등이 있습니다.
사용자가 MySQL 서버에 접속하면, MySQL 서버에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 스레드를 하나씩 할당하게 되는데, 클라이언트 스레드(포그라운드 스레드)가 사용하는 메모리 공간이라고 해서 클라이언트 메모리 영역이라고 합니다.
- 또한 클라이언트와 MySQL 서버와의 커넥션을 세션이라고도 부르기에,
세션 메모리 영역이라고도 불리는 것입니다.
로컬 메모리 영역은 각 클라이언트 스레드 별로 독립적으로 할당되며, 절대 공유되어 사용되지 않는다는 특징이 있습니다.
로컬 메모리 공간의 또 한가지 중요한 특징은 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다는 점입니다.
- 커넥션이 열려있는 동안 계속 할당된 상태로 남아있는 공간
- 커넥션 버퍼
- 결과 버퍼
- 쿼리를 실행하는 순간에만 할당했다가 해제되는 공간
- 조인 버퍼
- 소트 버퍼
쿼리 실행과정
MySQL에서 쿼리가 실행되는 과정을 위의 그림처럼 간략하게 표현할 수 있습니다. 대부분의 작업이 MySQL 엔진에서 처리되고, ‘데이터 읽기/쓰기’ 만 스토리지 엔진에 의해 처리됩니다.
MySQL 서버에서 MySQL 엔진은 사람 역할을 하고, 각 스토리지 엔진은 자동차 역할을 하는데, MySQL 엔진이 스토리지 엔진을 조정하기 위해 핸들러라는 것을 사용 하게 됩니다.
-
또한, MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 무조건
핸들러를 통해야 합니다. -
핸들러라는 의미는 MySQL 서버의 소스코드로부터 넘어온 개념입니다. 자동차에 비유하면 쉽게 이해가능합니다. 사람이 핸들(운전대)를 이용해 자동차를 운전하듯이, 프로그래밍 언어에선 어떤 기능을 호출하기 위해 사용하는 운전대와 같은 역할을 하는 객체를핸들러라고 합니다.
실질적인 GROUP BY나 ORDER BY 등 복잡한 처리는 스토리지 엔진 영역이 아니라, MySQL 엔진의 처리영역인 ‘쿼리 실행기’ 에서 처리됩니다.
중요한 내용은 “하나의 쿼리 작업은 여러 하위 작업으로 나뉘는데, 각 하위 작업이 MySQL 엔진 영역에서 처리되는지 아니면 스토리지 엔진 영역에서 처리되는지 구분할 줄 알아야 한다는 점”입니다.
쿼리 실행과정을 조금 더 자세히 표현하면 다음과 같습니다. 어떤 기능들로 쿼리가 실행되는지 확인해보겠습니다.
쿼리 파서
쿼리 파서는 사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조(파서 트리)로 만들어내는 작업을 의미합니다.
토큰: MySQL이 인식할 수 있는 최소 단위의 어휘나 기호
쿼리 문장의 기본 문법 오류는 이 과정에서 발견되고 오류 메시지를 사용자에게 전달합니다.
전처리기
파서 과정에서 만들어진 파서 트리 를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인합니다.
각 토큰을 테이블 이름이나 칼럼 이름, 또는 내장 함수와 같은 객체를 매핑해 해당 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 이 단계에서 수행합니다.
실제 존재하지 않거나 권한 상 사용할 수 없는 객체의 토큰은 이 단계에서 걸러집니다.
옵티마이저
옵티마이저는 쿼리 실행과정 중 성능 측면에서 가장 중요한 과정이라고 해도 무방합니다.
옵티마이저란, 사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할을 담당하며, DBMS의 두뇌라고 볼 수 있습니다.
어떻게 하면 옵티마이저가 더 나은 선택을 할 수 있게 유도하는지는 추후 포스팅으로 따로 다루도록 하겠습니다.
실행 엔진
옵티마이저가 두뇌라면, 실행 엔진과 핸들러는 손과 발에 비유됩니다. 예를 들어, 옵티마이저가 GROUP BY를 처리하기 위해 임시 테이블을 사용하기로 결정했다고 가정해보겠습니다.
실행 엔진이핸들러에게 임시 테이블 만들라고 요청- 다시 실행 엔진은
WHERE절에 일치하는 레코드를 읽어오라고핸들러에게 요청 - 읽어온 레코드들을 1번에서 준비한 임시 테이블로 저장하라고 다시
핸들러에게 요청 - 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어오라고
핸들러에게 다시 요청 - 최종적으로
실행 엔진은 결과를 사용자나 다른 모듈로 넘긴다.
즉, 실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행합니다.
핸들러(스토리지 엔진)
핸들러는 MySQL 서버의 가장 밑 단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 읽어오는 역할을 담당합니다.
위에서 스토리지 엔진이 데이터를 디스크로부터 읽어오거나 저장하는 역할이라고 했습니다.
맞습니다. 핸들러는 결국 스토리지 엔진을 의미합니다.
Reference
Real MySQL 8.0.1
