1. 글로벌 메모리
글로벌 메모리 영역은 클라이언트의 스레드 수와 관계없이 한 개의 메모리 공간만 할당이 된다. 하지만 필요에 따라 2개 이상의 메모리 공간을 할당받기도 하지만, 스레드 수와는 관계없으며, 생성된 글로벌 영역이 다수라 하더라도 모든 스레드에 의해 공유된다.
- InnoDB 버퍼 풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB 리두 로그 버퍼
- 테이블 캐시
2. 로컬 메모리
로컬 메모리는 세션 메모리 영역이라 표현하기도 하며, DB 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역이다. 클라이언트가 DB 서버에 접속하면 DB 서버에서는 클라이언트 커넥션으로부터 요청 처리를 위해 스레드를 하나씩 할당하게 된다. 클라이언트 스레드가 사용하는 메모리 공간이라고 해서 클라이언트 메모리 영역이라고도 한다. 클라이언트와 DB서버와의 커넥션을 세션이라고도 하기 때문에 로컬 메모리 영역을 세션 메모리 영역이라고도 표현한다.
- 바이너리 로그 캐시
- 정렬 버퍼
- 조인 버퍼
- 네트워크 버퍼
3. 플러그인 스토리지 엔진 모델
MySQL의 특징 중 하나가 플러그인 모델이다. 플러그인 해서 사용할 수 있는 것이 스토리지 엔진만 있는 것은 아니다. 전문 검색을 위한 검색어 파서도 플러그인 형태로 개발해서 사용할 수 있으며, 사용자 인증을 위한 native Authenication과 Caching SHA-2 Authentication 등도 플러그인으로 구현되어 제공된다. MySQL은 이미 기본적으로 많은 스토리지 엔진을 보유하고 있다. 하지만 기본적으로 제공되는 엔진 이외에 부가적인 기능을 제공하는 스토리지 엔진이 필요하기도 하며, 이런 사항을 다른 전문 업체 또는 사용자가 직접 스토리지 엔진을 개발하는 것도 가능하다.
쿼리가 실행되면 대부분의 작업이 MySQL엔젠에서 처리하고, 마지막에 데이터 읽기와 쓰기 작업만 스토리지 엔진에 의해 처리된다. 만약 사용자가 스토리지 엔젠을 새로 만든다 해도 DBMS 전체 기능이 아니 일부분의 기능만 수행하는 엔진을 생성한다는 의미이다.
데이터 읽기/쓰기 작업은 대부분 1건의 레코드 단위(특정 인덱스의 레코드 1건 읽기 or 마지막 읽은 레코드의 다음 또는 이전 레코드 일기와 같이)로 처리된다. 그리고 MySQL을 사용하다 보면 핸들러(Handler)는 MySQL 서버의 소스코드로부터 온 표현인데, MySQL 엔진이 스토리지 엔진을 조정하기 위해 핸들러라는 것을 사용한다.
MySQL 엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야 한다. ('Handler_ '로 시작하는 상태 변수는 MySQL 엔진이 각 스토리지 엔진에게 보낸 명령의 횟수를 의미하는 변수) MySQL에서 MyISAM이나 InnoDB와 같이 다른 스토리지 엔진을 사용하는 테이블에 대해 쿼리를 실행하더라고 MySQL의 처리 내용은 대부분 동일하며, 단순히 데이터 읽기/쓰기 영역의 처리만 차이가 있을 뿐이다. 실직적인 GROUP BY나 ORDER BY 등 복잡한 처리는 스토리지 엔진 영영이 아니라 MySQL 엔진의 처리 영역인 '쿼리 실행기'에서 처리된다.
스토리지 엔진은 'SHOW ENGINES'를 통해 아래와 같이 확인해볼 수 있다.
ARCHIVE, BLACKHOLE, MRG_MYISAM, FEDERATED, MyISAM, PERFORMANCE_SHCEMA, InnoDB, MEMORY, CSV
MySQL에 포함되지 않는 스토리지 엔진을 사용하려면 MySQL 서버를 다시 빌드해야 한다. 하지만 플러그인 형태로 빌드된 스토리지 엔진 라이브러리를 다운로드해서 끼워 넣기만 하면 사용할 수 있다. (SHOW PLUGINS 명령으로 확인 가능)
MySQL 서버에서는 스토리지 엔진뿐만 아니라 다양한 기능을 플러그인 형태로 지원한다. 인증 및 전문 검색 파서, 쿼리 재작성 등 플러그인이 있다면, 비밀번호 검증과 커넥션 제어 등에 관련된 다양한 플러그인이 제공된다. 또한 MySQL 서버의 기능을 커스텀하게 확장할 수 있게 플러그인 API가 매뉴얼에 공개되어 있으므로 기존 DB 서버에 제공하던 기능들을 확장하거나 완전히 새로운 기능들을 플러그인을 이용해 구현할 수도 있다.
4. 컴포넌트
MySQL 8.0의 비밀번호 검증 기능은 컴포넌트로 개선됐다.
validate_password 컴포넌트 설치: INSTALL COMPONENT 'file//component_validate_password';
설치된 컴포넌트 확인: SELECT * FROM mysql.component;
플러그인과 동일하게 컴포넌트도 설치 시 새로운 시스템 변수를 설정해야 할 수도 있다.
5. 쿼리 캐시
DB 서버에서 쿼리 캐시는 요청에 대한 빠른 응답이 필수인 웬 응용 프로그램에서 매우 중요한 역할을 한다. 쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시 하고, 같은 SQL 쿼리가 실행이 되면 테이블에 접근하지 않고 즉시 결과를 반환하기 때문에 성능적으로 매우 큰 장점이 있다. 하지만 쿼리 캐시는 테이블의 데이터가 변경되면 캐시에 저장된 결과 중에서 변경된 테이블과 관련된 것들은 모두 삭제해야 했다. 결과적으로 동시 처리 성능 저하를 야기시켰다. 또한 MySQL 서버가 발전하면서 성능이 개선되는 과정에서 쿼리 캐시는 많은 버그와 성능 저하의 원인이 되기도 했다.
결국 MySQL 8.0으로 올라오면서 쿼리 캐시는 MySQL 서버의 기능에서 제거되었다. 사실상 쿼리 캐시 기능은 데이터 변견이 거의 없이 읽기 작업만 있는 서비스 환경에서는 매우 뛰어난 성능을 발휘하지만 실제 환경에서 쿼리 캐시 기능이 큰 활약을 하는 서비스는 많지 않다. 결과적으로 MytSQL 서버에서 쿼리 캐시를 제거하는 것을 추천한다.
'IT' 카테고리의 다른 글
MysqlDB - Where Like '%%' 텍스트 검색 성능 개선 (n-gram) (0) | 2023.04.25 |
---|---|
리눅스 디렉터리 구조 (0) | 2022.10.05 |
MySQL 아키텍처 - 1 (0) | 2022.09.26 |
MySQL 사용자 계정 관리 - 1 (0) | 2022.09.21 |
MySQL 정적 변수와 동적 변수 (0) | 2022.09.19 |
댓글