TokuDB試してみる

TokuDB 試してみる
2014/07/11
yoku0825
MySQL Casual Talks vol.6

＼こんばんは／
● I'm yoku0825
● とある企業のＤＢＡ
●
オラクれない
● ポスグれない
● マイエスキューエる
●
家に帰ると
● 嫁の夫
●
せがれの父
● ポテトチップスはのりしお派

TokuDB とは
● Tokutek が作った Fractal Tree(R) Index を実
装したストレージエンジン
● MongoDB 向けに実装されたのが TokuMX
● TokuDB 公式バイナリーは MySQL 5.5.37, MariaDB
5.5.37( いずれも 64bit のみ )
●
MariaDB 公式バイナリーでは 5.5.33 以降と 10.0.5
以降
● Percona Server 公式バイナリーでは 5.6.19(7/2 に
GA になりました )

TokuDB
● http://docs.tokutek.com/tokudb/
● オンライン ALTER TABLE(ADD INDEX, ADD
COLUMN) に対応しているらしい
● 圧縮がイケているらしい
●
断片化しないらしい
● クラスターインデックスを複数作れるらしい
● Information_schema, SHOW ENGINE TokuDB
STATUS は慣れるまで大変そう
● FOREIGN KEY 制約はサポートしてない

Fractal Tree(R) Index
● http://tokutek.com/downloads/mysqluc-2010-
fractal-trees.pdf
● 14 ページ目あたりに Fractal Tree Index の構
造説明
● インデックス構造にあらかじめバッファがあるから
INSERT に強い、らしい。
● 28 ページ目あたりにベンチマーク
● 今は InnoDB の性能が上がってるので、交点はもう
ちょっと右にズレてると思う

正直この時点でだいぶやる気ない

テストケース
● user テーブル , follow テーブル , comment
テーブルを用意
● Twitter みたいなことがやりたかったんだよ
● それぞれのテーブルをクロスして、 timeline
テーブルを生成
●
抽出とソートだけここで済ませて、コメントの本文
は comment テーブルから当たる
● どう考えても timeline テーブルの件数がアレ
なので、 TokuDB を考えた
●
使ったのは percona-server-5.6.16-64.2-
tokudb-7.1.5

テストケース
● user
●
6 万
● comment
● 1 ユーザーあたり平均 1000 件 = 約 6000 万
● follow
●
1 ユーザーあたり平均 200 人 = 約 1200 万
● timeline
●
1 ユーザーあたり最大で直近 1 万件 = 約 6 億

テストケース
● ロジック
●
follower, followee, 自分のコメントの一覧 , 直
近 1 万件のタイムライン表示
– SELECT .. FROM follow WHERE user_id= ME
● コメントの投稿
– INSERT INTO comment VALUES ..
– INSERT INTO timeline SELECT .. FROM follow WHERE
follower_id= ME
●
コメントの削除
– DELETE FROM timeline ..
– DELETE FROM comment ..

テストケース
● ロジックつづき
●
フォロー
– INSERT INTO follow VALUES ..
– INSERT INTO timeline SELECT .. FROM comment WHERE
user_id= HIM;
● アンフォロー
– DELETE FROM timeline WHERE user_id= ME AND
comment_person= HIM;
– DELETE FROM follow WHERE user_id= ME AND
follower_id= HIM;

テストケース
● ロジックつづき
●
退会
– DELETE FROM timeline WHERE comment_person= ME
– DELETE FROM comment WHERE user_id= ME
– DELETE FROM follow WHERE follower_id= ME
– DELETE FROM user WHERE user_id= ME
● タイムラインの再生成
– DELETE FROM timeline WHERE user_id= ME
– INSERT INTO timeline SELECT .. FROM comment WHERE
user_id IN (MY_FOLLOWERS)

ベンチマークマシン
● CPU
●
Intel(R) Xeon(R) L5520 @ 2.27GHz
● 2P8C16T
●
Memory
● 48GB 、型番とかわからない
●
Storage
● RAID コントローラー + SSD2 本で RAID10
●
Fio でざっくり 100MB/s RW, 20000IOPS R,
2000IOPS W
● 鯖蔵同じスペックで 1 台ずつ

my.cnf はかなりテキトー
● innodb_buffer_pool_size= 30G
● innodb_flush_method= O_DIRECT
● innodb_log_file_size= 1G
● innodb_log_buffer_size= 64M
●
tokudb_directio= 1
● tokudb_cache_size= 30G
● tokudb_lock_timeout= 500000
● ミリ秒単位。デフォルトだと timeline テーブルの
構築時にタイムアウトしてたので。。
●
あとはソートバッファとか。

おことわり
● ベンチマークは飽くまで参考程度に。
●
自分でも納得いかない結果になってるとこもあるの
で。
●
特に InnoDB Compressed, TokuDB UNCOMPRESSED の
試行回数が十分取れてないのであんまりアテになり
ません。
●
あと、テストマシンのストレージ容量の関係で色々
ベンチが制約されてたりとか。
● せがれが熱を出してこの 1 週間くらいほとんど
何もできなかったんですよう。
●
いいわけ

ファイルサイズ
InnoDB Compact InnoDB Compressed TokuDB ZLIB TokuDB uncompressed
0
10
20
30
40
50
60
70
80
90
GB

follower 一覧 (pkey)
1 4 16 32 64
0
5
10
15
20
25
30
35
40
45
50
Latency(ms)
InnoDB – Compact
TokuDB – zlib
InnoDB – Compressed
TokuDB – Uncompressed

followee 一覧 (seckey)
1 4 16 32 64
0
5
10
15
20
25
30
35
Latency(ms)
InnoDB – Compact
TokuDB – zlib

My comment 一覧
1 4 16 32 64
0
20
40
60
80
100
120
140
160
180
200
Latency(ms)
InnoDB – Compact
TokuDB – zlib

timeline 一覧
1 4 16 32 64
0
500
1000
1500
2000
2500
3000
3500
Latency(ms)
InnoDB – Compact
TokuDB – zlib

4 クエリーをまとめたスループット
1 4 16 32 64
0
5
10
15
20
25
30
35
40
Throughput(tps)
InnoDB – Compact
TokuDB – zlib

コメント投稿レイテンシー
1 4 16 32 64
0
50
100
150
200
250
300
350
400
450
Latency(ms)
InnoDB – Compact
TokuDB – zlib

コメント投稿スループット
1 4 16 32 64
0
20
40
60
80
100
120
140
160
Throughput(tps)
InnoDB – Compact
TokuDB – zlib

コメント削除レイテンシー
1 4 16 32 64
0
50
100
150
200
250
300
350
400
Latency(ms)
InnoDB – Compact
TokuDB – zlib

コメント削除スループット
1 4 16 32 64
0
20
40
60
80
100
120
140
160
180
Throughput(tps)
InnoDB – Compact
TokuDB – zlib

ざっくり所感
● InnoDB は user を結構使える。スレッド数超え
ると wait が出始めてスループットが頭打ち。
● TokuDB はかなり CPU をぶん回す。 64 スレッド
だと sys だけで 50% くらい使うし csw が 150k と
か行く。
● InnoDB compressed と比べて 3 倍圧縮が効く。
多少レイテンシーは上がるけど、それを差っ引
いても容量が欲しい時は嬉しい。
● 正直ロック粒度がよくわからん。 InnoDB と同
じつもりでいくと結構 lock wait timeout 食ら
う。
● INSERT INTO .. SELECT でロックにはまること多々

ざっくり所感
● 公式 ML かなり過疎ってる
●
https://groups.google.com/forum/#!forum/tokudb
-user
● パーティショニングしてあってプルーニングが
効かないクエリーがめっさ遅かったと聞いてい
る
●
profiling 見た感じ、 1 つ 1 つのパーティションを
開くのがかなりオーバーヘッドみたい
● COUNT(DISTINCT ..) が遅いぽい
●
https://groups.google.com/forum/#!topic/tokudb
-user/hDnTItxkTTo
● covering index でも遅いってことは GROUP BY 苦手
なのかも。

ざっくり所感
● mysql コマンドラインクライアントからクエ
リーを叩くと、不気味な静寂に包まれることが
ある。
●
RC のやつだけど、何回かはそのままクラッシュし
た
● ばぐれぽはしていない
● どっか影響のないところから進めていくことに
なるかなぁ。

TokuDB試してみる

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to TokuDB試してみる (15)

More from yoku0825 (20)

TokuDB試してみる