TokuDB試してみる

2014/07/11yoku0825

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 uncompressed0

10

20

30

40

50

60

70

80

90

GB

follower一覧(pkey)

1 4 16 32 640

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 640

5

10

15

20

25

30

35

Latency(ms)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

My comment一覧

1 4 16 32 640

20

40

60

80

100

120

140

160

180

200

Latency(ms)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

timeline一覧

1 4 16 32 640

500

1000

1500

2000

2500

3000

3500

Latency(ms)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

4クエリーをまとめたスループット

1 4 16 32 640

5

10

15

20

25

30

35

40

Throughput(tps)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

コメント投稿レイテンシー

1 4 16 32 640

50

100

150

200

250

300

350

400

450

Latency(ms)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

コメント投稿スループット

1 4 16 32 640

20

40

60

80

100

120

140

160

Throughput(tps)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

コメント削除レイテンシー

1 4 16 32 640

50

100

150

200

250

300

350

400

Latency(ms)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

コメント削除スループット

1 4 16 32 640

20

40

60

80

100

120

140

160

180

Throughput(tps)

InnoDB – Compact

TokuDB – zlib

InnoDB – Compressed

TokuDB – Uncompressed

ざっくり所感

● 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のやつだけど、何回かはそのままクラッシュした

● ばぐれぽはしていない

● どっか影響のないところから進めていくことになるかなぁ。

Any Questions?