SitePoint: New Articles, Fresh Thinking for Web Developers and Designers |
Kevin Yank氏がSitePointにおいて、Free Performance with MySQL Table Typesのタイトルのもと、実際にSitePointのイベントに関連して発生したMySQLのパフォーマンス問題をどのように考えて解決していったかを紹介している。データベースパフォーマンスの改善事例として興味深い。
SitePointはMiles Burke氏がまとめた書籍「The Principles of Successful Freelancing」の無償PDFを、Twitterのフォロアになれば手に入れられるというキャンペーンを実施した。Twitterの利用制限を避けつつ使いやすい仕組みを提供するために、最終的に、今のスタイルの実施形式に落ち着いたという。このあたりの流れの詳細はFree Performance with MySQL Table Typesにまとまっている。実装では、PHPで使うセッションデータをMySQLに保持する仕組みが採用されている。
実際にイベントがはじまると、MySQLサーバの負荷が異常に高いものになり、まともにサービスが提供できない状況になったという。開発チームは当初、テーブルの種類を指定せずにセッションデータを保持するテーブルを作成した。この場合、MyISAMストレージエンジンが使われることになる。MyISAMストレージエンジンはいくつかの機能をサポートしないことでシンプルに、そしてパフォーマンスを発揮できるようにしたもので、多くのケースで適切なテーブルだと考えられている。
しかし今回のケースでは、テーブルレベルでロックをかけるというMyISAMの特徴がそのままパフォーマンスの低下につながってしまったという。細かにセッションのデータをやり取りするような使い方では、MyISAMテーブルでは性能が発揮できなかった。そこで解決方法としてInnoDBに焦点があてられる。MySQLはほかにも多くの機能をサポートしたInnoDBストレージエンジンを採用している。ただし、InnoDBは優れた機能を提供するが、MyISAMと比べるとパフォーマンスが発揮できないとみられている。
しかしながら、行レベルでロックをかけることができるInnoDBの性能が今回の用途にはマッチしており、テーブルの種類をMyISAMからInnoBDに変更することで、負荷は低下し、許容できるレベルで動作するようになったと報告されている。
さらに開発チームはテーブルの種類としてメモリストレージエンジンを検討。メモリストレージエンジンにはテーブルレベルでロックを実施するというMyISAMストレージエンジンと同じ懸念があったものの、実際にInnoDBからメモリストレージエンジンへ変更したところ、実質的に負荷をほとんどなくすことに成功したと説明されている。ただし、メモリストレージエンジンはディスクへ書き込まないためシステムが不慮にリスタートした場合などにデータを失う可能性があるほか、性能を発揮するためにテーブルに含められるレコードの型やサイズに制限があるため、万能薬というわけではない。
Kevin Yank氏はこうした経験を踏まえた上で、MySQLのパフォーマンスを検討するときは、ストレージエンジンにどれを採用するかを考える時間を設けた方がいいとアドバイスしている。