MySQL의 전체 구조
MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있다.
MySQL 엔진
MySQL 엔진은 요청된 SQL 문장을 분석하거나 최적화하는 등의 처리를 수행한다.
커넥션 핸들러, SQL 파서, 전처리기, 옵티마이저 등으로 구성되어 있다.
스토리지 엔진
디스크 스토리지에 데이터를 저장하거나 읽어오는 작업을 스토리지 엔진이 수행한다.
한 MySQL 서버에서 여러 종류의 스토리지 엔진을 동시에 사용할 수 있다.
스토리지 엔진에 따라 테이블 데이터와 인덱스를 저장하는 방식이 다르다.
커넥션 핸들러 (핸들러 API)
MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러(Handler) 요청이라 하고, 여기서 사용되는 API를 핸들러 API라고 한다.
스토리지 엔진은 이 핸들러 API를 이용해 MySQL 엔진과 데이터를 주고받는다.
이 핸들러 API를 통해 얼마나 많은 데이터 작업이 있었는지 아래 명령을 통해 확인할 수 있다.
SHOW GLOBAL STATUS LIKE 'Handler%';
MySQL 스레딩 구조
MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드와 백그라운드 스레드로 구분할 수 있다.
MySQL 서버에서 실행 중인 스레드의 목록은 다음과 같이 performance_schema 데이터베이스의 thread 테이블을 통해 확인할 수 있다.
SELECT thread_id, name, type, processlist_user, processlist_host
FROM performance_schema.threads ORDER BY type, thread_id;포그라운드 스레드
포그라운드 스레드는 최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.
클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread cache)로 되돌아간다.
포그라운드 스레드는 데이터를 MySQL 의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 한다
백그라운드 스레드
백그라운드 스레드의 경우, 디스크에 데이터를 직접 기록하는 작업을 수행한다.
다음과 같이 여러 가지 작업이 백그라운드로 처리된다.
- 인서트 버퍼(Insert Buffer)를 병합하는 스레드
- 로그를 디스크로 기록하는 스레드
- InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
- 데이터를 버퍼로 읽어 오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
메모리 할당 및 사용 구조
글로벌 메모리 영역
클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당된다.
필요에 따라 2개 이상의 메모리 공간을 할당받을 수 있으며, 생성된 글로벌 영역이 N개라 하더라도 모든 스레드에 의해 공유된다.
[대표적인 글로벌 메모리 영역]
- 테이블 캐시
- InnoDB 버퍼 풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB리두 로그 버퍼
로컬 메모리 영역
세션 메모리 영역이라고도 표현하며, MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역이다.
클라이언트가 MySQL 서버에 접속하면 MySQL 서버에서는 클라이언트 커넥션으로 부터의 요청을 처리하기 위해 스레드를 하나씩 할당하게 된다.
로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는다.
로컬 메모리의 다른 특징은 각 쿼리의 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당 조차도 하지 않을 수도 있다는 점이다.
[대표적인 로컬 메모리 영역]
- 정렬 버퍼(Sort buffer)
- 조인 버퍼
- 바이너리 로그 캐시
- 네트워크 버퍼
플러그인 스토리지 엔진 모델
MySQL에서 쿼리가 실행되는 과정 중 ‘데이터 읽기/쓰기’ 작업만 스토리지 엔진에 의해 처리된다.
MySQL에서 기본적으로 제공되는 기능 이외에 부가적인 기능을 더 제공하기 위한 방법으로 플러그인 모델을 사용한다.
컴포넌트
MySQL 8.0 부터 플러그인의 단점을 보완하기 위해 컴포넌트 아키텍처가 지원되었다.
- 플러그인은 오직 MySQL 서버와 인터페이스할 수있고, 플러그인끼리는 통신할 수 없다.
- 플러그인은 MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않다.
- 플러그인은 상호 의존 관계를 설정할 수 없어서 초기화가 어렵다.
플러그인은 위와 같은 단점을 가지고 있었으며, 컴포넌트는 해당 단점을 보완하도록 지원한다.
쿼리 실행 구조
-
쿼리 파서
사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어낸다. (문법 오류는 이 과정에서 발견된다.)
-
전처리기
파서 과정에서 만들어진 파서 트리를 기반으로 구조적인 문제가 있는지 확인한다.
각 토큰에 대한 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 수행한다.
실제 존재하지 않거나 권한상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다. -
옵티마이저
쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할 수 있도록 결정한다.
-
실행 엔진
옵티마이저에서 만든 계획대로 핸들러에게 실제 요청을 주고받는다.
옵티마이저가 특정 쿼리문을 처리하기 위해 임시 테이블을 사용하기로 결정했다고 가정할 때, 실행 엔진은 위의 목적을 달성하기 위해 핸들러에게 요청을 하고 최종 결과물을 사용자나 다른 모듈로 넘긴다.
-
핸들러(스토리지 엔진)
MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 읽어오는 역할을 한다.
복제
주요 키워드: 부하 분산
하나 또는 하나 이상의 MySQL Database 서버에 특정 MySQL Database 서버를 복사할 수 있는 기능이다.
모든 Database 단위가 아닌 특정 DB 또는 Table 단위로도 Replication이 가능하다.
쿼리 캐시
빠른 응답을 위해 SQL 실행 결과를 캐싱해두는 기능이다.
MySQL 8.0 이전
MySQL 서버에서 쿼리 캐시(Query Cache)는 빠른 응답을 필요로 하는 웹 기반의 응용 프로그램에서 매우 중요한 역할을 담당했다.
쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시하고, 동일 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하기 때문에 매우 빠른 성능을 보였다.
하지만 테이블의 데이터가 변경되면 캐시에 저장된 결과 중 변경된 테이블관 관련된 것들은 모두 삭제(Invalidate)해야 했다.
이는 심각한 동시 처리 성능 저하를 유발하며, 많은 버그의 원인이 되기도 했다.
MySQL 8.0 이후
쿼리 캐시는 MySQL 서버의 기능에서 완전히 제거되고, 관련된 시스템 변수도 모두 제거됐다.
쿼리 캐시 기능은 데이터 변경은 거의 없고 읽기만 하는 서비스와 같은 환경에서는 매우 훌륭한 기능이지만 이런 요건을 가진 서비스는 흔치 않다.
스레드 풀
MySQL 서버 엔터프라이즈 에디션은 스레드 풀(Thread Pool) 기능을 제공하지만 MySQL 커뮤니티 에디션은 스레드 풀 기능을 지원하지 않는다.
사용자의 요청을 처리하는 포워드 스레드의 개수를 CPU가 최대한 잘 처리할 수 있는 수준으로 줄여 한정된 스레드에서 처리될 수 있도록 하는것을 목적으로 한다.
이때 염두에 둘 점은 MySQL 서버에 스레드 풀을 설치 하더라도 무조건 성능이 올라가지 않는다는 것이다.
스레드 풀이 실제 서비스에서 눈에 띄는 성능 향상을 보여준 경우는 드물다.
트랜잭션 지원 메타데이터
데이터베이스 서버에서 테이블의 구조 정보와 Stored Program 등의 정보를 데이터 딕셔너리/메타데이터라고 한다.
5.7 버전 까지는 테이블 구조정보를 FRM 파일에 저장하고 일부 Stored Program의 정보 도한 파일로 저장했다. (=> 해당 구조는 트랜잭션을 지원하지 않았기 때문에 생성 도중에 문제가 생기면 정합성이 깨지는 문제가 있었다.)
8.0 버전 부터는 테이블의 구조정보와 같은 메타데이터들이 별도 파일이 아닌, 트랜잭션을 지원하는 InnoDB 스토리지 엔진에 테이블 형태로 저장되도록 개선 되었다.
