Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TokuDB試してみる

13,660 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?

×