TokuDB試してみる

12,300 views

Published on

2014/07/11 MySQL Casual Talks vol.6

Published in: Technology

TokuDB試してみる

  1. 1. TokuDB 試してみる 2014/07/11 yoku0825 MySQL Casual Talks vol.6
  2. 2. \こんばんは/ ● I'm yoku0825 ● とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● ポテトチップスはのりしお派
  3. 3. 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 になりました )
  4. 4. TokuDB ● http://docs.tokutek.com/tokudb/ ● オンライン ALTER TABLE(ADD INDEX, ADD COLUMN) に対応しているらしい ● 圧縮がイケているらしい ● 断片化しないらしい ● クラスターインデックスを複数作れるらしい ● Information_schema, SHOW ENGINE TokuDB STATUS は慣れるまで大変そう ● FOREIGN KEY 制約はサポートしてない
  5. 5. Fractal Tree(R) Index ● http://tokutek.com/downloads/mysqluc-2010- fractal-trees.pdf ● 14 ページ目あたりに Fractal Tree Index の構 造説明 ● インデックス構造にあらかじめバッファがあるから INSERT に強い、らしい。 ● 28 ページ目あたりにベンチマーク ● 今は InnoDB の性能が上がってるので、交点はもう ちょっと右にズレてると思う
  6. 6. 正直この時点でだいぶやる気ない
  7. 7. テストケース ● user テーブル , follow テーブル , comment テーブルを用意 ● Twitter みたいなことがやりたかったんだよ ● それぞれのテーブルをクロスして、 timeline テーブルを生成 ● 抽出とソートだけここで済ませて、コメントの本文 は comment テーブルから当たる ● どう考えても timeline テーブルの件数がアレ なので、 TokuDB を考えた ● 使ったのは percona-server-5.6.16-64.2- tokudb-7.1.5
  8. 8. テストケース
  9. 9. テストケース ● user ● 6 万 ● comment ● 1 ユーザーあたり平均 1000 件 = 約 6000 万 ● follow ● 1 ユーザーあたり平均 200 人 = 約 1200 万 ● timeline ● 1 ユーザーあたり最大で直近 1 万件 = 約 6 億
  10. 10. テストケース ● ロジック ● 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 ..
  11. 11. テストケース ● ロジックつづき ● フォロー – 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;
  12. 12. テストケース ● ロジックつづき ● 退会 – 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)
  13. 13. ベンチマークマシン ● CPU ● Intel(R) Xeon(R) L5520 @ 2.27GHz ● 2P8C16T ● Memory ● 48GB 、型番とかわからない ● Storage ● RAID コントローラー + SSD2 本で RAID10 ● Fio でざっくり 100MB/s RW, 20000IOPS R, 2000IOPS W ● 鯖蔵同じスペックで 1 台ずつ
  14. 14. 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 テーブルの 構築時にタイムアウトしてたので。。 ● あとはソートバッファとか。
  15. 15. おことわり ● ベンチマークは飽くまで参考程度に。 ● 自分でも納得いかない結果になってるとこもあるの で。 ● 特に InnoDB Compressed, TokuDB UNCOMPRESSED の 試行回数が十分取れてないのであんまりアテになり ません。 ● あと、テストマシンのストレージ容量の関係で色々 ベンチが制約されてたりとか。 ● せがれが熱を出してこの 1 週間くらいほとんど 何もできなかったんですよう。 ● いいわけ
  16. 16. ファイルサイズ InnoDB Compact InnoDB Compressed TokuDB ZLIB TokuDB uncompressed 0 10 20 30 40 50 60 70 80 90 GB
  17. 17. 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
  18. 18. followee 一覧 (seckey) 1 4 16 32 64 0 5 10 15 20 25 30 35 Latency(ms) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  19. 19. My comment 一覧 1 4 16 32 64 0 20 40 60 80 100 120 140 160 180 200 Latency(ms) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  20. 20. timeline 一覧 1 4 16 32 64 0 500 1000 1500 2000 2500 3000 3500 Latency(ms) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  21. 21. 4 クエリーをまとめたスループット 1 4 16 32 64 0 5 10 15 20 25 30 35 40 Throughput(tps) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  22. 22. コメント投稿レイテンシー 1 4 16 32 64 0 50 100 150 200 250 300 350 400 450 Latency(ms) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  23. 23. コメント投稿スループット 1 4 16 32 64 0 20 40 60 80 100 120 140 160 Throughput(tps) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  24. 24. コメント削除レイテンシー 1 4 16 32 64 0 50 100 150 200 250 300 350 400 Latency(ms) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  25. 25. コメント削除スループット 1 4 16 32 64 0 20 40 60 80 100 120 140 160 180 Throughput(tps) InnoDB – Compact TokuDB – zlib InnoDB – Compressed TokuDB – Uncompressed
  26. 26. ざっくり所感 ● InnoDB は user を結構使える。スレッド数超え ると wait が出始めてスループットが頭打ち。 ● TokuDB はかなり CPU をぶん回す。 64 スレッド だと sys だけで 50% くらい使うし csw が 150k と か行く。 ● InnoDB compressed と比べて 3 倍圧縮が効く。 多少レイテンシーは上がるけど、それを差っ引 いても容量が欲しい時は嬉しい。 ● 正直ロック粒度がよくわからん。 InnoDB と同 じつもりでいくと結構 lock wait timeout 食ら う。 ● INSERT INTO .. SELECT でロックにはまること多々
  27. 27. ざっくり所感 ● 公式 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 苦手 なのかも。
  28. 28. ざっくり所感 ● mysql コマンドラインクライアントからクエ リーを叩くと、不気味な静寂に包まれることが ある。 ● RC のやつだけど、何回かはそのままクラッシュし た ● ばぐれぽはしていない ● どっか影響のないところから進めていくことに なるかなぁ。
  29. 29. Any Questions?

×