Real MySQL 8.0 (신판)을 4장 아키텍처 일부분을 정리한다.
자세한 내용이 궁금하면 책을 읽어보는 걸 권장한다.
Real MySQL 8.0 (1권) - YES24
『Real MySQL 8.0』은 『Real MySQL』을 정제해서 꼭 필요한 내용으로 압축하고, MySQL 8.0의 GTID와 InnoDB 클러스터 기능들과 소프트웨어 업계 트렌드를 반영한 GIS 및 전문 검색 등의 확장 기능들을 추가로
www.yes24.com
MySQL 전체 아키텍처
MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진 2가지로 구분되며, 이 둘을 합쳐 MySQL 서버라 부른다.
MySQL 엔진 - 클라이언트의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 옵티마이저가 중심을 이룬다.
스토리지 엔진 - 요청된 SQL 문장을 분석 및 최적화하며, 데이터를 저장하거나 읽어오는 역할을 한다.
핸들러 API - MySQL 엔진의 쿼리 실행기에서 데이터를 읽거나 쓰기를 할 때 스토리지 엔진에 요청하는 걸 핸들러(Handler) 요청이라 하고, 사용되는 API가 핸들러 API다. 핸들러 API가 얼마나 작업되었는지는 아래의 구문을 통해 결과를 확인할 수 있다.
SHOW GLOBAL STATUS LIKE 'Handler%'
MySQL 스레딩 구조
MySQL 서버는 스레드 기반으로 작동하며 포그라운드(Foreground) 스레드와 백그라운드(Background) 스레드로 구분된다.
다음 구문을 이용하여 실행 중인 스레드 목록을 볼 수 있다.
SELECT thread_id, name, type, processlist_user, processlist_host
FROM performance_schema.threads
ORDER BY type, thread_id
type을 보면 백그라운드와 포그라운드로 구분된다.
마지막에 보이는 thread/sql/one_connection이 실제 사용자의 요청을 처리하는 스레드다.
중복되는 이름은 MySQL 서버 설정에 의해 병렬로 처리된다.
포그라운드 스레드(클라이언트 스레드)
포그라운드 스레드는 MySQL에 접속한 클라이언트만큼 존재하며, 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다. 사용자가 작업을 마치고 종료하면, 해당 사용자를 담당하는 스레드는 스레드 캐시(Thread cache)로 돌아간다.
※ 포그라운드 스레드와 사용자 스레드는 같은 의미로 사용한다.
포그라운드 스레드는 데이터 버퍼 & 캐시로부터 데이터를 갖고 온다. 버퍼 & 캐시에도 없다면 직접 디스크의 데이터나 인덱스 파일로부터 읽어와 처리한다. 여기서 스토리지 엔진에 따라 작동하는 방식이 달라진다.
MyISAM - 디스크 쓰기까지 포그라운드 스레드가 처리
InnoDB - 데이터 버퍼 & 캐시까지만 포그라운드 스레드가 처리하고, 디스크 쓰기는 백그라운드 스레드가 처리
백그라운드 스레드
스토리지 엔진에 따라 백그라운드 스레드로 작업하는게 달라지며, 그중 InnoDB는 아래의 작업이 백그라운드 스레드로 진행된다.
- 인서트 버퍼(Insert Buffer)를 병합하는 스레드
- 로그를 디스크로 기록하는 스레드 (Log thread)
- InnoDB를 버퍼 풀의 데이터를 디스크에 기록하는 스레드 (Write thread)
- 데이터를 버퍼로 읽어 오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
메모리 할당 및 사용 구조
MySQL의 메모리 공간은 스레드가 공유하는 여부에 따라 글로벌 메모리 영역과 로컬(세션) 메모리 영역 2가지로 구분되고 다음과 같은 특징을 가진다.
글로벌 메모리 영역 - 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당되며, 필요에 따라 2개 이상 할당받기도 한다. 생성된 글로벌 메모리 영역은 모든 스레드에 공유된다.
로컬 메모리 영역 - 각 클라이언트 스레드별로 독립적으로 할당되기 때문에 서로가 공유되지 않는다. 또한, 쿼리의 용도별로 필요에 따라 공간이 할당될 수도 안될 수 있다. ex) 소트 버퍼, 조인 버퍼는 쿼리를 실행한 순간에만 할당되고 다시 해제한다.
플러그인 스토리지 엔진 모델
MySQL은 독특하게 플러그인 모델을 사용하며, 기본적으로 제공하는 스토리지 엔진 이외의 다양한 기능을 가진 스토리지 엔진이 존재한다. 필요에 따라 개발자가 직접 스토리지 엔진도 개발해서 사용할 수 있다.
쿼리가 실행되는 과정은 보면 대부분의 작업은 MySQL 엔진에서 처리되고, 마지막에 '데이터 읽기/쓰기' 작업만 스토리지 엔진에 의해 처리된다. 이는 사용자가 스토리지 엔진을 만든다 해도 DBMS 전체 기능이 아닌 일부분만 수행하는 엔진을 작성한다는 의미다.
스토리지 엔진이 여러개가 존재하는데 MySQL 엔진은 핸들러(Handler)를 통해 스토리지 엔진에게 데이터를 가져오고 저장하도록 명령한다.
※ 프로그래밍 언어에서는 어떤 기능을 호출하기 위해 사용하는 운전대와 같은 역할을 하는 객체를 핸들러라고 표현한다.
다음 구문을 통해 스토리지 엔진 목록을 확인할 수 있다.
SHOW ENGINES
Support 컬럼의 값은 4가지로 구분된다.
YES - MySQL 서버에 해당 스토리지 엔진이 포함되어 있고, 활성화된 상태.
DEFAULT - YES와 동일하지만, 필수 스토리지 엔진을 뜻함. (없으면 MySQL 실행 안됨)
NO - 현재 MySQL 서버에 포함되지 않았음.
DISABLED - MySQL 서버에 포함되었지만, 활성화되지 않음.
컴포넌트
MySQL 플러그인은 몇 가지 단점이 존재한다.
- 플러그인은 오직 MySQL 서버와 인터페이스 할 수 있고, 플러그인끼리는 통신할 수 없음.
- 플러그인은 MySQL 서버의 변수나 함수를 직접 호출해서 위험함(캡슐화 안됨)
- 플러그인은 상호 의존관계를 설정할 수 없어서 초기화가 어려움.
MySQL 8.0 부터는 이러한 단점을 보완하는 컴포넌트 아키텍처를 지원한다.
아래는 가이드에서 제공하는 컴포넌트를 설치하는 방법이다.
-- Syntax
INSTALL COMPONENT component_name [, component_name ] ...
-- exmaple
INSTALL COMPONENT 'file://component_log_sink_syseventlog';
Query OK, 0 rows affected (0.36 sec)쿼리 실행 구조
사용자가 요청한 SQL 요청은 아래와 같이 실행되며, 기능별로 살펴보자.
쿼리 파서
사용자가 요청한 SQL를 서버가 이해할 수 있는 토큰으로 분리한다. 기본적인 문법 오류는 여기서 발견되어 사용자에게 오류 메시지를 보낸다.
전처리기
쿼리 문장에 구조적인 문제점 여부를 확인한다. 각 토큰을 테이블 이름, 칼럼, 또는 내장 함수 등에 매핑해 해당 객체의 존재 여부와 접근 권한 등의 확인 과정이 여기에 속한다.
옵티마이저
쿼리 문장을 저렴한 비용으로 빠르게 처리하는 역할을 담당하며, DBMS의 두뇌에 해당된다. 실행 계획(Exception Plan)을 수립한다.
실행 엔진
이전 단계에서 만들어진 실행 계획대로 핸들러에게 요청해서 결과를 받고, 또 다른 핸들러 요청의 입력으로 연결하는 역할을 한다.
핸들러(스토리지 엔진)
실행 엔진 요청에 따라 데이터를 디스크로 저장하고 읽어오는 역할을 담당한다.
쿼리 캐시 (8.0 부터 제거됨)
쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시 하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하기 때문에 빠른 성능을 보였다. 하지만 테이블 데이터가 변경되면 관련된 캐시도 모두 삭제하는 심각한 성능 저하를 유발하고 다양한 버그의 원인으로 지목되었는데, MySQL 8.0이 되면서 완전히 제거가 되었다.
스레드 풀
스레드 풀은 MySQL 서버 엔터프라이즈 에디션에 내장되어 있고, MySQL 커뮤니티에는 지원하지 않는다. 대신 플러그인 형태로 제공되는 Percona server의 스레드 풀을 알아본다.
스레드 풀은 MySQL 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 서버의 자원 소모를 줄이는 것이 목적이다.
Percona Server의 스레드 풀은 기본적으로 CPU 코어의 개수만큼 스레드 그룹을 생성하는데, thread_pool_size 변수로 조정할 수 있다.
공식 문서에 따르면
- InnoDB 경우, 최적의 thread_pool_size 설정 값은 16 ~ 36 사이일 가능성이 가장 높으며, 가장 일반적인 최적 값은 24 ~ 36이다.
DBT2 및 Sysbench와 같은 워크로드의 경우, InnoDB 최적화 값은 보통 36 정도이며, 쓰기에 집중적인 워크로드의 경우 더 낮아질 수 있다.
- MyISAM 경우, thread_pool_size 설정값은 상당히 낮아야한다. 최적의 성능은 4 ~ 8로 보인다. 높은 값을 설정하면 성능에 부정적인 영향을 미치지만, 심각한 영향을 끼치진 않는다.
스레드 그룹의 모든 스레드가 작업 중이라면 새로운 스레드 그룹을 추가할지, 기다릴 지 여부를 판단해야 하는데 스레드풀의 타이머 스레드가 주기적으로 스레드 그룹의 상태를 체크한다. thread_pool_stall_limit 변수의 밀리초만큼 작업이 안 끝난다면 새로운 스레드를 추가해서 작업을 하는데, 전체 스레드의 개수는 thread_pool_max_threads 변수의 값을 넘어설 순 없다.
즉, 모든 스레드가 작업중인 상태에서 새로운 요청은 thread_pool_stall_limit 밀리초만큼 대기해야 한다. 이때 서비스의 민감도에 따라 대기시간을 낮추게 설정해도 된다. 다만 0으로 설정하면 스레드를 사용하지 않는 것이 좋을 것이다.
트랜잭션 지원 메타데이터
DB 서버에서 '테이블의 구조 정보와 스토어드 프로그램 등의 정보'를 데이터 딕셔너리 혹은 메타데이터라 부른다. MySQL 5.7 버전까지는 파일로 관리하다가 MySQL가 비정상 종료를 하게 되면 파일 정보가 일관되지 않아서 문제가 생겼는데, 이를 'DB나 테이블이 깨졌다'라고 표현했다.
MySQL 8.0부터는 테이블 구조 정보와 스토어드 프로그램 등의 정보를 모두 InnoDB의 테이블에 저장하도록 개선되었다. mysql DB는 통째로 mysql.ibd라는 테이블 스페이스에 저장하게 된다.
InnoDB에서 데이터 딕셔너리가 테이블에 저장된다고 했는데, 실제 mysql DB 테이블 목록을 살펴보면 해당 테이블이 보이지 않는다. 이는 사용자가 임의로 수정하지 못하게 보여주지 않을뿐이지 실제로는 테이블이 존재한다. 대신 MySQL 서버는 뷰를 통해 조회할 수 있게 한다.
SHOW CREATE TABLE INFORMATION_SCHEMA.TABLES;
/*
CREATE TEMPORARY TABLE `TABLESsys_config` (
`TABLE_CATALOG` varchar(512) NOT NULL DEFAULT '',
`TABLE_SCHEMA` varchar(64) NOT NULL DEFAULT '',
`TABLE_NAME` varchar(64) NOT NULL DEFAULT '',
`TABLE_TYPE` varchar(64) NOT NULL DEFAULT '',
`ENGINE` varchar(64) DEFAULT NULL,
`VERSION` bigint(21) unsigned DEFAULT NULL,
`ROW_FORMAT` varchar(10) DEFAULT NULL,
`TABLE_ROWS` bigint(21) unsigned DEFAULT NULL,
`AVG_ROW_LENGTH` bigint(21) unsigned DEFAULT NULL,
`DATA_LENGTH` bigint(21) unsigned DEFAULT NULL,
`MAX_DATA_LENGTH` bigint(21) unsigned DEFAULT NULL,
`INDEX_LENGTH` bigint(21) unsigned DEFAULT NULL,
`DATA_FREE` bigint(21) unsigned DEFAULT NULL,
`AUTO_INCREMENT` bigint(21) unsigned DEFAULT NULL,
`CREATE_TIME` datetime DEFAULT NULL,
`UPDATE_TIME` datetime DEFAULT NULL,
`CHECK_TIME` datetime DEFAULT NULL,
`TABLE_COLLATION` varchar(32) DEFAULT NULL,
`CHECKSUM` bigint(21) unsigned DEFAULT NULL,
`CREATE_OPTIONS` varchar(255) DEFAULT NULL,
`TABLE_COMMENT` varchar(2048) NOT NULL DEFAULT ''
) ENGINE=MEMORY DEFAULT CHARSET=utf8
*/조회해보면 데이터 딕셔너리(메타 데이터)를 볼 수 있다.
SELECT * FROM INFORMATION_SCHEMA.TABLES;
하지만 InnoDB가 아닌 MyISAM, CSV 스토리지 엔진의 메타 정보는 여전히 저장 공간이 필요하는데, SDI(Serialized Dictionary Information) 파일을 사용한다.
'서적 > Real MySQL 8.0' 카테고리의 다른 글
| MySQL - InnoDB 스토리지 엔진 아키텍처 (0) | 2023.03.23 |
|---|