my sqlで2億件のシリアルデータと格闘した話

MySQL で 2 億件のシリアルデータと格闘したチューニングの話

YAPC::Asia Tokyo 2015Kenji Saito / @saiken3110

自己紹介

・斉藤　健二　 Kenji 　 Saito・ @saiken3110・ Java 　 PHP 　 Perl・ Oracle 　 MySQL

今日の内容

MySQL で2 億件のシリアルデータを

つかった話

主にチューニングの話です。Perl も最後にちょっとでてきます。。

Topic・システムの概要・負荷テストした話・ 2 億件登録したときの話・ update ではまった話・今後の課題 ・まとめ

システムの概要（フロント）

商品購入

シリアル入力

入力

・商品 A・サイズ

商品サイズ選択

登録

XXL　　　　　▼

商品シリアル紐付 利用履歴

システムの概要（バックエンド）

シリアルマスタ

商品名

シリアル数

商品・シリアル紐付け

紐付け

▼

商品シリアル紐付

2 億件！！ １億件！！

・ Red Hat 5.6・ Perl 5.20・ MySQL 5.6

DB サーバのインフラ事情①

・ CPU 　 2 コア・メモリ　８ G・ディスク　 450G・ /tmp 　 2G

DB サーバのインフラ事情②

　→　 2 コア、 8G 。。。 2 億件。。。

Topic・システムの概要

・負荷テストした話・ 2 億件登録したときの話・ update ではまった話・今後の課題 ・まとめ

□ 対象テーブル　・シリアルマスタ（２億件）　・商品シリアル紐付（１億件）

□ 内容　・インデックスを使った検索　・プライマリーキーでの検索　・フルスキャンでの検索　・フルスキャンでの count　・フルスキャンでの order by　・ insert　・ alter table （カラム追加）

負荷テスト

いろいろと問題が・・・

○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)

○ 商品シリアル紐付のデータファイルが 28G に。。　　→　パフォーマンスのために、　　　　各レコードで商品情報を持っていたのをやめた　　　　　→　管理用の TBL を作り、　　　　　　　正規化、 15G に縮小！

○insert が意外と早い　　「 LOAD DATA 」で 3 億件の登録が 70 分　　　→　後でいろいろ問題が発生。。

負荷テスト　結果②

Topic・システムの概要・負荷テストした話

・ 2 億件登録したときの話・ update ではまった話・今後の課題 ・まとめ

2 億件登録したときの話①

シリアルマスタ

商品名

シリアル数

商品・シリアル紐付け

紐付け

▼

商品シリアル紐付

2 億件！！ １億件！！

ココ

負荷テストのときに、３億件が 70 分で登録できた

実際のデータで２億件登録しようとしたら、、　　　　　　　

７５時間かかった。。

2 億件登録したときの話②

□ 実行時間の推移

2 億件登録したときの話③

※500 万件ずつ「 LODA DATA 」で登録

8000万件から急激に遅延

□ 負荷テストのときより遅くなった原因　→　負荷テストのときはシリアルが連番　　　実際は、ランダムな数字　　　→　 insert 時に index の再作成が発生！

□8000 万件くらいから急激に遅くなった原因　→　 innodb_buffer_pool が枯渇　　　→　検証してみた

2 億件登録したときの話④

innodb_buffer_pool と insert①

さすがに 75 時間を何度もは無理なので、

innodb_buffer_pool_size を 10 分の１くらいで

試してみた

40 時間くらいかけて。。

innodb_buffer_pool と insert②

innodb_buffer_pool_size を 1G 、 500M 、 250M で10 万件の insert × 100 回にかかる時間を計測

250M で実行した場合、340万件から遅延が発生

500M で実行した場合、700万件から遅延が発生

innodb_buffer_pool と insert③

データ量（登録件数）が増加し、innodb_buffer_pool が枯渇すると、insert が大幅に遅延し始める。

　→　メモリからあふれて、　　　ディスク I/O が発生しているため。

　　　→　メモリを増やすことで、　　　　　データ量が多くても遅延が発生しない

ついでに、、

主キーがシーケンスならインデックスの再構築が

早いんじゃないかと思った

試してみた

再びの 40 時間。。

主キーと insert①

主キーをシリアル（ランダムな数字）からシーケンスに変更して、 2 億件の登録にかかる時間を比較

○ 変更前　・主キー：シリアル　・ユニークキー：シーケンス

○ 変更後　・主キー：シーケンス　・ユニークキー：シリアル

主キーと insert②

○ ２億件の登録にかかった時間　　　７５時間　→　３０時間に改善！　　　→　主キーが連番になったことで、　　　　　主キーのインデックス構築にかかる時間が減少

変更前は２億件の登録に約 75時間

変更後は２億件の登録が約 30時間で完了

Topic・システムの概要・負荷テストした話・ 2 億件登録したときの話

・ update ではまった話・今後の課題 ・その他　 Perl のチューニング・まとめ

update ではまった話①

シリアルマスタ

商品名

シリアル数

商品・シリアル紐付け

紐付け

▼

商品シリアル紐付

2 億件！！ １億件！！

ココ

負荷テストのときは、100 万件の紐付が７４秒だった

お客さんの前でデモしたら、、　　　　　　　

１時間かかった

update ではまった話②

update ではまった話③

□ アプリケーションの動き　※１回の max が 100 万件で１万件ごとにコミット

　１）シリアルマスタからステータスが　　　「未使用」のものを取得

　２）商品シリアル紐付へ、　　　入力した商品の情報をつけてシリアルを insert

　３）シリアルマスタのステータスを「使用済み」に update　　　→　１回の update で 35 秒かかっていた　　　　　→　 100 万件の場合、 35 秒 ×100 回！　

update ではまった話④

□update が遅かった原因　→　 update 時に index の再構築が発生　　　　→　シリアルがランダムなため、　　　　　　紐付く主キーの読込みが重い。。

read_buffer_size （ 16k）ずつ読み込まれる紐付く主キーがバラバラなため、読込が毎回発生

update ではまった話⑤

□ 対応　ステータス管理をやめ、　管理テーブルを作成し、　 update 自体を不要にした

　→　６０分が４５秒に改善！　　　　→　インデックスの再構築怖い。。。

そんなこんなで、なんとか無事リリースできました

よかった

Topic・システムの概要・負荷テストした話・ 2 億件登録したときの話・ update ではまった話

・今後の課題 ・その他　 Perl のチューニング・まとめ

今後の課題①

□ 増分バックアップ　現状mysqldump でフルバックアップ　　→　今後さらにデータが増えてくると、　　　　バイナリログを使った　　　　増分バックアップの方がよさそう

今後の課題②

□ データ退避とかパーティショニング　　→　古いシリアルの退避とか、　　　　できれば「 xxxx_2015 」とか作りたくないので、　　　　うまくパーティションとか使えると。。

Topic・システムの概要・負荷テストした話・ 2 億件登録したときの話・ update ではまった話・今後の課題

・その他　 Perl のチューニング・まとめ

その他　 Perl のチューニング①

□ コネクションプーリングっぽいこと

　コネクションオブジェクトを　シングルトンにし、 1worker 1 コネクションを共有

　　→　コネクション生成のコストをなくした

その他　 Perl のチューニング②

□ マスタデータをキャッシュ

　 PSGI サーバ起動時に、メモリに DB のマスタデータを保持　　→　 worker 内でメモリは共有されるため、　　　　 DB アクセスが不要になる

　　　　※ただし、「 Copy-On-Write 」なので、　　　　　書き換えようとすると、メモリリークの原因になる

　　　　※ただし、マスタデータを変更する場合には、　　　　　再起動が必要になるので、　　　　　本当は memcached とかを使った方がよさそう

まとめ①

□innodb_buffer_pool_size は大きい方がいい

□ 主キーはシーケンスにした方が insert が早い

□ インデックスの再構築は意外とばかにならない

まとめ②

□ 負荷テスト大事　実際のデータに近いデータでやる

□ 結局計測してみないとわからないことは多い　　→　効果測定にすごく時間がかかるので、　　　　負荷テストとかは、早めにやる

ありがとうございました！