Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
10年以上前投稿 修正あり

クエリの最適化とキャッシュの有効化の利点・欠点

データベースの負荷軽減の方法としては、クエリ(あるいはMySQL自体)の最適化と、memcachedなどのキャッシュを挟むという2通りの方法がある。それぞれについての利点と欠点を明らかにし、アプローチの方法を提案する。

原文
Query optimization versus caching | Master MySQL (English)
翻訳依頼者
D98ee74ffe0fafbdc83b23907dda3665
翻訳者
D98ee74ffe0fafbdc83b23907dda3665 doublemarket
原著者への翻訳報告
未報告


今日は、全く新しいプロジェクト(Greenfieldプロジェクト)に適用できそうな色々な最適化の方法を比較したメリットについてみていきたい。すなわち、過去の判断からの圧力を受けたり、それまで最適化をほとんどしていないプロジェクトのことだ。

具体的に言うと、比較したい最適化法とは、MySQL自体を最適化するか、キャッシュするかの2つである。これらの最適化法は、完全に独立した方法だということを先に言っておくべきだろう。そのうちの片方だけをやるようにこだわるのは、両方とも開発者のリソースを使うことだからだ。

クエリの最適化

この最適化は一般的には、MySQLに送られてきているクエリを確認することと、それらに対してEXPLAINを実行することから始まる。調査によっては、インデックスを追加したり、スキーマに少々の変更を加えるのはよくあることだろう。

利点

  1. 最適化されたクエリは通常、アプリケーションにアクセスするあらゆるユーザに対して高速に応答する。インデックスはデータに対して対数探索でのアクセス(電話帳から調べるような分割統治法)を提供するものなので、ある程度のデータ量の増大にもパフォーマンスを維持する。インデックスが張られていないデータへのクエリをキャッシュで隠してしまうのは、場合によってはデータ量増大に対しては悪い結果になりえる。データが増えるにしたがって、キャッシュにヒットしないユーザはアプリケーションが使えないぐらいひどいパフォーマンス問題に当たることになる。
  2. MySQL側を最適化することで、キャッシュを無効にしたり、有効期限切れのデータをキャッシュから読み込んでしまうことを心配する必要がない。
  3. MySQL側を最適化すると、システムのスタックをシンプルに保てるし、開発環境でも同期したり作業するのが簡単になる。

欠点

  1. クエリによってはインデックスを張るだけでは改善せず、アプリケーションによって改善が難しいスキーマ変更をしなくてはならない。
  2. スキーマ変更の方法によっては非正規化することになる(データが重複する)。これはDBAにとっては一般的なテクニックではあるが、全てのデータがアプリケーションによって更新されるのを確実にするか、トリガによってそういった変更を保証する必要がある。
  3. 最適化の方法がMySQL特有のものになることがある。つまり、ベースにあるソフトウェアが複数のデータベース上で動く者の場合、インデックスを張るよりもさらに複雑な最適化をするのが難しくなってしまう。

キャッシュを追加する

このタイプの最適化では、アプリケーションのプロファイリングが必要で、思い処理をMySQLからmemcachedやRedisといった外部のキャッシュに逃がすことになる。

利点

  1. MySQLで最適化するのが難しい重いクエリがあるアプリケーションの場合、非常にうまくいく。例えば、大きな集約やGROUP BYを使うクエリだ。
  2. キャッシュは、システムのスループットを挙げるのにうまくはたらく。例として、一度に多数のユーザがアプリケーションにアクセスしてくることによるスローダウンなどに対して。
  3. キャッシュを他のアプリケーションの最上位に置くのがより簡単。例えば、あなたのアプリケーションが、MySQLにデータを保存する他のソフトウェアパッケージのフロントエンド部分だったとすると、そのソフトウェアパッケージにデータベースに関する変更を加えるのは非常に難しい。

欠点

  1. データに対してたくさんのアクセスパターンがあると(異なるフォーマットで異なるたくさんのページに分かれているなど)、更新時にキャッシュを無効化するのが難しくなり、期限切れデータが返されることになる。これへの対策として、よりきめ細かなデータをキャッシュする必要がある。しかしこれは、キャッシュからのデータの取り出しのレイテンシがかかるようになるなど問題がある。
  2. 生成処理が重いオブジェクトをキャッシュすることは、キャッシュミスしたリクエストに対してパフォーマンスの急落を招く(クエリの最適化の#1を見よう)。よいパフォーマンスのあり方としては、ユーザ間のばらつきを狭めるべきであって、平均をみてはならない(キャッシュの場合そうなってしまいがち)。
  3. 甘い考えのキャッシュ実装では、cache stampedeのようなバグに悩まされる。ちょうど先週、複数のユーザが同時に同じキャッシュコンテンツを更新しようとしてデータベースサーバがダウンした人のお手伝いをしたところだ。これに対する正しい解決策は、キャッシュの再生成をシリアライズするロックのレベル付けを導入することだ。

結論

通常、MySQLの最適化をまず調べてみるように薦めていて、それが最もエレガントな解決策だと考えている。しかし長期的に見れば、ほとんどのアプリケーションはどちらのアプローチもある程度は実装するものだろう。

次の記事
MySQLのためのLinuxチューニングヒント
前の記事
PostgreSQLのコマンドラインの動きを改善してみる

Feed small 記事フィード

新着記事Twitterアカウント