MySQL 아키텍처 이해하기 (작성중)

현재 회사에서는 MariaDB, MySQL, PostgreSQL을 모두 쓰고 있습니다. 인프라 엔지니어로서 MariaDB, MySQL, PostgreSQL의 내부 아키텍처를 배우기 위해서 작성되었습니다.

개요

본 문서는 18.11 Overview of MySQL Storage Engine Architecture를 읽고 이해한 내용을 정리하는 문서입니다.

읽기 전에

본 문서는 이미 MySQL을 사용하는 엔지니어를 위해 작성되었습니다.
따라서 기본적인 SQL 및 MySQL에 대해서는 서술하지 않습니다.
주된 내용은 MySQL이 쿼리를 어떻게 처리하는지를 다룹니다.
모든 내용은 최대한 공식문서를 참조하였으며, 일부 특수한 사례에서 개인 게시글을 참조하였습니다.

또한 얼마 전에 MariaDB 아키텍처 이해하기 게시글을 썻습니다.
MariaDB는 MySQL에서 파생된 오픈소스 데이터베이스로 많은 부분에서 유사한 점을 가지고 있습니다. 또한 기본 Storage Engine*으로 InnoDB를 쓰기 때문에 큰 차이점이 없음을 명시하고자 합니다.

Pluggable Storage Engine이란?

MySQL 서버는 실행 중인 MySQL 서버 Storage Engine*을 로드하거나 언로드할 수 있어서 Pluggable Storage Engine*이라고 부릅니다. - [Ref]

• INSTALL

  INSTALL PLUGIN <Plugin Name> SONAME '<Library Name>'
  
  -- Example
  INSTALL PLUGIN example SONAME 'example.so'

• UNINSTALL

  UNINSTALL PLUGIN <Plugin Name>
  
  -- Example
  UNINSTALL PLUGIN example

MariaDB와 마찬가지로
MySQL도 Storage Engine*에 테이블 생성, 조회, 인덱스 캐싱을 위임합니다. 이로 인해 DBA가 특정 어플리케이션 요구사항에 맞는 전문 Storage Engine*을 선택할 수 있으면서도 코드 레벨의 변경사항이 없도록 보호받을 수 있습니다.

즉, 서로 다른 Storage Engine*을 사용하면 서로 다른 기능을 제공받지만
어플리케이션 코드에는 이런 차이점을 적용할 필요가 없습니다. - [Ref]

지원하는 Storage Engine*

MySQL에 설치된 Storage Engine*은 아래 쿼리로 확인 가능합니다. - [Ref]

SHOW ENGINES

MySQL은 다양한 종류의 Storage Engine*을 제공하고 있습니다.
기본으로는 Transaction이 보장되는 ACID를 충족하는 InnoDB를 사용합니다.
하지만 특수 요구사항이 있다면 MyISAM, Memory, CSV, Archive, Backhole, Federated, Example 등을 선택할 수도 있습니다.

하지만 Transaction, Persistence, B-Tree Index 등의 기능 보장이 없을 수 있습니다.
따라서 세부 사항을 반드시 확인하고 작업을 진행해야 합니다.

ACID란 무엇일까?
ACID(Atomicity, Consistency, Isolation, Durability)
Transaction이 보장된다고 할 때 ACID를 달성한다라고 말합니다.
이는 모든 SQL 작업이 개별적으로 작동하며 Transaction 성공과 실패에 따라서
데이터 및 SQL의 결과가 손실되지 않는 중요한 특징을 의미합니다.

따라서 이러한 특징을 가진 InnoDB를 기본 Storage Engine으로 사용합니다.
InnoDB는 Undo, Redo Log를 활용하여 이를 달성합니다. - [Ref]

InnoDB