글을 작성하기 전에
대부분의 RDBMS는 아키텍처 부분에서 많은 공통점을 가지고 있습니다.데이터를 궁극적으로 디스크에 저장하지만, 데이터베이스의 일부를 메모리에 저장하고 유지함으로써 더 빠른 성능을 유지할 수 있도록 합니다. 또한 ACID 를 충족하기 위해 대부분 WAL 기법을 사용하고 있습니다.이 글은 MySQL System Architectire 를 PostgreSQL과 비교를 통하여 정리해보겠습니다.
MySQL System Architecture (PostgreSQL과 비교를 통하여)
MySQL의 시스템 아키텍처는 데이터베이스(MySQL) 엔진과 스토리지 엔진으로 분류한다.
MySQL 엔진에서 쿼리의 수행을 담당하고, 그 쿼리에 결과에 따른 데이터 저장의 부분은 스토리지 엔진에서 담당한다.
PostgreSQL에서는 하나의 스토리지 엔진을 지원하므로 해당 분류에 대해 들어본 경험이 적을 것으로 예상된다.
(PostgreSQL 12버전 이후 부터 플러그인을 통한 새로운 스토리지 엔진에 대해 검토가 진행 중)
해당 포스팅에선 MySQL 5.5버전 부터 기본 엔진 스토리지로 채택된 InnoDB 기준으로 작성한다.
MySQL Process/Thread
MySQL은 멀티 프로세스 기반이 아닌, 멀티쓰레드 기반으로 동작한다.
그러나 서버에 MySQL이 시작되면 기동된 두개의 프로세스를 확인 할 수 있다.
그 중 mysqld은 실제 서비스 데몬이며 mysqld_safe은 MySQL이 비정상 종료되는 경우 다시 기동하는 역할 (일부 Postmaster와 동일한 역할)을 한다.
Foreground Thread
PostgreSQL에서 세션마다 Backend Process 생성되는 것처럼, MySQL에서는 최소한 MySQL에 접속된 세션 만큼 Foreground Thread가 존재한다. PostgreSQL에서는 데이터 블록을 디스크로 부터 Shared Buffer에 올리고, 디스크에 쓰는 작업까지 수행하지만 MySQL Foreground Thread는 메모리에 대한 Read/Write 작업만을 담당한다.
만약 세션이 종료되면 해당 Thread는 쓰레드 캐시로 반환되고, 이때 쓰레드 캐시에 일정 개수 이상의 대기 중인 쓰레드가 있을 시 쓰레드 캐시에 유지 하는 것이 아닌 해당 Thread를 종료시키게 된다.
PostgreSQL에서는 Connection 생성과정에 자원소모가 매우 높아, PgBouncer나 PgPool 같은 Pool 관리 도구를 사용하는 경우가 있는데 MySQL은 Thread 구조로 되어 있어 세션 생성 시 비용이 MySQL 보다 적다
Background Thread
Master Thread
- Background 쓰레드에 대한 관리 및 다양한 작업들의 스케줄링을 담당
- 과거 버전일 수록 Master Thread가 하드웨어 리소스와 직접적으로 연결되는 일을 많이 하였으나, 버전 업에 따라 분리되는 추세
Change Buffer Thread
- Change Buffer(구 insert Buffer)를 병합 하는 쓰레드
Log Thread
- 로그를 디스크로 기록하는 쓰레드
- 대부분의 관계형 데이터베이스에서는 ACID(그중 A,D)를 위해 writer ahead log 기법을 사용한다. 그를 위해 사용되는 쓰레드
- 트랜잭션 로그를 작성
- PostgreSQL에서 walwriter 역할 ( logger와 다름)
Read Thread
- 다양한 유형의 Read 요청을 처리
Write Thread
- 다양한 유형의 Writer 요청을 처리
- PostgreSQL의 checkpointer 역할
Page Cleaner Thread
- Buffer Pool에 있는 dirty page를 Flush
- Master Thread 에서 수행하는 작업이였지만 Page Cleaner Thread 가 하도록 분리
- PostgreSQL의 background Writer 역할
Purge Thread
- Marking 처리(rollback) 된 ROW를 제거하는 작업을 담당
- 5.5버전에 처음 도입 되었으며 5.6 버전부터 Default로 Master Thread와 분리
- 처리 방식과 수행 조건이 매우 다르지만 PostgreSQL에서 autovacuum process와 비슷한 역할을 할 수 있을 것으로 보임
(그림 출처 및 참고 자료)
https://velog.io/@rime/RealMySql-04-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%981(Real MySQL 8.0 1권 내 사진 자료)
'MySQL & MariaDB' 카테고리의 다른 글
| MySQL GTID 복제 환경에서 Reset Master/Reset Slave 명령어 (0) | 2022.12.27 |
|---|---|
| MySQL Multi Source Replication(MSR) 실습 (0) | 2022.12.26 |
| MySQL GTID Replication 실습 (0) | 2022.12.22 |
| [Real MySQL 8.0] 02. 설치와 설정 & 03. 사용자 및 권한 (0) | 2022.10.06 |
| MySQL System Architecture - 2. Memory (0) | 2022.07.06 |
