Embian Blog

이번에 소개할 MySQL 클론은 TokuDB인데, 엄밀히 말해서 TokuDB는 MySQL의 클론이라고는 할 수가 없다.

TokuDB는 MySQL이나 MariaDB에서 사용할 수 있는 새로운 Storage Engine인데, 이게 또 상당히 특이하고 흥미로운 Storage Engine이다.

4. TokuDB

TokuDB는 TokuTek사에서 개발한 Database Storage Engine으로 MySQL, MariaDB에서 사용할 수 있다.

TokuDB는 처음에는 Open source가 아닌 쉐어웨어로 시작했다. 40G까지는 무료로 사용할 수 있고, 그 이상은 년 400달러 정도의 금액을 지불하는 라이센스 정책을 쓰다가 얼마지나지 않아 30일까지만 무료로 사용할 수 있도록 라이센스 정책이 바뀌었다. 그러다가 최근 다시 Open source로 라이센스가 바뀌었는데, 1년사이에 라이센스 정책이 두번이나 바뀌어서 살짝 불안한 감이 있다.

그래서 현재 라이센스 정책은 MySQL처럼 Community Version은 open source로 Enterprise Version은 커머셜로 두가지 라이센스 정책을 가지고 있다.

Community와 Enterprise의 차이점도 MySQL가 흡사한데, 프로그램 자체에는 없는 듯 하고 다만 Enterprise는 테크니컬 서포트가 추가되는 형태인듯 하다.

1. 특징

- 데이터 Insert 속도

InnoDB는 Primary key를 데이터의 물리적인 저장 주소로 사용한다. 그래서 auto increment 값을 primary key로 설정하면 굉장히 빠른 데이터 insert 속도를 낼 수 있다. 하지만 auto increment 값이 아닌 다른 값(예를 들어 varchar나 순서가 뒤죽박죽인 int 데이터)을 pk로 잡을 경우 데이터 insert 속도는 곤두박질 칠수 밖에 없는 구조를 가지고 있다. 반면 TokuDB는 pk의 데이터 유형에 상관 없이 빠르고 일정한 insert 속도를 낼 수 있다.

- 데이터 indexing

TokuDB는 index 구조로 B-Tree가 아닌 TokuTec사에서 특허를 낸 Fractal-Tree 구조를 사용하고 있는데, 이 Fractal-Tree의 알고리즘이 MySQL이나 기타 DB에서 흔히 사용되는 B-Tree보다 성능이 뛰어나고 단편화가 일어나지 않는 구조라고 한다.

그래서 index 기반의 query들(select, update, delete)에서 특히 더 좋은 성능을 볼 수 있다.

뿐만 아니라 단편화(Fragmentation)가 일어나지 않는 특징 때문에 장시간이 지나도 성능 하락이 발생하지 않는다.

B-Tree는 처음 Tree가 구성되어 있을 때에는 양쪽 Balance가 잘 맞기 때문에 빠르게 이진탐색이 가능하지만, 중간 중간 index가 추가, 삭제, 변경이 됨에 따라 양쪽 Balance가 조금씩 무너지는 단편화가 발생하게 되는데, 단편화가 심해질 경우, DB의 성능도 급격하게 떨어지기 때문에 주기적으로 몇시간 또는 몇일에 걸친 index rebuild나 optimize가 필요하다.

하지만, Fractal-Tree는 단편화가 일어나지 않기 때문에 성능 저하도 발생하지 않고, 주기적인 optimize도 필요가 없다. (이 부분은 테스트를 해보지 않아서 전적으로 TokuTec사의 주장을 바탕으로 작성함)

- 데이터 압축

사실 이 특징이 TokuDB의 가장 큰 장점이라고 할 수 있다. TokuDB는 두가지 압축 레벨을 제공하고 있는데, 아무런 설정 없이 데이블을 생성하면 기본 압축 레벨이 적용 된다. 기본 압축일 경우 데이터의 용량은 InnoDB에 비해 3~6배까지 데이터의 용량을 줄어든다. 또한 최대 압축일 경우 약 10배의 압축결과를 보여주는데, 이건 눈으로 보지 않으면 믿기지 않은 결과 일것이다. (실제로 테스트 해본 결과 정말 믿기 힘들정도로 용량이 들어든다.)

데이터는 압축 할 수 있다고 치고, 그럼 압축된 데이터 때문에 query 성능이 떨어지지 않을까 생각했는데 그렇지도 않다. 앞에서도 언급했지만, InnoDB보다 전반적으로 빠른 query 성능을 보여준다. 심지어 최대 압축일때도 InnoDB보다 빠르다. 물론 cpu를 조금 더 쓰기는 하지만, 생각만큼 cpu load가 올라가지 않아서 테스트 내내 놀라움을 금치 못했다.

- Flash Drive(SSD) 최적화

B-Tree는 작은 블럭단위로 write가 발생하지만, Fractal-Tree는 큰 블럭단위로 write가 발생하는데, 이는 SSD의 수명이나 성능에 많은 영향을 미친다. (TokuDB가 SSD에 보다 더 적합하다고 볼 수 있다.)

- Hot Schema, Hot Index 기능

"Hot"이라는 말은 여기서는 실시간이라는 뜻으로 이해하는 것이 좋을 듯 하다.

InnoDB는 새로운 컬럼이나 인덱스를 추가하기 위해 서비스를 중단(Table Lock이 걸리기 때문)해야 하지만, TokuDB는 서비스중에 Table Lock 없이 새로운 컬럼이나 인덱스를 추가 할 수 있다.

- 빠른 복구 기능

InnoDB는 table 이 깨졌을 경우 이를 복구하는데 수분에서 몇시간까지의 시간이 필요한다. TokuDB는 몇초만에 데이터 복구가 가능하다.

- 개발 편의성

TokuDB는 MySQL과 MariaDB에서 사용할 수 있는 Storage Engine으로 사용법은 MySQL이나 MariaDB와 똑같으며, 기존 DBMS가 제공하는 함수기능들을 모두 사용할 수 있다. 

TokuDB를 사용하기 위해 따로 학습이 거의 필요 없고 다만, tokuDB Engine tunning을 위해 my.cnf에 사용할 수 있는 configuration 몇가지만 알면 된다.

2. 테스트 결과

약 3억건의 Record를 가지는 데이터를 CSV 파일로 준비해서 InnoDB와 TokuDB에 각각 Bulk insert, select query를 날리는 테스트를 진행했다. (CSV파일의 총 용량은 22G)

- InnoDB

a. Bulk insert에 걸린 총 시간: 49분 22초

b. insert 후 DB size: 15G

c. select count query에 걸린 시간: 53초

d. index key add에 걸린 시간: 18분 26초

e. 부하테스트 툴을 이용한 query test: 초당 약 500건 처리

- TokuDB (기본 압축 레벨)

a. Bulk insert에 걸린 총 시간: 106분 14초 (primary key가 auto_increment값이라서 그런지 InnoDB가 훨씬 빨랐음)

b. insert 후 DB size: 3.7G (용량이 약 1/4로 줄어듬)

c. select count query에 걸린 시간: 44초 (약간 성능 향상)

d. index key add 에 걸린 시간: 4분 49초 (상당히 빨라졌음)

e. 부하테스트 툴을 이용한 query test: 초당 약 700건 처리 (약 1.4배 향상)

- TokuDB (최대 압축 레벨)

a. Bulk insert에 걸린 총 시간: 105분 52초

b. insert 후 DB size: 1.9G (InnoDB대비 8배 이상)

c. select count query에 걸린 시간: 44초

d. index key add 에 걸린 시간: 5분 27초

e. 부하테스트 툴을 이용한 query test: 초당 약 700건 처리

** 특이사항: 기본 압축 레벨에 비해 성능 하락은 거의 없지만, cpu load가 조금 더 올라갔고, Bulk insert 중 알 수 없는 이유로 2차례 Connection이 끊어짐, 그리고 약 1천건 정도의 데이터가 들어가지 않음 (최대 압축 레벨은 서비스에 쓰기에는 좀 불안 할지도.....)

- 테스트 결과에 대한 추가 설명

InnoDB와 TokuDB의 Insert 시간을 비교해 보면 2배 이상의 차이가 나는데, 이는 auto_increment 값을 primary key로 사용하고 있는 상태이기 때문으로 보이며, 순차적인 insert가 일어나는 경우에는 InnoDB가 배 이상의 속도를 내는 것으로 보인다.

하지만 auto_increment 데이터가 없는 상태에서 1천만건의 데이터 insert 속도를 비교했을 때는 InnoDB는 약 3분, TokuDB는 약 48초 정도가 걸렸는데, 데이터의 건수가 많아질수록 그 차이는 벌어질 것이다.

DB의 용량을 살펴 보면 TokuDB가 InnoDB에 비해 4배 이상 작으며, 최대 압축일 경우 8배까지 그 차이가 벌어지는 것을 볼수 있다.

부하테스트 툴을 이용한 query 테스트는 전반적으로 TokuDB가 우수한 것을 볼 수 있는데, 부하테스트의 경우 텟그트 환경중 네트워크 속도가 받혀 주지 않아 TokuDB의 경우는 실제로 위의 값보다 충분히 더 많은 초당 처리 갯수를 보일 수 있을 것으로 예상된다.

최대 압축 테스트중 2회 정도 Connection이 끊기는 현상이 발생했고, insert 후 record 갯수가 1천개 정도 적었는데, 이것이 최대 압축 라이브러리의 문제인지, 아니면 다른 외부요인이 있었는지는 확인하지 못했다.

이번에는 MySQL 클론들 중에 맏형격인 Drizzle에 대해서 적어 볼까 한다.

3. Drizzle

Drizzle은 Cloud 환경 기반 Database이다. 

Drizzle은 Cloud 환경에 최적화 되었으며, 경량이고(하지만 고성능), 어떤 특정 회사가 개발하고 소유하는 것이 아니라 개발자 커뮤니티를 통해 개발되고 공유되고 있다. 

Drizzle(이슬비)라는 네이밍이 참으로 적절한것 같다.

처음 Drizzle에 대해서 조사할 때 "Cloud 환경 기반"이라는 것이 어떤 특징을 가져야 하는 가에 대해서 이해하지를 못했었다. 

Google신을 닥달해 본 결과 본인은 Cloud 환경이란 "한정된 하드웨어 리소스를 서로 공유해서 사용해야 하는 환경"으로 이해했다. 

하드웨어 리소스를 효과적으로 사용하기 위해 Drizzle은 MySQL을 대체하는 것이 목적이 아니라 MySQL을 최대한 다이어트 시키는 것을 선택했다.

그래서 MySQL과 개발 환경이 비슷하지만 완벽하게 호환이 되지는 않는다.

사실 Drizzle은 MySQL이 Oracle에 인수되기 훨씬 전에 이미 프로젝트가 시작되었기 때문에 앞서 소개된 두개의 DBMS가 MySQL처럼 MySQL의 대체제가 목적은 아니었다.

Drizzle은 초심을 잃어버린 MySQL에 반기를 들고, 초심으로 돌아가고자 튀어나온 DBMS로 개발도 개발자 커뮤니티를 중심으로 진행되고 있는 진정한 의미의 Open source Project라고 할 수 있다.

그럼 Drizzle은 어떤 군더더기들을 뺏을까?

• Drizzle에는 trigger나 stored procedures가 없는데, Drizzle의 개발자들은 이 두가지의 기능 때문에 MySQL이 필요 이상으로 비대해 졌다고 생각했고, 이 기능들의 필요성에 대해서는 다른 방식으로 풀 수 있을거라고 생각했다.
• Drizzle에서는 오직 utf-8만 지원한다. 
• MySQL의 100만 줄이 넘는 소스 코드를 1/3 미만으로 줄였다.
• 기본 storage engine으로 InnoDB를 채택했으며, MyISAM은 아에 빼버렸다.

Drizzle이 추구하는것이 무엇인지 느낌이 오는가?

그 외 replication을 굉장히 쉽게 구축할 수 있도록 수정하는 등, 관리 포인트를 최소화 함으로써 개발자나 관리자의 수고를 덜어주는데 집중했다.

전체적인 인상은 Cloud 환경이나, 간단한 웹프로그램을 위해 최소, 최적화된 경량 DBMS라는 느낌이 강하다.

Drizzle에 대해서는 조사만 하고 실제로 설치하고 돌려보지 않아서 뭐라 쓸만한 내용이 별로 없는데, 시간이 되는데로 테스트해보고 결과를 따로 포스팅 하도록 하겠다.

오늘은 "MySQL 클론의 역습" 두번째 글로 또다른 fork DBMS인 Percona Server에 대해서 적어볼까 한다.

2. Percona Server

Percona라는 회사는 MySQL에서 근무하던 엔지니어들을 주축으로 2006년도에 설립된 MySQL관련 컨설팅 전문 회사이다. 

주로 MySQL 테크니컬 서포팅을 해오다가 MySQL이 Oracle로 인수 되던 해(2010)에 그동안의 노하우를 바탕으로 MySQL fork 프로그램인 Percona Server를 내놓았다. 

Percona Server 역시 MariaDB처럼 MySQL의 완벽한 대체품을 가장 큰 목표로 삼고 개발 되었지만, 세부적인 컨셉은 MariaDB와는 약간 차이가 있다.

MariaDB가 MySQL의 완벽한 대체품 + 자신만의 다양한 기능 추가가 컨셉이라면, Percona Server는 MySQL의 성능 및 안정성, 편의성을 극대화 하는 것이 목표이다.

이런 컨셉이 이해가 되는 것이 Percona라는 회사 자체가 MySQL 테크니컬 서포트, 컨설팅이 주요 업무이 회사이다 보니, 이런 접근 방식이 그들에게는 그동안의 노하우를 자연스럽게 표출할 수 있는 방법이었지 않았을까 라는 생각이 든다.

하여튼 이러한 컨셉 때문인지 실제로 인터넷 상의 MySQL vs MariaDB vs Percona 성능 비교 테스트 결과를 보면 Percona의 성능이 가장 좋은 것으로 나타난다.

이제 Percona Server의 기술적인 특징들을 짚고 넘어가 보자.

Percona 사이트에 기술되어 있는 특징은 다음과 같다.

• Query가 보다 더 일관되고 빠르게 실행된다.
• 최신의 고사양 하드웨어를 보다 더 효율적으로 사용한다.
• 데이터를 샤딩해야 될 시점이 늦춰지거나, 아에 필요 없을 수도 있다.
• 호스팅이나 전력 비용을 절약할 수 있다.
• 관리나 성능 튜닝에 드는 시간을 절약할 수 있다.
• 높은 가동시간을 달성할 수 있다.
• 문제를 해결하는데 원인을 추측할 필요가 없다.

Query 성능 말고는 딱히 확인해 본바가 없어서 뭐라고 말할 수는 없지만, 하여튼 MySQL에 비해서 성능, 안정성, 관리의 편의성 등이 향상된것은 확실해 보인다.

실제 성능 테스트를 해본 결과로는 대체적으로 Query time이 MySQL보다 더 짧게, 그리고 일관되게 나오는 것을 확인 할 수 있었다. 다만 내가 테스트 했던 버전의 문제인지는 모르겠지만, Partitioning table에는 문제가 있어 보였는데, 이 부분은 추후 성능테스트 편에서 다시 자세히 이야기 하도록 하겠다.

위에 언급된 특징들중에 가장 큰 특징이자 장점이 하나 빠져 있는데, Percona는 XtraDB라는 InnoDB를 대체할 수 있는 Engine을 자체 개발해서 사용하고 있다.

XtraDB Engine은 InnoDB의 강화버전이라고 볼 수 있는데, 위에서 설명한 대부분의 특징이 XtraDB Engine에서 나온거라고 볼 수 있다.

XtraDB Engine은 현재 Percona에 기본 탑제되어 있고, MySQL에 추가할 수 있도록 Engine만 따로 제공하기도 한다.

그리고 MariaDB도 InnoDB를 대체할 목적으로 Percona가 개발한 XtraDB Engine을 기본 탑재하고 있다.

한편, Percona는 다년간의 MySQL 서포트, 컨설팅을 통해 축적된 노하우를 바탕으로 Percona Server 이외에 MySQL을 지원하는 다양한 소프트웨어들을 함께 개발하고 제공하고 있는데, 그 중 대표적인 소프트웨어인 Percona XtraBackup에 대해서 간단히 설명하도록 하겠다.

Percona XtraBackup은 실시간 백업을 지원하는 툴이다.

MySQL의 mysqldump는 백업시 해당 테이블이 Locking(MyISAM의 경우)되는데 비해 Percona XtraBackup은 테이블 Locking없이 백업(Hot backup)이 가능한 툴이다.

Percona의 문서를 보면, Parallel backups, Parallel compression,Streaming backups 등의 특징을 가지고 있으며, 무엇보다 Open Source이기 때문에 필요에 따라 수정도 가능하다.

Percona의 다양한 기능 및 추가 툴에 대한 내용은 여기에서 확인 할 수 있다.

사실 이 글의 제목을 처음에는 “MySQL의 형제들” 이었다.

source가 fork된것이니 형제보다는 부모 자식 관계가 더 맞지 않을까 생각되서, “MySQL의 자식들”이라고 제목을 바꾸었다가 어감이 좋지 않아서 MySQL의 창시자가 자신의 첫째딸 이름을 따서 MySQL이라고 작명한 것에 착안해 “MySQL의 딸들”이라고 바꾸었다.

그런데, 그만 코드가 복제되서 다시 분화된 것인데 이것을 부모 자식간이라고 해야 하나 형제간이라고 해야 하나 쓸데없는 고민에 빠져버렸다.

결국, 장고 끝에 제목은 “MySQL 클론의 역습”이라고 결정했다. (그런데 실제로 MySQL과 클론들끼리 정말 싸우지는 않는다. 심지어 그들 간은 사이가 좋아 보이기 까지 한다.)

헛소리는 여기까지 하고 본문으로 들어가 보자. ^^;

우리나라에서 DB라고 하면 Oracle 아니면, MySQL이다. 특히 웹서비스 환경은 MySQL이 현재까지도 대세라고 할 수 있다.

최근들어 NoSQL이니 BigData니 하는 새로운 페러다임과 프로그램들이 등장하면서 광풍의 조짐이 보이고는 있지만, 여전히 사용함에 있어서는 제한적이고 진입장벽이 만만치가 않다.

아직까지 DB의 메인스트림은 RDBMS이고, 새로운 웹 프로젝트가 진행되면, 당연하듯 DBMS로는 MySQL이 거론되곤 한다.

사실 좀 지루했었다.

뭔가 MySQL이 아닌 새로운 것을 만지고 싶었을 뿐이었다.

그래서 어떤 프로젝트에서 Postfix를 도입해 볼까 하다가 MySQL에 익숙한 엔지니어들과 개발자들의 반대에 부딛혀야 했고,  본인 스스로도 딱히 그 프로젝트에서 Postfix를 써야 할 당위성을 찾기도 힘들어서 포기한적이 있다.

최근 모바일 게임 관련 프로젝트를 진행하면서 MySQL에서 fork된 몇가지 DBMS들을 만져볼 수 있게 되었다. 이해 당사자도 적고, 약간 도전적인 프로젝트이다 보니 아무런 태클 없이 혼자서 자유롭게 DBMS를 선택할 수 있는 기회였다.

이 글은 그 때 research 했던 MySQL fork program 들에 대한 간단한 소개 글이다.

MySQL이 Oracle에 편입된 후, MySQL의 향후 운명에 대한 우려의 목소리가 많아졌다.

이러한 우려 속에서 MySQL의 대안을 찾으려는 움직임이 많아지고 있는데, 그것들 중 대표적인 것으로 MySQL에서 fork된 프로젝트들을 꼽고 싶다.

이 글에서는 MySQL fork 프로젝트들 중 가장 많이 알려진 세가지 프로젝트에 대해서 정리 하려고 한다.

1. MariaDB

MariaDB 의 주요 개발자는 Michael Monty Widenius라는 사람으로 MySQL을 개발했던 사람이고, 그 MySQL을 Sun에 10억 달러(약 1조원)에 매각하면서 핀란드 10대 부자중 한 명이 된 사람이기도 하다.

하지만 MySQL을 인수했던 Sun이 다시 Oracle로 인수되자, Monty Program AB이라는 회사를 설립하고 MySQL의 소스를 기반으로 MySQL과 완벽하게 호환이 되는 DBMS를 개발 하는데, 이것이 MariaDB이다.

MySQL, MariaDB 둘 다 Monty의 딸 이름을 따서 만들었는데 MySQL은 첫째 딸, MariaDB는 둘째딸의 이름에서 따론 것이라고 한다.(딸바보인가보다)

MariaDB는 MySQL의 소스를 가져다 만들기도 했지만, 목표자체가 MySQL을 완벽하게 대체하는 것이다 보니, 기존 MySQL과 완벽하게 호환이 된다.

프로그램의 룩앤필도 거의 똑같고 지원하는 함수들도 모두 일치하며 심지어 파일 이름들도 그대로 MySQL의 것을 가져다 쓰고 있다.

개발자들이 그냥 보기에는 이게 MariaDB인지 MySQL인지 모를 정도이다. (Client의 프롬프트가 “MariaDB” 로 뜨는 것 말고는 정말 똑같다.)

당연히 php-mysql 이라던지, jdbc-mysql-connector같은 기존 db connection library도 그대로 사용할 수 있기 때문에 실제로 개발자들은 MySQL에서 MariaDB로 DB 서버가 바뀐다고 해도 전혀 소스코드 수정이 필요없으며, 추가적인 DBMS에 대한 학습도 거의 필요가 없다.

즉, MySQL을 다룰줄 아는 개발자라면 MariaDB의 진입장벽은 거의 없는 수준이라고 할 수 있다.

하지만, MySQL을 완벽하게 대체한다는 사실만으로 기존에 MySQL을 잘 사용하던 사람들이 막연한 불안감이나 새로운 프로그램에 대한 단순한 호기심만으로 MariaDB로 갈아타지는 않을 것이다.

그럼 MySQL 대신 MariaDB를 썼을 때 얻을 수 있는 잇점들은 어떤 것이 있을까?

첫번째 장점은 월등히(?) 빠른 쿼리 타임을 들 수 있다.

인터넷이 돌아다니는 다양한 퍼포먼스 테스트 결과를 보면 전반적인 쿼리 성능이 MySQL에 비해 좋은 것을 알 수 있다.

특히, sub query나 join query 같은 경우 따로 MariaDB의 특징으로 소개할 만큼 성능 향상이 있다.

그리고 본인이 직접 테스트한 결과에서는 Partitioning table에 대한 select 쿼리 결과가 특히 눈길을 끌었는데, 자세한 테스트한 결과는 따로 추가 글을 작성할 예정이다.

두번째 장점은 다양한 추가 기능들이다.

이 글에서는 다양한 추가 기능들중 몇가지만 소개하고자 한다.

• Microseconds in MariaDB

테이블을 생성할 때 시간관련 자료형에 정밀도를 설정 할 수 있다.

정밀도는 0부터 6까지 설정할 수 있으며, 설정된 값만큼의 microseconds가 출력된다.

• Microseconds Precision Processlist

INFORMATION_SCHEMA.PROCESSLIST 테이블에 TIME_MS 컬럼이 추가 되었다.

processlist를 볼때 MySQL에서는 실행타임이 초단위까지 밖에 나오지 않았다면 MariaDB에서는 microseconds 단위까지 확인 할 수 있다.

• Table Elimination

여러개의 table 조인으로 구성된 쿼리의 경우, 사용하기 편하기 view table을 따로 구성하기도 하는데, view table에서 특정 컬럼을 select할 경우 실제로 조인된 table들중 쿼리에 필요 없는 테이블이 발생할 수 있다.

MariaDB는 이런 경우 자동으로 쿼리에 필요 없는 테이블을 조인쿼리에서 제거해주는 기능을 가지고 있다. (이 특징은 성능 향상쪽에 가까운것 같기도 하다.)

• Virtual Column

다음의 테이블 스키마를 보자.

table1의 c 컬럼은 가상컬럼이다. 실제로 storage에 저장되지 않고 query 실행시간에 계산되어 출력된다.

table1의 d 컬럼은 실제로 storage에 저장이 되는 가상컬럼으로, insert나 update 때 계산되어 저장 되는 컬럼이다.

더 많은 추가 기능들이 있는데, 추가기능에 대한 설명은 여기에서 확인 할 수 있다.

한가지 주의할 점은 MariaDB의 추가 기능들을 사용할 경우 혹시라도 부득이하게 MySQL로 돌아가야 될 경우 호환이 안될 수도 있다는 점을 유의해야 한다.

마지막으로 MariaDB는 다양한 Storage Engine을 지원한다.

• 1. Aria

  Aria 엔진은 MyISAM과 호환되면서 추가적으로 Transactional기능이 추가된 Engine이다.

• 2. XtraDB

  InnoDB의 대체 Engine으로 다음에 설명할 Percona사에서 개발한 Storage Engine이다.

• 3. PBXT

  일반적인 목적의 transactional storage engine으로 현재 더이상 maintaine 되지 않고 있어서 MariaDB에 기본 탑제되어 있지 않지만, 필요한 경우 재컴파일을 통해 사용할 수 있다.

• 4. FederatedX

  Federated Storage Engine의 fork engine으로 Federated engine은 원격 서버의 table에 접근해서 Insert, Update, Delete, Select 를 할 수 있도록 해주는 engine이다.

• 5. OQGRAPH

  Open Query Graph storage engine의 약자로 트리나 그래프 형태로 출력될 수 있도록 데이터를 저장하는 engine이다.

• 6. IBMDB2I

  MySQL 5.1.55에서 빠졌던 엔진인데, MariaDB에서는 아직까지 지원하고 있다.

• 7. SphinxSE

  Full Text Search Engine 으로 Full Text Search가 필요한 경우 사용할 수 있을 듯 하다.

• 8. Cassandra in MariaDB-10.0

  NoSQL DBMS인 Cassandra cluster에 MariaDB를 통해 접근 할 수 있도록 10.0 버전에 추가되었다.

3가지 측면에서 MariaDB의 장점에 대해서 설명했는데, 개인적으로는 첫번째 장점인 성능 향상 만으로도 MariaDB를 쓰는 이유는 충분한 것 같다.

본인 입장에서는 추가 기능의 필요성은 아직까지 피부로 와닿지 않았고, 추후 MySQL이나 Percona로 전환해야 될지도 모르는 이슈 때문에 전혀 고려대상이 되지는 못했다.

MariaDB에 대한 소개는 여기까지 하고 다음 글에서는 Percona Server에 대해 이야기 하도록 하겠다.