NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
•
6 gefällt mir•13,155 views
MySQL Casual Talks Vol.7で発表したLTの資料ですm(_ _)m
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
Ähnlich wie NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴 (20)
Mehr von Akihiro Kuwano
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴
- 1. NVMFS 使ってみたとか 言っちゃって マジカジュアルな奴 ! 桑野 章弘
- 2. 自己紹介 •桑野 章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/ akuwano/
- 3. 自己紹介 •桑野 章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/ akuwano/
- 8. DB構成 •MySQL 5.5 •垂直分散メイン+レプリケーション分割
- 9. メイン系イベント系ヒストリ系アバター系 レプリの更新 テーブルを分散 Master Slave 通常の フルレプリ （昇格、バックアップ）
- 10. 現環境の問題点 •DB容量肥大化による容量問題 •マスタ更新過多によるスレーブ遅延解 消のためテーブル分散レプリ •運用負荷の増大（NEW！）
- 11. 解決策 •ハードウェアのスペックアップ •NVMFS+Page Compressionの検討
- 12. スペックアップ •当たり前だがお金を使えば解決 •メニーマニー •メニーマニー
- 13. だと話が終わるので
- 14. NVMFS検討 •先ほど説明がありましたが •データアクセスとデータ圧縮をiodrive 側のAtomicWriteとTrimを使って透 過的に行う •速度と容量圧縮の良いところ取り（！）
- 15. NVMFSの導入 •サービスへの一部サーバとして導入 •MySQL単体試験 •スレーブへの導入
- 16. 導入箇所 •Percona-Server 5.6 •マスタへのフルレプリとして導入
- 17. メイン系イベント系ヒストレプリの更新 テーブルを分散 Master Slave 通常の フルレプリ フルレプリで テスト導入 比較
- 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 ! !
- 21. RWは8割、ROだ と6～7割弱 LAは圧縮伸張で 高くなる
- 22. 書き込み回数で 徐々に断片化
- 23. サービス導入比較 •圧縮率 •書き込み時CPU負荷確認 •ioDriveへのWrite比較
- 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. 45%
- 27. 圧縮率 •1GB以上のテーブルを圧縮した結果 •圧縮したテーブルの容量比較 •217G •484G •45%
- 28. CPU負荷 •CPU負荷の比較
- 29. User 約2倍
- 30. CPUおかわり •よりCPUバウンドによる このとおり。 Userが頭打ちに
- 32. ioDriveへの書込
- 33. つかいかた •データ量は増えていく事が期待される テーブル •クエリは多すぎない方が好ましい •ヒストリログとかDWHとか •バックアップサーバとか
- 34. まとめ
- 35. まとめ
- 37. まとめ •CPUバウンドな処理な所には入れづら いっす •でも容量は欲しいけどアクセスが頻繁 じゃないものには有用です •試験しつつ模索中 •引き続き検証していきます