시작하기 전
이번 포스팅은 챕터4 아키텍처를 학습하게 됩니다.
챕터4는 4개로 이루어집니다.
- MySQL 엔진 아키텍처
- InnoDB 스토리지 엔진 아키텍처
- MyISAM 스토리지 엔진 아키텍처
- MySQL 로그 파일
MySQL Engine과 Storage Engine이 무엇이며 MySQL Server에서 어떤 역할을 하고 각 엔진이 어떤 기능을 제공하는지에 대하여 알 수 있습니다.
MySQL Server 구조
MySQL Server는 크게 머리 역할의 MySQL Engine과 손발 역할의 storage Engine으로 나뉩니다.
https://dev.mysql.com/doc/refman/8.0/en/pluggable-storage-overview.html
1. MySQL Engine
4가지가 중심을 이룹니다.
- 클라이언트로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러
- SQL 파서
- 전 처리기
- 옵티마이저
또한 표준 SQL(ANSI)를 지원하기 때문에 표준 문법으로 작성된 쿼리는
다른 DBMS에서도 실행이 됩니다.
MySQL Server에서는 1개의 Engine만 존재합니다.
2. Storage Engine
문장 분석, 최적화같은 작업은 MySQL Engine의 역할이며
Storage Enigne은 Disk에 저장하거나 읽어오는 부분을 전담합니다.
MySQL Server에서는 여러개의 Storage Engine을 동시에 사용할 수 있습니다.
3. Handler API
MySQL Engine의 쿼리 실행기에서 데이터를 쓰거나 읽거나 할 때
핸들러에 요청을 합니다.
InnoDB(storage Engine)또한 Handler API를 이용하여 통신합니다.
MySQL Threading Model
대다수의 Thread가 Background이며 Foreground는 매우 소수인 것을 알 수 있으며 51번 행의 thread/sql/one_connection Thread만 실제 사용자의 요청을 처리하는 Foreground Thread 입니다.
현재 환경은 Thread Pool을 지원하지 않는 Community Edition입니다.
Enterprise환경에서는 다른 결과를 보여줄지도..
https://dev.mysql.com/doc/refman/8.0/en/thread-pool.html
- Foreground Thread : 최소한 MySQL Server에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리합니다.
사용자의 작업이 종료되면 Thread Cache에 돌아가며 일정 개수 이상의 Thread가 Thread Cache에 존재 시에 해당 Thread를 종료합니다.
Thread에 관한 정보입니다. Threads_created 값이 오르지 않을 때 까지
Thread Cache Size를 설정하는 것으로 최적화가 가능합니다.
- Background Thread
(InnoDB O, MyISAM X):
여러가지 작업이 Background에서 처리됩니다.
- 인서트 버퍼를 병합하는 스레드
- ⭐️로그를 디스크로 기록하는 스레드
- ⭐️InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
- 데이터를 버퍼로 읽어 오는 스레드
- 잠금이나 데드락을 모니터링하는 스레드
읽는 작업은 주로 Foreground Thread에서 처리하여 쓰기 작업은
많은 작업이 Background Thread로 처리되기 때문에 스펙에 맞게
스레드 개수를 올릴 필요가 있습니다.
또한 읽기 작업은 지연이 불가능 하지만(상식적으로) 쓰기작업은 지연이 가능하며 InnoDB 역시 이러한 기능이 사용됩니다.
어디까지 Foreground Thread의 영역인가?
InnoDB Storage Engine은 데이터 버퍼나 캐시영역까지만 사용되며
MyISAM은 디스크 쓰기 작업까지 모두 처리합니다.
쿼리 실행 구조
쿼리 실행 관점에서 MySQL구조를 그림으로 표현
- Query Parser 쿼리 문장을 최소 토큰(어휘)로 분해 + 문법 오류 확인
- preprocessor 파서 과정에서 만들어진 트리가 구조적 문제 확인, 토큰에 매핑되는 객체가 존재하는지 확인 + 접근 권한 확인
- Optimizer 가장 중요한 파트, 들어온 쿼리를 가장 저렴한 비용으로 가장 빠르게 처리할지를 결정,
어떻게 해야 Optimizer가 나은 선택을 하도록 유도하는지가 중요함
데이터 딕셔너리, 시스템 테이블
MySQL Server 5.7까지느 테이블의 구조를 FRM 파일에 저장하고 일부 스토어드 프로그램 또한 파일 기반으로 관리했습니다.
문제가 될 수 있는 것은 이러한 방식은 트랜잭션을 지원하지 않습니다.
그래서 8.0부터는 구조 정보, 스토어드 프로그램 관련 정보를 모두 InnoDB에 모두 저장하도록 변경하였습니다.
그래서 변경 작업이 성공하면 모두 성공하고 실패하면 모두 실패합니다.
그리고 해당 정보들 모두 mysql.idb라는 파일명으로 저장이 되므로(다른 *.idb도 주의!) MySQL 디렉토리내의 해당 파일들은 정말로 조심해야 합니다.
InnoDB 관련 포스팅은 다음으로!
질문
Thread Pool VS Thead Cache
Community Edition에는 Thread Pool이 없는데 Thread Cache가 존재함
Thread Cache 설명이 Connection Pool 설명들을 때랑 동일함
