[MySQL 성능 최적화] Day 1 (p.2 ~ 21)

01. MySQL 아키텍처

MySQL은 아키텍처의 특성 덕분에 광범위한 목적에 유용하게 사용된다.
작은 개인 웹 사이트에서부터 대규모 엔터프라이즈 애플리케이션에 이르기까지 크고 작은 환경에서 잘 동작할 만큼 유연하다.
MySQL을 최대한 활용하려면 MySQL의 의도에 맞게 잘 활용할 수 있도록 해야 하고 그러기 위해서는 MySQL의 설계를 이해해야 한다

01장에서는 MySQL 서버 아키텍처를 살펴보고 스토리지 엔진 간의 주요한 차이점에 대해서 살펴볼 것이다.

MySQL의 논리적 아키텍처

MySQL의 구성요소가 함께 작동하는 원리를 잘 이해하면 서버를 이해하는데 도움이 된다.

• 1번째 계층 (클라이언트)

MySQL의 고유한 서비스보다는 대부분의 네트워크 기반 클라이언트/서버 도구 또는 서버에 필요한 연결 처리, 인증, 보안 등의 서비스가 포함되어 있음

• 2번째 계층

쿼리 파싱, 분석, 최적화 및 모든 기본 제공 함수를 포함해서 MySQL의 대부분의 지능적인 부분이 여기에 속한다.
또한, 스토리지 엔진에서 제공되는 모든 기능(ex. 프로시저, 트리거, 뷰)을 여기에서 사용할 수 있다.

• 3번째 계층 ⇒ 스토리지 엔진이 포함된 계층

MySQL에 저장된 모든 데이터를 저장하고 검색하는 역할을 담당. 다양한 스토리지 엔진이 있는데 각 엔진마다 장단점이 존재한다.

1) 서버는 스토리지 엔진 API를 통해 통신한다. API에서 스토리지 엔진 간의 차이를 숨겼기 때문에 쿼리 계층에서는 그 차이를 알지 못한다.
2) 수십개의 하위 수준 함수가 포함되어 있다
3) SQL을 구문 분석하거나 서로 통신하지 않고 단순히 서버의 요청에 응답만 한다

연결 관리 및 보안

• 연결 관리

기본적으로 각각의 클라이언트 연결은 서버 프로세스 내에서 고유한 thread를 갖는다.

연결 쿼리는 하나의 코어 또는 CPU에 존재하는 단일 쓰레드 내에서 실행된다.

서버는 즉시 사용할 수 있는 쓰레드의 캐시를 유지 관리하기 때문에 새로운 연결마다 매번 쓰레드를 생성하거나 폐기할 필요가 없다.
(쓰레드 풀링 플러그인을 허용하는 API 지원 - MySQL 5.5 이상부터는 잘 안씀)

• 보안

클라이언트(응용 프로그램)가 MySQL 서버에 연결되면 서버에서 인증해야 한다.
인증은 사용자 이름(user name), 호스트 및 암호(password)를 기반으로 한다.

클라이언트가 연결되면 서버는 클라이언트에서 보내는 각 쿼리에 대해 권한이 있는지 확인한다
(ex. 클라이언트가 world 데이터베이스의 Country 테이블에 접근하는 select 문을 요청할 수 있는지 여부)

데이터 파일 구조

버전 8.0에서 MySQL은 테이블 메타데이터를 테이블의 .ibd 파일에 포함된 데이터 딕셔너리로 재설계했다.
이렇게 하면 테이블 구조 지원 트랜잭션 및 원자 데이터 정의 변경에 대한 정보가 만들어진다.

작업 중에 테이블 정의 및 메타데이터를 검색하기 위해 information_schema에만 의존하는 대신
파티션 정의, 테이블 정의, 저장된 프로그램 정의, charset 및 데이터 정렬 정보는 LRU 기반 메모리 내 캐시인 딕셔너리 오브젝트 캐시를 사용한다.

즉, 테이블의 메타데이터를 데이터 딕셔너리 로 재설계하고 LRU 기반 메모리 내 캐시인 딕셔너리 오브젝트 캐시를 사용함으로써 서버가 테이블에 대한 메타데이터에 접근하는 방식이 바뀜으로써 I/O가 감소하고 효율성이 높아진다.
(특히, 테이블의 하위 집합이 가장 많은 활동을 인지하여 캐시에 통상적으로 있는 경우 더욱 효율성이 높아진다)

.ibd, .frm 파일은 테이블당 직렬화된 사전 정보(.sdi)로 대체된다.

InnoDB 엔진

InnoDB는 MySQL의 기본 트랜잭션 스토리지 엔진이다.

일반적으로는 롤백되지 않고 완료되는 많은 양의 단기 트랜잭션을 처리하도록 설계되었다.
성능과 자동 충돌 복구 기능 때문에 비트랜잭션 스토리지 요구 사항에도 널리 사용된다.

때문에, 스토리지 엔진을 공부하고 싶다면 InnoDB에 시간을 투자해서 최대한 깊이 학습하자.