MySQL 엔진 아키텍처
💡 본 내용은 Real MySQL 8.0 1권을 읽으면서 정리한 내용입니다.
- 본문에 포함된 사진의 출처는 Real MySQL 4장입니다.
전체 구조
MySQL 서버 : MySQL 엔진 + 스토리지 엔진 이라고 생각하고 보자.
MySQL 엔진
- 커넥션 핸들러 + SQL Parser 및 전처리기, 쿼리 연산 최적화 (옵티마이저)
커넥션 핸들러 : 클라이언트로부터의 접속 및 쿼리 요청을 처리
MySqL은 대부분의 프로그래밍 언어로부터의 접근은 모두 지원한다.
즉, DBMS의 두뇌에 해당하는 처리를 수행하는 것이 MySQL 엔진이다.
스토리지 엔진 (Storage Engine)
MySqL에서 처리를 수행한 뒤, 실제 데이터를 디스크 스토리지에 저장하거나 읽어오는 부분이다.
MySQL 엔진은 하나지만, 스토리지 엔진은 여러 개 동시에 사용 가능하다.
그리고 각각의 버퍼, 캐시가 있어서 각각 쿼리 최적화, 데이터 최적화에 사용한다.
핸들러
MySQL 엔진의 쿼리 실행기에서 데이터를 읽거나 쓸 때 각 스토리지 엔진에도 읽기 or 쓰기 요청을 한다.
이 때 이러한 요청을 핸들러 요청이라고 한다.
그리고 그 때 사용하는 API를 핸들러 API라고 한다.
MySQL 스레딩 구조
MySQL 서버는 프로세스 기반 X -> 스레드 기반으로 작동된다.
1. 포그라운드 스레드 / 2. 백그라운드 스레드 2가지로 구분된다.
포그라운드 스레드
- 포그라운드 스레드 = 사용자 스레드 : 각 클라이언트가 요청하는 쿼리 문장 처리
-
서버에 접속된 클라이언트 수만큼 존재한다.
-
사용하지 않으면 스레드 캐시로 돌아간다. (커넥션이 종료되면 돌아간다.)
- 이미 일정 개수 이상의 대기 중인 스레드가 있으면 다시 넣지는 않고 종료한다.
-
스레드 캐시에 유지할 수 있는 개수가 한정적 (
thread_cache_size로 설정 가능) -
버퍼나 캐시로부터 데이터를 가져오고, 없는 경우에는 직접 디스크의 데이터 or 인덱스 파일로부터 읽어와서 처리한다.
참고
MyISAM테이블은 디스크 쓰기 작업까지 포그라운드가 담당InnoDB테이블은 버퍼나 캐시까지만 포그라운드가 담당, 디스크로 기록하는 작업은 백그라운드가 담당
백그라운드 스레드
- 백그라운드 스레드 : 주로 InnoDB에서 사용되는 스레드
-
Insert Buffer 병합하는 스레드
-
로그를 디스크로 기록 스레드 -
로그 스레드 (Log Thread) -
InnoDB 버퍼풀의 데이터를 디스크에 기록 -
쓰기 스레드 (Write Thread) -
데이터를 버퍼로 읽어오는 스레드
-
잠금이나 데드락을 모니터링하는 스레드
로그 스레드와 쓰기 스레드가 가장 중요한 역할을 한다.
데이터 읽기 작업은 절대 지연될 수 없다.
(사용자가SELECT쿼리를 실행했는데 요청된SELECT는 10분 뒤에 결과를 돌려주겠다라고 응답을 보내는DBMS는 없다.)
그래서 대부분의 DBMS와 InnoDB는 그래서 쓰기 작업을 버퍼링해 일괄 처리해 데이터가 변경될 디스크의 데이터 파일로 저장되는 것까지 기다리지 않아도 된다.
하지만, MyISAM은 포그라운드 스레드가 읽기, 쓰기 둘 다 하기 때문에 쓰기 버퍼링 기능 사용할 수 없음
메모리 할당 및 사용 구조
크게 글로벌 메모리 영역, 로컬 메모리 영역으로 구분할 수 있다.
글로벌 메모리 영역
- 글로벌 메모리 영역
- 모든 메모리 공간은 MySQL 서버가 시작되면서 OS로부터 할당된다.
- OS 종류마다 달라도 요청된 메모리 공간을 100% 할당 가능하며, 필요할 때 조금씩 할당해주는 경우도 있다.
- 하지만, 정확한 메모리의 양을 측정하는 것은 어렵다.
- 클라이언트 스레드 수와 무관하게 하나의 메모리 공간만 할당된다. (모든 스레드에 의해 공유된다.)
- 단, 필요에 따라 2개 이상의 메모리 공간 할당도 가능.
대표적인 글로벌 메모리 영역
- 테이블 캐시 / InnoDB 버퍼 풀 / InnoDB 어댑티드 해시 인덱스 / InnoDB 리두 로그 버퍼
로컬 메모리 영역
- 로컬 메모리 영역 (= 클라이언트 메모리 영역 = 세션 메모리 영역)
-
MySQL 서버에 접속하면 서버에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 스레드를 하나씩 할당한다. -> 그것이 클라이언트 스레드
-
MySQL 서버상 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 독립적인 메모리 영역
- 절대 공유되어 사용되지 않음
-
조인버퍼나 소트 버퍼의 경우 필요할 때만 공간이 할당됨
-
커넥션 버퍼 / 소트 버퍼 / 조인 버퍼 / 바이너리 로그 캐시 / 네트워크 버퍼
커넥션 버퍼나 결과 버퍼는 커넥션이 열려있는 동안 계속 할당된 상태로 공간이 남아있음
플러그인 스토리지 엔진 모델
특이한 구조 중에 플러그인 모델이 있다.
수많은 사용자의 요구 조건을 만족시키기 위해 기본적으로 제공되는 스토리지 엔진 외에 부가적인 기능을 더 제공하는 스토리지 엔진을 개발하여 플러그인 형태로 제공할 수 있다.
인증이나 전문 검색 파서 또는 쿼리 재작성과 같은 플러그인이 있으며, 비밀번호 검증과 커넥션 제어 등에 관련된 다양한 플러그인이 제공된다.
MySQL 서버의 기능을 커스텀하게 확장하거나 새로운 기능을 플러그인을 이용해 구현할 수도 있다.
쿼리 실행 구조
- 쿼리 파서 : 쿼리 문장을 토큰으로 쪼개는 것 (문법 확인 과정) -> 파스 트리를 만든다.
- 전처리기 : 만든 파스 트리 속 문제점 확인 -> 객체의 존재 여부, 접근 권한 등 확인
- 옵티마이저 : 비용 아끼기 위한 더 나은 실행 계획 도출
- 쿼리 실행기 : 핸들러에게 요청 후 받은 결과들을 또 다른 핸들러에 요청하며 연결하는 역할
- 핸들러 : 데이터를 저장, 읽기 하는 역할
복제 라는 개념도 있다. 이건 매우 중요한 역할을 하기 때문에 다음에 자세하게 다뤄보겠다.
쿼리 캐시
쿼리 캐시는 빠른 응답을 필요로 하는 웹 기반 응용 프로그램에서 매우 중요한 역할을 담당했지만, 테이블의 데이터가 변경되면 캐시에 저장된 결과에서 해당 테이블과 연관된 모든 것들을 삭제해야 하므로 동시 처리 성능 저하를 유발하는 문제점이 있었다.결국 MySQL 8.0에서는 쿼리 캐시에 대한 기능이 완전히 제거되었고 관련된 시스템 변수도 모두 제거됐다.
스레드 풀
내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있도록 서버 자원 소모를 줄이는 역할그러나 스레드 그룹 개수와 CPU 코어 개수를 맞추는 것이 CPU 프로세서 친화도를 높이는 데 좋다
트랜잭션 지원 메타데이터
MySQL 서버 5.7 버전까지 테이블 구조를 파일 기반으로 관리했다.
하지만 이러한 파일 기반의 메타데이터는 생성 및 변경 작업에 트랜잭션을 지원하지 않아서 생성이나 변경 도중 MySQL 서버가 비정상 종료가 되면 일관성이 보장되지 않아 테이블이 깨지는 현상이 발생했다.따라서 MySQL 8.0부터는 테이블 구조 정보나 스토어드 프로그램의 코드 관련 정보 등의 정보를 모두 InnoDB의 테이블에 저장되도록 변경되었다.
