TokuDB Fast Upserts and Update

Upsert(INSERT INTO .. ON DUPLICATE KEY UPDATE...)나 UPDATE문은 UPDATE에 영향을 받는 로우가 얼마나 되는지를 판단해야 하기 때문에 느리고, 시스템의 read I/O 성능에 의해 영향을 많이 받는다. MySQL에서 update문은 read-modify-write 알고리즘에 의해 수행되어 스토리지 엔진에서 로우를 읽고, 갱신한 후 스토리지 엔진에 갱신된 로우를 쓴다.

TokuDB의 update 알고리즘은 이와 다르다.  Update 문이 실행되면 먼저, Fractal Tree Message라는 작은 공간에 update 표현식을 암호화한 형태로 저장한다. update message는 Fractal Tree의 root level에 전달되고, background에서 Fractal Tree Buffer flush down 이벤트에 의해 message down을 수행한다. 결국 Fractal Tree의 leaf node까지 전달되고 update program이 해당 로우를 쓰게 된다.

아래와 같은 테이블이 있다고 가정하자.

CREATE TABLE t ( id BIGINT UNSIGNED NOT NULL PRIMARY KEY, count BIGINT UNSIGNED NOT NULL );

우리는 이 테이블의 id 컬럼에 어떤 값이 저장되어 있는지 알 수 없으므로 아래와 같은 Upsert문을 실행한다. 즉 해당 :id에 바인드된 id가 있으면 update를 없으면 insert를 수행한다.

INSERT NOAR INTO t values (:id, 1) ON DUPLICATE KEY UPDATE count=count+1;

여기서 INSERT INTO 사이의 "NOAR"(TokuDB에서는 NOAR modifier라고 말하고 있다.) 예약어를 주목하자. NOAR modifier는 TokuDB로 하여금 PK 존재 여부를 Fractal Tree Index 안으로 "upsert" message를 삽입하는 형태로 체크할 것으로 대체하도록 명령한다. "upsert" message는 row의 복사본과 업데이트할 count 컬럼의 값을 들고 있다. 그리고 앞에서 언급한 것처럼 Fractal Tree의 노드의 Buffer가 채워지게 되면, 이 "upsert" message를 하위 트리의 노드에 flush하고, message가 leaf node에 도달하면 update를 실행하여 count컬럼의 값을 갱신하거나 새로운 로우를 leaf node에 삽입한다. 따라서, "upsert" message가 어떤 레벨에 있든지 관계없이 같은 PK값을 가지는 메시지는 상위 노드에 있는 메시지가 최신이기 때문에, PK의 존재 여부를 마지막 leaf level까지 내려가서 찾을 필요가 없이 가장 먼저 찾아진 message에서 그 로우를 취득하면 된다.

단, Fast Upsert 및 Update의 제약 사항은 아래와 같다. 

• 테이블에 반드시 PK가 정의되어 있어야 한다.
• 테이블에 보조키가 있어서는 안된다.
• 테이블에 트리거가 있어서는 안된다.
• binlog_format은 STATEMENT 이어야 한다.
• Update할 컬럼의 데이터 타입은 int, char, varchar 타입이여만 한다.
• 쿼리가 실행되는 세션의 SQL_MODE는 STRICT_ALL_TABLES 또는 STRICT_TRNAS_TABLE가 아니어야 한다.

아래의 링크를 Tokutek 내부의 벤치마크 결과이다.
http://www.tokutek.com/2013/03/tokudb-fast-update-benchmark/

아래는 sysbench 0.5에서 InnoDB, TokuDB normal update, TokuDB fast update(NOAR)를 수행했을 때의 벤치마크 결과이다. 혹시나해서 테이블에 보조키를 생성하여 돌려보았으나 fast update가 동작하지 않아서 해당 결과는 제외시켰다.

위와 같은 제한된 환경이 얼마나 있을지 모르겠지만 혹시 존재한다면 Fast Upsert 기능은 상당히 강력한 기능이 될 수도 있겠다.