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.

NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴

12,416 views

Published on

MySQL Casual Talks Vol.7で発表したLTの資料ですm(_ _)m

Published in: Technology

NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴

  1. 1. NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴 ! 桑野 章弘
  2. 2. 自己紹介 •桑野 章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/ akuwano/
  3. 3. 自己紹介 •桑野 章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/ akuwano/
  4. 4. みんなカジュアルとか わかってるんですか
  5. 5. 本当にカジュアルな 奴です
  6. 6. MongoDBの方から 来ました
  7. 7. 今日の話 NVMFS試してみた
  8. 8. DB構成 •MySQL 5.5 •垂直分散メイン+レプリケーション分割
  9. 9. メイン系イベント系ヒストリ系アバター系 レプリの更新 テーブルを分散 Master Slave 通常の フルレプリ (昇格、バックアップ)
  10. 10. 現環境の問題点 •DB容量肥大化による容量問題 •マスタ更新過多によるスレーブ遅延解 消のためテーブル分散レプリ •運用負荷の増大(NEW!)
  11. 11. 解決策 •ハードウェアのスペックアップ •NVMFS+Page Compressionの検討
  12. 12. スペックアップ •当たり前だがお金を使えば解決 •メニーマニー •メニーマニー
  13. 13. だと話が終わるので
  14. 14. NVMFS検討 •先ほど説明がありましたが •データアクセスとデータ圧縮をiodrive 側のAtomicWriteとTrimを使って透 過的に行う •速度と容量圧縮の良いところ取り(!)
  15. 15. NVMFSの導入 •サービスへの一部サーバとして導入 •MySQL単体試験 •スレーブへの導入
  16. 16. 導入箇所 •Percona-Server 5.6 •マスタへのフルレプリとして導入
  17. 17. メイン系イベント系ヒストレプリの更新 テーブルを分散 Master Slave 通常の フルレプリ フルレプリで テスト導入 比較
  18. 18. mysql> show create table t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=50000001 DEFAULT CHARSET=utf8 ROW_FORMAT=PAGE_COMPRESSION ! !
  19. 19. 結果比較/考察 •単純性能比較 •サービス導入検討比較
  20. 20. 単純比較 •トランザクション数比較 •トランザクション数による圧縮率の低 下確認
  21. 21. RWは8割、ROだ と6~7割弱 LAは圧縮伸張で 高くなる
  22. 22. 書き込み回数で 徐々に断片化
  23. 23. サービス導入比較 •圧縮率 •書き込み時CPU負荷確認 •ioDriveへのWrite比較
  24. 24. 圧縮率 •カッとなってサービスで使ってる実デー タ圧縮した
  25. 25. [root@sx300-dbm101 sbtest]# ls -lh * | grep ibd -rw-rw---- 1 root root 12G 12月 12 18:00 2014 t1.ibd ! ! [root@sx300-dbm101 sbtest]# du -sh * | grep ibd 1.5G t1.ibd !
  26. 26. 45%
  27. 27. 圧縮率 •1GB以上のテーブルを圧縮した結果 •圧縮したテーブルの容量比較 •217G •484G •45%
  28. 28. CPU負荷 •CPU負荷の比較
  29. 29. User 約2倍
  30. 30. CPUおかわり •よりCPUバウンドによる このとおり。 Userが頭打ちに
  31. 31. CPU負荷 •でもただでさえCPUバウンドなのに、 よりCPUバウンドに寄っちゃう
  32. 32. ioDriveへの書込
  33. 33. つかいかた •データ量は増えていく事が期待される テーブル •クエリは多すぎない方が好ましい •ヒストリログとかDWHとか •バックアップサーバとか
  34. 34. まとめ
  35. 35. まとめ
  36. 36. うそですすいません((((;゚Д゚))))
  37. 37. まとめ •CPUバウンドな処理な所には入れづら いっす •でも容量は欲しいけどアクセスが頻繁 じゃないものには有用です •試験しつつ模索中 •引き続き検証していきます

×