TokuDB試してみる
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

TokuDB試してみる

  • 7,109 views
Uploaded on

2014/07/11 MySQL Casual Talks vol.6

2014/07/11 MySQL Casual Talks vol.6

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,109
On Slideshare
2,439
From Embeds
4,670
Number of Embeds
17

Actions

Shares
Downloads
9
Comments
0
Likes
2

Embeds 4,670

http://d.hatena.ne.jp 2,811
http://blog.mogmet.com 1,225
http://yoku0825.blogspot.jp 449
https://twitter.com 100
http://cheliped29.rssing.com 37
https://willgate.atlassian.net 11
http://yoku0825.blogspot.com 9
http://feedly.com 9
http://yoku0825.blogspot.kr 5
http://getpocket.com 4
https://www.blogger.com 2
http://go.idwebspace.com 2
http://www.google.co.jp 2
http://yoku0825.blogspot.de 1
https://tweetdeck.twitter.com 1
http://plus.url.google.com 1
http://www.slideee.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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