MARIADB 5.5 ARCHITECTURE v1.0
|
13.06.04 |
1.0 |
|
|
|
|
|
|
|
|
|
1. MariaDB Architecture
(http://docs.oracle.com/cd/E19957-01/mysql-refman-5.5/storage-engines.html )
MariaDB Architecture 는 MySQL 과 동일하다.
상단의 그림은 MySQL 5.5 의 Architecture 이다.
2. Architecture Components
|
|
응용프로그램 |
Connectors Management Service & Utilities |
||||
|
MariaDB Server |
MariaDB Engine |
MySQL 엔진 |
커넥션 핸들러 |
|||
|
SQL 인터페이스 |
SQL 파서 |
SQL 옵티마이저 |
캐시 & 버퍼 |
|||
|
Storage Engine |
MyISAM, InnoDB, … |
|||||
|
|
OS & H/W |
디스크 파일 시스템, 데이터 및 로그 파일 |
||||
구성 요소 중 MySQL 과 대비되는 MariaDB 의 특이사항은 다음과 같다
l Storage Engine
NDB 를 지원하지 않음 (https://kb.askmonty.org/en/mariadb-storage-engines/ )
NDB 에 대해서 지원하지 않음 (disabled) 으로 명시되어 있는걸 보아 다른 엔진 사용에 대해 제약은 없는 듯 하다.
확실하게 사용가능한 (공식페이지에 소개되어 있는) 스토리지 엔진은 MyISAM, XtraDB / InnoDB 가 있다.
(주로 사용하는 Storage Engine 이다.)
다른 MySQL 기반과 구분되는 특징은 Cassandra 를 Storage Engine 으로 사용할 수 있다는 것이다.
이는 MariaDB 10.0.1 부터 지원한다. (https://kb.askmonty.org/en/cassandra-storage-engine/ )
3. Storage Engine
실질적으로 사용하게 되는 Storage Engine 은 아래와 같다.
l MyISAM
|
Memory |
Key Cache |
|
|
O/S cache |
OS system cache / buffer |
|
|
Disk |
Index file |
Data file |
MyISAM 의 Key cache 는 Index 만을 대상으로 하며, 테이블의 페이지는 그 대상이 아니다.
이 Storage Engine 에는 I/O 를 해결하기 위한 캐시나 버퍼링 기능이 없기에 이를 OS 에 의존한다.
운영체제의 캐시는 남는 메모리를 사용하는데 MyISAM 이 해당 영역을 사용할 수 있다는 것을 감안해야 한다.
l InnoDB (XtraDB)
MariaDB 는 XtraDB 를 사용한다.
XtraDB 는 Storage Engine 의 하나로 InnoDB 와 거의 동일하다.
PERCONA 에서 개발 된 Storage Engine 으로 MySQL 의 InnoDB 를 PERCONA 에서 개발한
XtraDB 의 백업도구 XtraBackup 을 가지고 백업/복구가 가능할 정도로 InnoDB 와 XtraDB 는 유사하다.
MariaDB 는 PERCONA 의 XtraDB 를 사용하며 기본적으로 enabled 상태이다.
AskMonty (공식페이지) 를 보면 PERCONA 의 지원 Storage 로 InnoDB/XtraDB 라 표시한 정도를 보면
유사를 넘어 동일하다고 봐도 무관할 정도이다.
InnoDB 의 아키텍쳐는 다음과 같다.
|
Memory |
InnoDB 버퍼 풀 |
언두레코드 |
|
인서트버퍼 |
||
|
페이지버퍼 |
||
|
로그버퍼 |
||
|
Disk |
테이블스페이스 |
시스템테이블스페이스 |
|
유저테이블스페이스 |
||
|
리두로그 |
||
|
언두로그 |
||
크게 메모리에 해당하는 부분과 디스크에 해당하는 부분이 있다.
MyISAM Storage 와 대비되는 부분으로는 OS 의 캐시에 의존하지 않는다는 것이다.
InnoDB 는 독자적으로 캐싱을 위한 메모리 영역을 가져간다.
각 요소들에 대한 부가 설명은 다음과 같다.
언두레코드 : 이를통해 MVCC 를 지원한다. MariaDB 는 read-committed 와 read-uncommitted 를 지원하는데
read-committed 의 경우 커밋되지 않은 타 세션의 데이터는 조회할 수 없다. 때문에 이 변경된 페이지가 아니라
변경 이전 버전의 페이지를 읽어야 하는데 이를 UNDO 를 사용해 구현한다.
이와 같이 동일 페이지에 대해 여러 버전을 가지고 컨트롤하기 때문에 Multi Version Concurrency Control 이라 표현한다.
인서트버퍼 : 변경해야 할 인덱스 페이지가 메모리상에 없는 경우 임시공간에 저장했다가 한번에 처리한다.
사용자에게 결과를 전달하기 전에 반드시 중복 여부를 체크해야 하는 유니크 인덱스는 인덱스 버퍼를 사용할
수 없다.
이 기능을 통해 I/O 를 효율적으로 사용한다.
페이지버퍼 : 페이지(오라클의 블록에 해당) 를 캐싱한다 ( 인덱스, 테이블 )
로그버퍼 : ORACLE 의 redo 에 해당한다.
테이블스페이스 : InnoDB 의 시스템 테이블스페이스는 공용테이블 스페이스에 위치한다.
유저 테이블스페이스의 경우는 file_per_ table 파라미터의 사용에 따라 공용으로 쓸 수도 있고,
테이블마다 각기 사용할 수도 있다.
리두로그와 언두로그는 로그버퍼, 언두레코드가 기록된다.
리두로그 파일의 경우 그룹 지정이 되는데 각 그룹은 하나의 멤버로 구성되어 있다.
InnoDB 스토리지의 특징
- InnoDB 의 모든 테이블은 pk 를 기준으로 정렬된 상태로 저장된다. (오라클의 IOT 를 생각)
- MVCC (Multi Version Concurrency Control) 를 이용해 LOCK 없이 읽기 작업이 가능
- FK 지원
- Deadlock 감지 (Rollback 부하가 가장 작은 세션을 강제종료한다.)
4. Primary Index and Secondary Index on InnoDB
Ref.C 에서 발췌
InnoDB 에서의 Index 는 Primary Index 와 Secondary Index 로 나뉘어진다.
Primary Index 는 테이블 생성할 때 지정하게 되어 있으며, 만약 지정하지 않는 경우
MariaDB 가 적합하다고 생각하는 컬럼을 Primary Index 컬럼으로 지정하여 생성하게 된다.
Secondary Index 는 Primary Index 외에 생성하는 모든 Index 에 해당된다.
Secondary Index 에는 인덱싱 된 컬럼의 값 외에 Primary Index 의 키 컬럼 값을 포함한다.
이 값을 가지고 Primary Index 를 탐색하여 값을 찾게 된다.
이러한 특징 때문에 Primary Index 키컬럼은 싱글컬럼의 짧은 길이의 데이터 타입을 사용한다.
반면 Primary Index 로 결합인덱스를 사용하고 긴 길이의 데이터 타입을 사용하게 되면
Secondary Index 의 특징 때문에 인덱스 자체 크기가 커지고 이로인해 I/O 가 다량 발생하게 된다.
5. References
A. Real MySQL | 위키북스
B. MariaDB | https://kb.askmonty.org/en/
C. XtraDB / InnoDB internals in drawing | http://www.mysqlperformanceblog.com/2010/04/26/xtradb-innodb-internals-in-drawing/
D. Index-Organized Tables and Clustered Indexes | http://use-the-index-luke.com/sql/clustering/index-organized-clustered-index