MySQL의 여동생, MariaDB와 친구되기

MySQL의 여동생, MariaDB와 친구되기

MySQL이 선마이크로시스템즈(이하 선)로 넘어갔음에도 불구하고 개발자들은 MySQL의 미래를 그리 어둡게 보지 않았다. 선은 오픈소스에 대한 열렬한 지지를 보내던 회사로 인식되고 있었기 때문이다.

 

하지만 선이 DBMS 거인 오라클에 인수되면서부터 그림자는 개발자들 사이에 드리워지기 시작했다. 자신의 경쟁 상대로 지목되던 업체, 오라클에게 MySQL이 넘어갔기 때문이다. 그동안 MySQL의 아버지격인 Monty의 구명 운동, 자바를 둘러싼 구글과 오라클의 마찰, 오라클의 보수적인 유지보수 정책 등 그동안의 오라클 행보는 오픈소스 진영을 비롯한 수많은 국내외 개발자들에게는 상대적으로 부정적인 이미지를 심어주고 있었다. 

이런 MySQL의 보이지 않는 리스크(?)를 피하기 위해 각 기업과 개발자들이 MySQL과 자매 관계인 오픈소스 MariaDB로 눈길을 돌리기 시작했다. 이와 함께 그 전부터 오라클의 대안으로 생각하고 있는 PostgreSQL도 MariaDB와 함께 눈길을 끌기 시작했다. MySQL과 호환되는 MariaDB에 대해 소개하고자 한다. MariaDB는 GPL v2 라이선스를 따르기 때문에, 오라클의 보수적인 자세로부터 자유로울 수 있다.

1. My와 Maria라는 이름은…

MariaDB은 MySQL의 창업자 중 한 명이자 핵심 개발자였던 Michael Widenius(Monty로 불림)가 시작한 오픈소스 데이터베이스다. MySQL의 소스 코드를 기반으로 몇 가지 기능을 추가하는 형태로 선보였다. MariaDB 탄생 배경은 MySQL Ab사가 선에게 인수되는 것으로 거슬러 올라간다. Monty는 개발 지침 차이 등으로 인해 2009년에 선을 떠나 ‘Monty Program Ab’사를 설립해 MariaDB 개발을 시작한다. Monty Program Ab는 Monty를 비롯한 MySQL Ab 출신의 개발자 여러 명이 근무하고 있다. MySQL의 My는 Monty의 딸 이름에서 따온 것이라고 한다. MariaDB의 Maria도 마찬가지다. 부모가 동일한 소스 코드를 기반으로 하기 때문에 MySQL과 MariaDB는 자매 관계라고 부를 수 있다. 

MariaDB의 목표는 다음과 같다. 

- MySQL의 호환성을 유지한다.
- 소스 코드를 개선해 MariaDB의 안정성과 신뢰성을 높인다.
- 가능하면 빠르게 새로운 기능을 추가한다.
- 성능과 신뢰성을 가진 Aria 데이터베이스 엔진을 만들자.

2. MariaDB 설치와 설정

MariaDB 정보는 Monty Program Ab가 중심이 돼 운영하는 AskMonty.org 사이트에서 대부분 얻을 수 있다. 여기서 ‘MariaDB Downloads’ 링크를 클릭하면 안정화 버전인 ‘MariaDB 5.5.27 Stable’로 이동한다. 운영체제를 ‘Generic Linux’(리눅스 환경이라는 가정)로 선택하고 mariadb-5.5.27-linux-x86_64.tar.gz를 내려 받으면 된다. 

1) 설치 과정
내려 받기가 완료되면 MariaDB 설치에 들어간다. 설치 방법은 MySQL과 거의 동일하다. 먼저 root 사용자로 MariaDB의 그룹 및 사용자를 만들었다는 가정 하에 설치 과정은 다음과 같다.

# wget http://mirror.yongbok.net/mariadb/mariadb-5.5.27/kvm-bintar-hardy-amd64/mariadb-5.5.27-linux-x86_64.tar.g 
# tar xvfz mariadb-5.5.27-linux-x86_64.tar.gz 
# ln -sf mariadb-5.5.27-linux-x86_64 mariadb 
# cd mariadb 
# scripts/mysql_install_db --user=mysql --datadir=/database/data5 
Installing MariaDB/MySQL system tables in '/database/data5' ... 
OK 
Filling help tables... 
OK 

To start mysqld at boot time you have to copy 
support-files/mysql.server to the right place for your system 

PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER ! 
To do so, start the server, then issue the following commands: 

./bin/mysqladmin -u root password 'new-password' 
./bin/mysqladmin -u root -h localhost password 'new-password' 

Alternatively you can run: 
./bin/mysql_secure_installation 

which will also give you the option of removing the test 
databases and anonymous user created by default. This is 
strongly recommended for production servers. 

See the MariaDB Knowledgebase at http://kb.askmonty.org or the 
MySQL manual for more instructions. 

You can start the MariaDB daemon with: 
cd . ; ./bin/mysqld_safe --datadir=/database/data5 

You can test the MariaDB daemon with mysql-test-run.pl 
cd ./mysql-test ; perl mysql-test-run.pl 

Please report any problems with the ./bin/mysqlbug script! 

The latest information about MariaDB is available at http://mariadb.org/. 
You can find additional information about the MySQL part at: 
http://dev.mysql.com 
Support MariaDB development by buying support/new features from 
Monty Program Ab. You can contact us about this at sales@montyprogram.com. 
Alternatively consider joining our community based development effort: 
http://kb.askmonty.org/en/contributing-to-the-mariadb-project/ 
http://kb.askmonty.org/en/contributing-to-the-mariadb-project/

이로써 MariaDB 설치는 끝난다.

2) 설정 방법
MariaDB의 초기 설정 방법도 MySQL과 거의 동일하다. 아래의 MariaDB가 디폴트로 제공하는 설정 파일들 중에서 적당한 파일을 선택-복사해 사용하면 된다.

 

설치 샘플에 포함된 옵션 값은 MySQL과 MariaDB가 거의 비슷하다. 하지만 스레드의 스택 크기(thread_stack)는 MariaDB가 약간 높게 240KB로 설정돼 있다.

# cp support-files/my-innodb-heavy-4G.cnf /etc/mariadb/my.cnf

이어서 my.cnf 파일을 편집한다. MySQL과 마찬가지로 기본적으로 InnoDB 관련 옵션이 주석(해제)돼 있기 때문에, InnoDB를 사용하는 경우에는 다음과 같이 주석을 해제한다. 그리고 일부 파라미터들을 수정해 준다.

#vi /etc/mariadb/my.cnf
innodb_buffer_pool_size = 2G
innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
innodb_data_home_dir = /database/data5
innodb_flush_log_at_trx_commit = 1
innodb_log_group_home_dir = /database/data5
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 50

3) 실행
MariaDB는 다음과 같이 실행한다.

# bin/mysqld_safe --defaults-file=/etc/mariadb/my.cnf --datadir=/database/data5 --user=mysql &
# bin/mysqladmin -u root password 'new password';
# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 25
Server version: 5.5.27-MariaDB-log MariaDB Server

This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

MariaDB가 구동됐다면, 로그인해 지원하는 엔진을 살펴보자. MariaDB가 새로 추가한 InnoDB, FEDERATED, Aria 스토리 엔진을 지원하는 것을 볼 수 있다.

MariaDB [(none)]> show engines;
+--------------+-------+---------------------------------------------------------------
| Engine |Support| Comment 
+--------------+-------+---------------------------------------------------------------
| MyISAM |DEFAULT| MyISAM storage engine 
| MRG_MYISAM |YES | Collection of identical MyISAM tables 
| CSV |YES | CSV storage engine 
| BLACKHOLE |YES | /dev/null storage engine(anything you write to it disappears)
| MEMORY |YES | Hash based, stored in memory, useful for temporary tables 
| InnoDB |YES | Percona-XtraDB, Supports transactions, row-level locking, 
and foreign keys
| ARCHIVE | YES | Archive storage engine 
| FEDERATED | YES | FederatedX pluggable storage engine 
| PERFORMANCE_SCHEMA | YES | Performance Schema 
| Aria | YES | Crash-safe tables with MyISAM heritage 
+--------------------+---------+-------------------------------------------------------
10 rows in set (0.00 sec)

3. MariaDB 특징

MariaDB는 MySQL의 소스 코드를 기반으로 몇 가지 기능을 추가하면서 탄생됐고, MySQL의 버그를 정기적으로 반영하기 때문에 MySQL 버전과 시간적 차이가 있을 수 있다. MySQL과 높은 호환성에 리눅스-윈도우-솔라리스- OS X 등 멀티 운영체제를 지원하며, 라이선스는 커뮤니티 버전(GPL v2)만 제공한다. 클라이언트 API나 프로토콜도 MySQL과 같고, 설치할 때 파일 이름과 파일 경로도 매우 비슷하다. 

이번 글에서는 MariaDB를 사용하면서 꼭 알아야 하는 특징들만 소개하고, 기타 자세한 특징과 추가 기능의 설명은 다음 회에서 소개하겠다.

 

MySQL의 5.1은 MariaDB 5.1-5.2-5.3과 호환되고, MySQL 5.5는 MariaDB 5.5와 깊은 호환성을 가진다. 이런 특성을 기억해뒀다가 사용하면 도움이 된다.

 

MySQL의 기본 스토리지 엔진인 InnoDB가 MariaDB에서는 Percona의 XtraDB로 바뀌었다는 점이 눈길을 끈다. MariaDB에서 InnoDB는 스토리지 엔진 이름으로 인식되기 때문에 특히 XtraDB라는 것을 개발자가 의식해 사용할 필요가 없이 그냥 사용하면 된다. Federated 스토리지 엔진도 FederatedX로 바뀌었다. Federated 엔진에서 지원하지 않았던 트랜젝션이나 파티션을 대응한 것이 FederatedX 엔진이다. 마지막으로 새로운 스토리 엔진인 Aria도 구현돼 있다. Aria는 MyISAM을 기반으로 한 것으로, MyISAM - MERGE - MEMORY 스토리지 엔진을 개발했던 엔지니어가 핵심 구성원으로 참여해 프로젝트를 진행됐다. 향후 MariaDB의 기본 스토리지 엔진을 목표로 현재 개발 중이며, 완전한 트랜잭션을 지원할 예정이다. 이미 MyISAM에서는 지원하지 않았던 충돌 안전성을 구현하고, 장애 발생 시 자?의 MySQL과 MariaDB의 옵티마이저를 비교해 보면, 디스크 액세스와 조인, 서브 쿼리 등에서 선택되는 실행 계획의 패턴이 많은 것을 알 수 있다.

 

이러한 수정의 활동들은 쿼리 속도를 향상시키기 위해 행해지고 있다. 다음은 실무에 가장 활용이 많이 적용되는 사례를 몇 가지를 소개한다. 

① 서브 쿼리 최적화
MariaDB 5.3부터 지원한 서브 쿼리 최적화를 사용하면 MySQL에서 꺼렸던 서브 쿼리를 빠르게 처리할 수 있다. 서브쿼리를 최적화하기 전에는 select type에서 DEPENDENT SUBQUERY가 보인다. "set optimizer_switch='semijoin=on,firstmatch=on,materialization=on,loosescan=on';" 명령어를 통해 서브 쿼리 최적화 실행을 하고 나서 플랜을 보면 테이블 t2의 "DEPENDENT SUBQUERY"의 액세스가 없어지고 t2도 "PRIMARY"에서 액세스된다. 그래서 쿼리 조회 결과가 향상을 가져온다.

MariaDB [test]> explain extended select count(*) from t1 
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+------+--------------------+-------+---+--------------------------+
| id | select_type | table | . | Extra |
+------+--------------------+-------+---+--------------------------+
| 1 | PRIMARY | t1 | . | Using where; Using index |
| 2 | DEPENDENT SUBQUERY | t2 | . | Using index; Using where |
+------+--------------------+-------+---+--------------------------+
2 rows in set, 1 warning (0.00 sec)
MariaDB [test]> select count(*) from t1 
-> where 
-> t1.gid> 0.3 * (select min(t2.gid) 
-> from t2
-> where t2.username = t1.username and t2.gid >50003);
+----------+
| count(*) |
+----------+
| 1090000 |
+----------+
1 row in set (2.92 sec) 
MariaDB [test]> set optimizer_switch='semijoin=on,firstmatch=on,materialization=on,loosescan=on';

MariaDB [test]> explain extended select count(*) from t1 
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+------+-------------+-------+---+--------------+
| id | select_type | table | . | Extra |
+------+-------------+-------+---+--------------+
| 1 | PRIMARY | t2 | . | Using where |
| 1 | PRIMARY | t1 | . | Using index |
+------+-------------+-------+--------+---------------+---------+---------+------------------+
2 rows in set, 1 warning (0.00 sec)
MariaDB [test]> select count(*) from t1 
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+----------+
| count(*) |
+----------+
| 1090000 |
+----------+
1 row in set (0.19 sec)

최적화가 없을 때 2.92초에서 최적화한 후 0.19.초까지 성능 개선을 가져왔다. 

② 서브 쿼리 캐시
"set optimizer_switch='subquery_cache=on';" 커맨드 실행 후에는 실행 계획에서는 <EXPR_CACHE>문자열을 추가하는 형태로 쿼리 캐시를 활용하고 있음을 알 수 있다. 물론 캐시를 기능을 켰을 때 성능이 좋았다.

MariaDB [test]> explain extended select count(*) from t1 
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+------+--------------------+-------+---+--------------------------+
| id | select_type | table | . | Extra |
+------+--------------------+-------+---+--------------------------+
| 1 | PRIMARY | t1 | . | Using where; Using index |
| 2 | DEPENDENT SUBQUERY | t2 | . | Using index; Using where |
+------+--------------------+-------+---+--------------------------+
2 rows in set, 1 warning (0.00 sec)
MariaDB [test]> select count(*) from t1 
-> where 
-> t1.gid> 0.3 * (select min(t2.gid) 
-> from t2
-> where t2.username = t1.username and t2.gid >50003);
+----------+
| count(*) |
+----------+
| 1090000 |
+----------+
1 row in set (2.90 sec)
MariaDB [test]> set optimizer_switch='subquery_cache=on';

MariaDB [test]> explain extended select count(*) from t1
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+------+--------------------+-------+---+--------------------------+
| id | select_type | table | . | Extra |
+------+--------------------+-------+---+--------------------------+
| 1 | PRIMARY | t1 | . | Using where; Using index |
| 2 | DEPENDENT SUBQUERY | t2 | . | Using index; Using where |
+------+--------------------+-------+---+--------------------------+
2 rows in set, 1 warning (0.00 sec)

MariaDB [test]> show warnings;
+-------+------+-------------------------------------------------------------------------+
| Level | Code | Message | 
+-------+------+-------------------------------------------------------------------------+
| Note | 1003 | select count(0) AS `count(*)` from `test`.`t1` |
| | | where <EXPR_CACHE><`test`.`t1`.`username`>(<IN_OPTIMIZER>(`test`. |
| | | `t1`.`username`, <EXISTS>(<PRIMARY_INDEX_LOOKUP>(<CACHE>(`test`.`t1`. |
| | | `username`) in t2 on PRIMARY where ((`test`.`t2`.`gid` >50003) |
| | | and (<CACHE>(`test`.`t1`.`username`)=`test`.`t2`.`username` |
| | | )))))) |
+-------+------+-------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [test]> select count(*) from t1 
-> where 
-> t1.username in (select t2.username 
-> from t2
-> where t2.gid >50003);
+----------+
| count(*) |
+----------+
| 1090000 |
+----------+
1 row in set (0.48 sec)

캐시 기능을 온 시킨 후 성능도 향상을 가져왔다는 것을 알 수 있다.

③ Index Condition Pushdown
인덱스를 사용하는 경우, B-Tree index를 취득한 후 table의 레코드에 액세스 데이터를 얻을 수 있다. 하지만 "Index Condition Pushdown" 기능은 인덱스 레코드가 불필요한 데이터 참조 없이 존재하는 데이터만 액세스해 확인할 수 있다. 효율성이 증가하게 된다.

explain select * from t1 where gid <50002; 
MariaDB [test]> explain select * from t1 where username between 'aaaajbjtcmtw66094' and 'kkkkkkkkkkkkkkkkk' and gid <50002; 
+------+-------------+-------+-------+--.+-------+-------------+ 
| id | select_type | table | type | . | rows | Extra | 
+------+-------------+-------+-------+---+-------+-------------+ 
| 1 | SIMPLE | t1 | range | . | 82820 | Using where | 
+------+-------------+-------+-------+---+-------+-------------+ 
1 row in set (0.00 sec) 

MariaDB [test]> set optimizer_switch='index_condition_pushdown=on'; 
Query OK, 0 rows affected (0.00 sec) 

MariaDB [test]> explain explain select * from t1 where username between 'aaaajbjtcmtw66094' and 'kkkkkkkkkkkkkkkkk' and gid <50002; 
+------+-------------+-------+-------+--.+-------+-----------------------+ 
| id | select_type | table | type | . | rows | Extra | 
+------+-------------+-------+-------+---+-------+-----------------------+ 
| 1 | SIMPLE | t1 | range | . | 37573 | Using index condition | 
+------+-------------+-------+-------+---+-------+-----------------------+ 
1 row in set (0.00 sec)

④ Multi Range Read
인덱스에서 로드할 행을 식별하고 필요한 데이터를 Rowid를 기준으로 정렬해 디스크에 데이터를 요청한다. Rowid로 데이터가 정렬됐기 때문에 디스크는 순차적(Sequential)으로 데이터를 읽어옴으로써 과도하게 헤더가 움직이지 않아도 됨을 의미한다. 그래서 스토리지 엔진에 편리한 순서(ROWID)에서 행을 로드해 속도를 높일 수 있다.

MariaDB [test]> explain select * from t1 where username between 'aaaajbjtcmtw66094' and 'kkkkkkkkkkkkkkkkk' and gid <50002; 
+------+-------------+-------+-------+--.+-------+-------------+ 
| id | select_type | table | type | . | rows | Extra | 
+------+-------------+-------+-------+---+-------+-------------+ 
| 1 | SIMPLE | t1 | range | . | 82820 | Using where | 
+------+-------------+-------+-------+---+-------+-------------+ 
1 row in set (0.00 sec) 

MariaDB [test]> set optimizer_switch='mrr=on,mrr_sort_keys=on,mrr_cost_based=off'; 
Query OK, 0 rows affected (0.00 sec) 

MariaDB [test]> explain select * from t1 where username between 'aaaajbjtcmtw66094' and 'kkkkkkkkkkkkkkkkk' and gid <50002; 
+------+-------------+-------+-------+--.+-------+---------------------------------+ 
| id | select_type | table | type | . | rows | Extra | 
+------+-------------+-------+-------+---+-------+---------------------------------+ 
| 1 | SIMPLE | t1 | range | . | 37573 | Using where; Rowid-ordered scan | 
+------+-------------+-------+-------+---+-------+---------------------------------+ 
1 row in set (0.00 sec)

4) 기타 추가 기능들

① Pool of Thread
다음 옵션에서 시작해 연결 스레드의 동시 실행을 조정할 수 있으며, (실행 시간이 짧은) 짧은 쿼리에서 일부 테이블/행 잠금이 있으면 성능을 올릴 수 있다. Pool of Thread를 사용하려면 먼저 컴파일 시 --with-libevent 옵션을 추가해 컴파일한다. 구동 시 MariaDB에서 디폴트 thread_handling은 one-thread-per-connection이므로 스레드 풀링을 사용하려면 --thread_handling=pool-of-threads 옵션을 지정해야 한다.

mysqld --thread-handling=pool-of-threads --thread-pool-size=20

② Table Elimination
View에서 데이터를 검색할 때 실행 계획을 최적화한다. 다음과 같이, t1 ~ t4를 사용해 만든 t_1234_v 뷰에 액세스할 때 필요한 테이블에만 액세스하게 된다는 것이다.

MariaDB [test]> create view t_1234_v as 
-> select t1.username, t1.pass, t1.uid, t1.gid 
-> from t1 
-> left join t2 on t1.username = t2.username 
-> left join t3 on t1.username = t3.username 
-> left join t4 on ( 
-> t1.username = t4.username and 
-> t4.gid = (select max(sub.gid) from t4 sub where sub.username = t4.username) 
-> ); 
Query OK, 0 rows affected (0.00 sec) 

MariaDB [test]> explain select count(*) from t_1234_v where gid >50002; 
+----+------------+---------+--------+---+-------------------+-------------+ 
| id | select_type| table | type | . | ref | Extra | 
+----+------------+---------+--------+---+-------------------+-------------+ 
| 1 | SIMPLE | t1 | index | . | NULL | Using index | 
| 1 | SIMPLE | t2 | eq_ref | . | test.t1.username | Using where | 
+----+------------+---------+--------+---+-------------------+-------------+

③ INFORMATION_SCHEMA에 테이블 추가
INFORMATION_SCHEMA에 4개의 테이블이 추가돼 SELECT 문에서 사용자와 테이블, 인덱스의 통계 정보를 볼 수 있도록 돼 있다.

 

4. MySQL과 MariaDB 성능 비교

 

2) 테스트 결과

① Read 성능 비교
위와 같이 동일한 환경에서 MySQL과 MariaDB에 username 조회 키를 랜덤하게 입력해 테이블을 유니크하게 조회해 Read 성능을 도출했다. 한 레코드의 사이즈는 1024바이트였고 전체 로우 건수는 1000만건이다.

 

Read 성능의 결과는 MariaDB가 근소한 차이로 앞섰다. 클라언트에 대응하는 pool-of-threads 옵션을 주어서 그런 것 같다. 

② Write 성능 비교
MySQL과 MariaDB에 유니크 한 username을 랜덤하게 발생시켜 Insert 문을 수행해 Write(Insert) 성능을 도출했다.

 

Write 성능은 그래프와 같이 클라이언트 구간별로 조금씩 차이가 나지만, 전체 흐름 상으로 봤을 때 MySQL과 MariaDB는 별 차이가 없다.

5. 운영하면서 염두해 둘 점

1) 옵티마이저
MariaDB는 다양한 조인이 추가돼 그들의 옵션이 필요한 쿼리들에 의해 켜진 상태에서 운영하는 경우가 많다. 그렇게 되면 정상적인 쿼리가 Nested Loop 조건으로 실행되는 것이 빠른데, 다양한 조인 기법에 의해 다른 형태로 쿼리 플랜이 적용될 수 있다. 이는 다양한 옵티마이저의 기능 추가가 오히려 해가 될 수 있다는 의미이기도 하다. 결국 모든 쿼리의 플랜을 확인하고 운영해야 한다. 더불어 Join cache level을 적절하게 설정해야 조인이 원하는 방식으로 이뤄진다.

 

2) 스토리지 엔진
NDB 등 MySQL에서 제공하는 스토리지 엔진이 자동 플러그인되지 않은 탓에 직접 설치해야 하고, 이에 따라 제대로 설치 및 동작될지 불확실성이 존재한다. 

3) MySQL에 비해 얇은 사용자층
사용자층이 두텁지 않아 다양한 이슈 발생 시 다양한 논의를 통해 해결해나가는 경로가 상대적으로 제한적이다. 따라서 얘기치 않은 문제 발생시 상대적으로 불리할 수 있다. MySQL에서 파생됐다고 하더라도 MariaDB에 대한 커뮤니티가 덜 활성화돼 MySQL보다 노하우 공유의 폭이 좁을 수밖에 없는 것이다.

결론

기능이나 성능에서 MySQL과 MariaDB는 큰 차이가수 있었다. 거기에 추가로 MariaDB가 MySQL의 기능 개선이나 기능 추가를 목표로 삼았기 때문에 MySQL에 없는 장점이 있다. 그래서 MariaDB의 특성을 분명히 파악한 다음, MariaDB의 서브 쿼리 최적화, 서브 쿼리 캐시, Index Condition Pushdown, Multi Range Read 등의 옵티마이저의 장점, 추가된 기능에서의 Table Elimination, Virtual Columns, Group commit, Dynamic Columns 등의 기능들을 십분 활용한다면 분명 MySQL보다 더 효율성이 있지 않을까 생각해 본다. 

또한 오라클 진영해 편입됨으로 인해 오픈소스 프로젝트로서 MySQL의 불확실한 미래는 견제 솔루션으로서 MariaDB와 PostgreSQL이 떠오르는 배경이 되지 않을까 예상된다. 다음 회에서는 MariaDB의 숨은 장점에 대해 알아본다.

출처 : 한국데이터베이스진흥원                               ▶ MySQL의 여동생, MariaDB와 친구되기 

 

제공 : DB포탈사이트 DBguide.net                     ▷ MariaDB의 숨은 장점 제대로 알아보기