TokuDB Introduction

TokuDB는 높은 확장성과 zero-maintenance downtime 을 지향하는 MySQL Storage engine으로, 인덱스 기반의 쿼리 속도 향상, 복제 성능 향상, 병렬화되지 않은 압축 및 온라인 스키마 변경이 가능하다.

TokuDB는 drop-in stroage engine의 MySQL로 개발한 애플리케이션을 그대로 사용할 수 있으며,  ACID와 MVCC를 완벽하게 지원한다.

TokuDB는 2013년 초 Open source로 개방하였고, 2014년 1월 현재 TokuDB 7.1.0 Community for MySQL 5.5.30, TokuDB 7.1.0 for Community Edition MariaDB 5.5.30 버전을 제공하고 있다.

한편 Tokutek에서 MongoDB with Fractal Tree Indexes v0.0.2도 발표하여 Fractal Tree Index를 활용할 수 있는 영역을 넓히고 있어 주목된다.

그러나, 아직은 QPS가 높은 OLTP상에서는 여러 안정성에서 문제가 발생하고 있기 때문에, 데이터 size가 크고 QPS가 높지  않은 성격의 DB (Log DB, 분석 DB 등등)라면 권장 해 볼만 하며, 실제로 카카오에서는 이러면 성격의 DB에 도입하여 활용 중에 있다.

Toku DB 사용의 appeal point는 다음과 같다.

장점 : 

• index scan의 경우 innodb 대비 read속도가 상당히 빠르다.
• insert speed InnoDB 대비 10x (read가 많지 않은 경우)
• 압축 size InnoDB 대비 : 1/10~1/20

단점 : 

• full scan의 경우는 압축을 풀어야 하므로, InnoDB대비 3x이상 느리다.
• 압축을 사용할 경우 innoDB보다 user CPU사용율이 약간 높다.
• XtraBackup 등의 innoDB open source backup tool을 사용할 수 없다.

Fast insertions and deletions

• TokuDB에서는 Fractal Tree기술로 빠른 인덱싱이 가능하다. B-tree의 경우 느린 인덱싱으로 인해 암묵적으로 인덱스 개수를 제한하고 있다는 점에서 주목할만하다. 인덱싱이 빠르다는 것은 인덱스를 많이 만들 수 있다는 것을 의미하고 그만큼 쿼리에서 활용할 수 있는 인덱스의 수가 늘어난다는 것을 의미한다. Fractal Tree는 B-tree의 인덱스 최적 포인트인(indexing sweet spot)인 sequential data에 대비해서, 높은 카디널리티를 가진 랜덤 데이터에서도 2배 이상 빠르다.

• fast indexing means fast queries. -Tokuteck-

Hot index creation

• TokuDB에서는 온라인으로 인덱스를 생성할 수 있다. MySQL 5.5 이하 및 MariaDB 5.5 이하에서 지원하지 않음

• tokudb_create_index_online 세션 변수가 ON (Default) 일 경우 온라인으로 인덱스 생성을 할 수 있다.

• 온라인 인덱스 생성은 CREATE INDEX 구문으로만 가능하다. ALTER TABLE 구문으로 인덱스를 생성하면 tokudb create index online 세션 변수가 on 으로 설정되어 있다 하더라도 인덱스는 오프라인(해당 테이블은 오퍼레이션이 불가, Locking)으로 생성된다.

• 인덱스 생성 진행 상황은 다른 클라이언트에서 SHOW PROCESSLIST 명령어에서 확인할 수 있다. (CTAS, LOAD, INSERT...SELECT 등 포함)

show processlist; +...+---------+------+------------------------------------+----------------------------------------------------+----------+ |...| Command | Time | State                              | Info                                               | Progress | +...+---------+------+------------------------------------+----------------------------------------------------+----------+ |...| Query   | 1312 | Adding of indexes about 79.5% done | CREATE INDEX ix1_toku_default ON toku_default (c2) | 79.000   | |...| Sleep   | 30   |                                    | NULL                                               | 0.000    | |...| Query   | 0    | NULL                               | show processlist                                   | 0.000    | +...+---------+------+------------------------------------+----------------------------------------------------+----------+

Hot column addition, expansion and rename(HCADER)

• TokuDB에서는 일부 데이터 타입에 대해 Locking 없이 온라인으로 컬럼 추가, 확인 및 이름 변경을 할 수 있다. MySQL 5.5 이하 및 MariaDB 5.5 이하에서 지원하지 않음

• 지원 가능한 데이터 타입은 CHAR, VARCHAR, VARBINARY, INTEGER 이다. TIME, ENUM, BLOB, TINYBLOB, MEDIUMBLOB, LONGBLOB 타입은 지원하지 않는다.

• HCADER를 실행하면 meta 정보를 갱신하기 위해 아주 짧은 시간 동안 테이블 락을 잡고, 락이 풀린 후에는 row가 디스크에서 메모리로 올라올 때 각 row를 수정한다 - 이를 후행 작업이라고 정의하자 -. HCADER은 PK 및 secondary index를 포함한 Fractal Tree의 일부를 건드리는 후행 작업으로 수행된다. 추가된 컬럼, 삭제된 컬럼 및 확장된 컬럼의 각각의 후행 작업을 OPTIMIZE TABLE 구문으로 수동으로 한 번에 실행할 수 있다. OPTIMIZE TABLE 구문은 온라인으로 실행이 가능하다. 즉, OPTIMIZE TABLE 명령어가 실행되는 동안 아무런 블럭킹 없이 쿼리를 실행할 수 있다. 이는 TokuDB v7.0.1 에서 중요한 부분으로 소개되고 있다. 또한 온라인으로 OPTIMIZE TABLE을 수행하더라도 TokuDB 인덱스가 age되지 않은 한 인덱스를 리빌드하지 않는다. 즉, HCADER의 모든 플러시 작업은 백그라운드로 실행된다.

• 온라인 컬럼 추가, 컬럼 삭제, 컬럼 확장 작업은 각각의 SQL 문장으로 실행해야 한다.

• 인덱스를 추가 또는 삭제하는 동안에는 HCADER을 하지 않도록 한다.

• HCADER을 수행하는 동안에 발생하는 테이블 락 시간은 dirty page flush time에 의해 결정된다. 만일 체크포인트가 최근에 발생했다면 이 작업은 길어야 수 초 이내에 끝나고 테이블에 dirty page가 많으면 flush로 인해 수 분이 걸릴 수도 있다.

• 인덱스의 일부로 사용되고 있는 컬럼의 삭제는 피하는 것이 좋다. 인덱스 컬럼을 삭제 작업은 느리다.  인덱스 컬럼을 삭제하고자 한다면 먼저 해당 인덱스를 삭제한 후 컬럼을 삭제하도록 한다.

• PK나 Secondary Key의 일부로 사용되는 컬럼에 대해서는 HCADER을 지원하지 않는다.

• 문법은 아래와 같다.

ALTER TABLE <table-name> CHANGE <old-column-name> <new-column-name> <data-type> <required-ness> <default>

• 임시 테이블의 경우 HCADER을 이용하는 것보다는 일반적인 방법으로 작업하는 것이 더 빠르다.

Compression

• TokuDB는 3가지 레벨(tokudb_default, tokudb_fast, tokudb_small)의 압축을 제공한다.

• 당연한 이야기이지만 압축과 CPU 사용율은 상반 관계를 가진다. 즉, 기본 레벨 (tokudb_default)을 사용하면 CPU 사용율은 낮아지지만, tokudb_small 압축 레벨을 사용하면 CPU 사용율은 높아진다.

• TokuDB에서의 압축은 백그라운드 스레드로 동작하기 때문에 고레벨 압축을 사용하더라도 데이터베이스는 성능은 나빠지지 않는다. TokuTek왈, 오히려 압축율이 높은 데이터베이스가 좋을 성능을 보이는 것을  보았다.

• 6 Core 이하에서는 tokudb_default, 그 이상에서는 tokudb_small를 권장한다.

• 압축은 테이블 단위(row_format option)로 지정한다. 압축 옵션을 지정하지 않으면 기본 값으로 지정된다.

• 압축 레벨은 crate table 또는 alter table 문장으로 변경할 수 있다. 바뀐 압축 옵션은 새롭게 유입된 데이터에 대해서만 유효하다. OPTIMIZE TABLE 구문을 실행하면 테이블의 모든 데이터 및 인덱스를 재작성할 수 있다.

CREATE TABLE <table_name> (c1 INT NOT NULL PRIMARY KEY, c2 INT NOT NULL) ENGINE=TOKUDB ROW_FORMAT=<row_format>; ALTER TABLE <table_name> row_format=<row-format>;

• 또한 세션 변수로 tokudb_row_format을 사용해도 된다.

SET tokudb_row_format = <row_format>;

• row_format
  • tokudb_default : 기본값으로 TokuDB 7.0.1에서는 (=tokudb_fast)로 동작한다. 앞으로 이 값은 바뀔 예정이다.
  • tokudb_fast : quicklz 라이브러리를 사용하여 기본 압축을 한다.
  • tokudb_small : lzma 라이브러리를 사용하여 고압축을 한다.

• 참고

Elimiates slave lag

• MySQL의 복제는 단일 스레드로 디자인되어 있기 때문에 slave log가 종종 발생한다. 하지만 TokuDB에서는 high insertion rates로 인해 slave lag가 거의 발생하지 않는다. 

• 참고

No Aging/Fragmentation

• TokuDB Fractal Tree Index에서는 단편화가 절대 발생하지 않기 때문에 Reorg가 필요하지 않다.

Clustering keys and other indexing improvements

• TokuDB 테이블들은 PK로 clustered된다.

• secondary key도 clustering key로 생성할 수 있다. 하지만 clustering key의 leaf level에는 모든 컬럼이 포함되므로 문자열 데이터의 경우 데이터 사이즈의 최소 2배 이상의 공간이 필요하다 (단, 압축율에 따라 달라짐) . 

• 따라서 clustering key를 이용하여 범위 검색을 할 경우 clustering factor가 높은 검색을 할 수 있어 쿼리 성능을 상당히 향상시킬 수 있다.

• auto-increment 컬럼을 모든 인덱스의 모든 포지션에서도 사용할 수 있다.

• 최대 32 컬럼까지 지원한다.

Bulk loader

• 오프라인 테이블 및 인덱스 생성 작업은 parallel loader로 작업하기 때문에 multiple core에서 빠르게 작업할 수 있다.

Fast recovery

• TokuDB 에서의 recovery는 100% 자동으로 실행된다. 
• 빠른 복구를 지원한다. (일반적으로 1분이내)

참고

TokuDB vs. InnoDB

TokuTeck: TokuDB Benchmarks