前回お約束した通り、今日はストレージのキャッシュについて述べてみたいと思います。
と、その前に前回の記事でいろいろコメントいただきありがとうございました。一応補足させていただくと、前回の記事では冒頭に「ハイエンドストレージの導入云々」とあるようにハイエンドストレージの話が前提となります。同様に今回もハイエンドストレージの話が前提となりますのでご了承ください。
さて、最近のハイエンドストレージのキャッシュは大容量です。代理店さんからストレージの提案をいただくと、最近では1GBなんて当たり前。4GBや8GBは割と普通で、まれに64GBなんて提案をいただいたこともあります（64GBっていったらハードディスク容量と変わんないよ～＾＾）。しかしストレージのキャッシュは非常に高価です。そこで最適なキャッシュ容量を割り出すためにはどうしたらよいか考えていきましょう。
そもそもストレージのキャッシュって何？
キャッシュする・・・貯蔵するということなのですが、WEBブラウザーのキャッシュやWEBキャッシュサーバと違ってストレージのキャッシュって何を貯蔵するのかちょっとわかりにくいです。ストレージにおけるキャッシュの役割はベンダーによっても違うようですが主に下記の3点に集約されるようです。
- 最近アクセスしたデータ（読み取りキャッシュ)
- 使用を見越してディスクから読み取られたデータ（先読みキャッシュ）
- 最近書き込まれたデータ（書き込みキャッシュ）
キャッシュのヒット率と利用率について考える
これを踏まえてキャッシュのヒット率と利用率について考えてみたいと思います。最適なキャッシュ容量を考える上で重要なのはリードの場合はキャッシュのヒット率、ライトの場合はキャッシュ利用率です。WEBブラウザーのキャッシュやWEBキャッシュサーバの場合はキャッシュ容量を大きくすればするほどキャッシュヒット率が向上していきますが、ストレージの場合は場合によります。ここではシーケンシャルリード、ランダムリード、シーケンシャルライト、ランダムライトの4パターンで考えて見ましょう。
- シーケンシャルリード
- 連続したデータをリードする場合です。この場合は先読みキャッシュ機能のおかげで高いキャッシュヒット率が期待できます。このアクセスが多い場合はキャッシュ容量を増やせるだけ増やすのがよいでしょう。
- ランダムリード
- ランダムにデータをリードする場合です。この場合は上記キャッシュ機能１，２，３のいずれにもひっかからないのでこのアクセスが多い場合はキャッシュヒット率を上げるためにキャッシュ容量を増やすことは得策ではありません。
- シーケンシャルライト
- 連続したデータをライトする場合です。この場合は書き込みキャッシュ機能のおかげで高いキャッシュ利用率が期待できます。
- ランダムライト
- ランダムにデータをライトする場合です。この場合も書き込みキャッシュ機能のおかげで高いキャッシュ利用率が期待できます。
考察
ストレージキャッシュはランダムリードに弱いです。DBはランダムリードが多いと思われるのでDB用途にストレージを購入する場合はこの弱点回避のためにはキャッシュ容量を増やすこと以外の別の手段を取る必要があります。一番効果的なのは一番アクセスが多いデータだけに限ってキャッシュ上に全てのデータを置くことだとかいろいろ考えられますね。それは今回の趣旨と違うのでまたいつか別の機会にでも。
※余談
余談ですが、キャッシュはCacheと綴ります。Cashと誤記される事例を本当によく見ますので気をつけましょう。Cashだと・・・現金ですね。Cashを積めばたしかにパフォーマンスは上がりそうです。^^
