キャッシュと言っても種類が多い
キャッシュの種類
ブラウザキャッシュ
メインDBの負荷軽減 | X |
表示速度UP | O |
ヒット率 | X |
実装工数 | O |
コスト | O |
各々のクライアントに保存するキャッシュ
同じブラウザでのキャッシュになるので、ヒット率はかなり低くなってしまいます。
コストも実装もかからないので、念の為、画像やJS、CSSなどをブラウザでキャッシュしている所が多いです。
CDN
メインDBの負荷軽減 | O |
表示速度UP | O |
ヒット率 | O |
実装工数 | X |
コスト | X |
Akamaiなどが有名なサービスで、負荷の軽減、表示速度UP、ヒット率もいいのです。
しかし、ページをキャッシュしてしまうので、そのページでのお気に入り登録などの動的な機能が使えなくなってしまいます。
なのでログインユーザーにはキャッシュしないというような設定をしている所が多いです。
テンプレートキャッシュ
メインDBの負荷軽減 | O |
表示速度UP | O |
ヒット率 | △ |
実装工数 | O |
コスト | O |
smartyのtemplate_cがわかりやすい例かと思います。
この場合はWEBサーバーが複数あった場合にキャッシュのヒット率が低くなるなどのデメリットがあるかと思います。
DBから取得したデータを取りやすい場所に保管しておいて、次からはその保管してる場所から取得すればDBの負荷は下げられます。
DBから取得した配列などのデータをJSONにしてキャッシュするより、テンプレートキャッシュにした方がレンダリングの速度分速くなります。
Redisでキャッシュ
メインDBの負荷軽減 | O |
表示速度UP | O |
ヒット率 | O |
実装工数 | X |
コスト | △ |
とりあえず、負荷がかかりそうな所にRedisとかMemcacheでキャッシュして負荷を軽減するというようなシステムが多かった気がします。
ただ、いくらRedisにキャッシュしたからといって実装方法が間違っていたら、大きい表示速度UPの効果は望めないのではと思います。
例えば、商品情報のキャッシュをしたとして、100商品を見せる一覧ページで100回Redisからのデータ取得が必要となります。
そうなると、メインDBの負荷を下げられたとしてもスピードUPには繋がらないのではと思います。
この場合は一覧の表示条件に合して100商品のキャッシュを一つにすべきなのではと思います。
ただ、一覧ページは更新頻度によってもキャッシュが好ましくないケースがあったりなど、なかなか一概に言えない難しさがあります。
RDBMSのクエリキャッシュ
メインDBの負荷軽減 | △ |
表示速度UP | O |
ヒット率 | △ |
実装工数 | O |
コスト | X |
RDBMSの場合クエリをキャッシュできるので、実は重いクエリだけどもキャッシュのおかげで助かっているというような事もありえるかもしれないです。
しかし、DBのメモリには上限があるので、クエリキャッシュは当てにしない方がいいのではと思います。
CDNやRedisのキャッシュでも動的ページではキャッシュできる範囲、有効期限などに制限がかかるため、上手い設計が中々できないと思います。
保存先を違うところに写してメインDBの負荷をただ下げただけという事になっている所が多いのではと思います。
費用対効果も特に検証せずにただなんとなくキャッシュしているという事に陥っている現場は多いように思います。
キャッシュを使うと、開発とテストの難易度と工数が高くなってしまいます。
そこで、MongoDBをメインにすればキャッシュしなくてもRDBMSに比べてだいぶ早いので、MongoDBを使ってみてもいいのではと思います。
そうすれば、早く、コストのかからないWEBシステムが可能なのではと思います。
登録日:
更新日: