こんにちは。クルーズ株式会社CTOの鈴木です。
今回は「SHOPLISTの脱レガシ―システム」の5回目「脱レガシーシステム⑤（DB容量を1.6TB⇒1.1TBに減らした話）」で話した InnoDBのテーブル圧縮の検証についての話です。
検証を思い立ったきっかけ
SHOPLISTのインフラ的な問題の１つで、本番のデータベース容量が1.6TBある問題の解決案を考えていて、サービス上参照しないけど、だからと言ってSQLでデータ抽出できるDBにもっときたいデータがあるという話が分かりました。
じゃあ昔からやってみたかったネタでテーブル圧縮やってみようと思い立ったのがきっかけです。
実際にはこのテーブル圧縮のほかにもストレージタイプの変更であるとかインスタンスサイズについても変更するのですが、今回の検証としてはテーブル圧縮を進めました。
すごくざっくりなぺージ圧縮のしくみの理解
斜め読みなので正確に理解しているわけではないのですが、ほかのRDBMS同様にデータ格納時に圧縮ページを作成してストレージ保存する仕組みのようです。
なので期待する挙動としてはデータサイズは減り、書き込みが遅くなるはずで、実際どのくらいの効果があるかを把握するため、当社のメンバーに協力してもらい実際のデータで検証を行いました。
検証の概要
検証方法としては実際のテーブルをdumpし、同じ構造のテーブルをCREATE する際にDDLに「ROW_FORMAT=Compressed KEY_BLOCK_SIZE=8」を追加した別テーブルdumpしたデータをRestoreして、非圧縮テーブルと圧縮テーブルを作りテーブルの容量とRestore速度を比較しました。
前提としてはDBMSはMariaDB10.2です。
検証結果⓵ 圧縮率比較
結論：約5割ほどの圧縮率となる。
※データによって差があるが、Text型が多いテーブルは効果があるように見受けられる
圧縮無し
[root@ecSubDb01 compression_test]# ll -htr | grep "product_m.ibd" -rw-rw---- 1 mysql mysql 11G Jul 15 15:32 product_m.ibd
圧縮あり
[root@ecSubDb01 compression_test]# ll -htr | grep "product_m.ibd" -rw-rw---- 1 mysql mysql 5.1G Jul 15 15:40 product_m_compression.ibd
検証結果② Insert速度（Restore速度で検証）
結論：約２倍遅くなる。
圧縮無し
[root@ecSubDb01 mysql]# time mysql compression_test < session_t_local.dump real 28m23.795s user 1m8.439s sys 0m4.598s
圧縮あり
[root@ecSubDb01 mysql]# time mysql compression_test < session_t_local.dump real 60m42.655s user 1m7.089s sys 0m4.394s
結論
期待通りといえば期待通り。ただ、ずば抜けて1/10に圧縮されます！とかではなかったです。 KEY_BLOCK_SIZEを変えていけばなどもっと検証すればいろいろ新しい発見があったかもしれないのですが、期待した通りの結果だったためここで検証としては終了としました。
※2020年の内容を記事にしており、2020年11月以降PHP7サポート切れをはじめとした脆弱性リスクへの対処は完了しております。
