Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to My sqlで2億件のシリアルデータと格闘した話
Similar to My sqlで2億件のシリアルデータと格闘した話 (20)
My sqlで2億件のシリアルデータと格闘した話
- 1. MySQLで2億件のシリアルデータと 格闘したチューニングの話 YAPC::Asia Tokyo 2015 Kenji Saito / @saiken3110
- 2. 自己紹介 ・斉藤 健二 Kenji Saito ・@saiken3110 ・Java PHP Perl ・Oracle MySQL
- 3. 今日の内容
- 9. ・Red Hat 5.6 ・Perl 5.20 ・MySQL 5.6 DBサーバのインフラ事情①
- 10. ・CPU 2コア ・メモリ ８G ・ディスク 450G ・/tmp 2G DBサーバのインフラ事情② → 2コア、8G。。。2億件。。。
- 12. □対象テーブル ・シリアルマスタ（２億件） ・商品シリアル紐付（１億件） □内容 ・インデックスを使った検索 ・プライマリーキーでの検索 ・フルスキャンでの検索 ・フルスキャンでのcount ・フルスキャンでのorder by ・insert ・alter table （カラム追加） 負荷テスト
- 13. いろいろと問題が・・・
- 14. ○count に84秒、CPUを80 ～ 95 %使用 → アプリケーションからは 実行しないため、対応不要とした ○order by や alter で/tmp が枯渇 → tmp_dir を物理ディスクに変更 → エラーがでなくなったが、 50Gくらい一時領域を使ってた。。 → 運用で回避することにした 負荷テスト 結果① ERROR 3 (HY000) at line 1: Error writing file '/tmp/MY3p25s8' (Errcode: 28 - No space left on device)
- 15. ○商品シリアル紐付のデータファイルが28Gに。。 → パフォーマンスのために、 各レコードで商品情報を持っていたのをやめた → 管理用のTBLを作り、 正規化、15G に縮小！ ○insertが意外と早い 「LOAD DATA」で3億件の登録が70分 → 後でいろいろ問題が発生。。 負荷テスト 結果②
- 20. □負荷テストのときより遅くなった原因 → 負荷テストのときはシリアルが連番 実際は、ランダムな数字 → insert 時にindex の再作成が発生！ □8000万件くらいから急激に遅くなった原因 → innodb_buffer_pool が枯渇 → 検証してみた 2億件登録したときの話④
- 22. innodb_buffer_pool とinsert② innodb_buffer_pool_size を1G、500M、250Mで 10万件のinsert × 100回にかかる時間を計測 250M で実行した場合、 340万件から遅延が発生 500M で実行した場合、 700万件から遅延が発生
- 23. innodb_buffer_pool とinsert③ データ量（登録件数）が増加し、 innodb_buffer_pool が枯渇すると、 insert が大幅に遅延し始める。 → メモリからあふれて、 ディスクI/Oが発生しているため。 → メモリを増やすことで、 データ量が多くても遅延が発生しない
- 26. 主キーとinsert② ○２億件の登録にかかった時間 ７５時間 → ３０時間に改善！ → 主キーが連番になったことで、 主キーのインデックス構築にかかる時間が減少 変更前は２億件の登録に 約75時間 変更後は２億件の登録が 約30時間で完了
- 30. updateではまった話③ □アプリケーションの動き ※１回のmaxが 100万件で１万件ごとにコミット １）シリアルマスタからステータスが 「未使用」のものを取得 ２）商品シリアル紐付へ、 入力した商品の情報をつけてシリアルをinsert ３）シリアルマスタのステータスを「使用済み」にupdate → １回のupdate で35秒かかっていた → 100万件の場合、35秒×100回！
- 31. updateではまった話④ □update が遅かった原因 → update 時にindex の再構築が発生 → シリアルがランダムなため、 紐付く主キーの読込みが重い。。 read_buffer_size （16k）ずつ 読み込まれる 紐付く主キーがバラバラなた め、読込が毎回発生
- 32. updateではまった話⑤ □対応 ステータス管理をやめ、 管理テーブルを作成し、 update 自体を不要にした → ６０分が４５秒に改善！ → インデックスの再構築怖い。。。
- 38. その他 Perlのチューニング① □コネクションプーリングっぽいこと コネクションオブジェクトを シングルトンにし、1worker 1コネクションを共有 → コネクション生成のコストをなくした
- 39. その他 Perlのチューニング② □マスタデータをキャッシュ PSGIサーバ起動時に、メモリにDBのマスタデータを保持 → worker 内でメモリは共有されるため、 DBアクセスが不要になる ※ただし、「Copy-On-Write」なので、 書き換えようとすると、メモリリークの原因になる ※ただし、マスタデータを変更する場合には、 再起動が必要になるので、 本当はmemcached とかを使った方がよさそう
- 42. ありがとうございました！