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試してみる

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to TokuDB試してみる

Similar to TokuDB試してみる (20)

More from yoku0825

More from yoku0825 (20)

TokuDB試してみる