キャッシュについて

⇒SOAとは何かを考える from JavaOne＠arclamp.jp

リソースAとリソースBがあり、リソースAはリソースBより１００倍速いとする。たとえば、リソースAがメモリ、リソースBがハードディスク。

アプリケーションが設定ファイルを見て、動作を切り替えるとする。たとえば、デバッグ情報のON/OFF、ログファイルパス等々。 ここで、リソースBに用意されている設定ファイルを毎回READしたらどうなるか？ １回だけデバッグ情報を参照するだけなら大したことはないが、毎件づつ処理するたびに設定ファイルのデバッグ情報をREADしていたら、本来の仕事よりオーバーヘッドがかかることになる。

そこで、一度リソースAであるメモリに読み込み、あとはメモリの設定を呼んで分岐する。

ここまではなんとも当たり前の話かもしれない。

さて、ここでリソースAとリソースBがどちらも同じ速度で動作するようになったらどうだろう。 つまりリソースBに設定ファイルがあるが、毎回これをREADしても全然遅くならないということになる。

つまりキャッシュ管理をリソースAを使って実装してもまったくの無意味となる。 確かに新規のプログラムは楽になるかもしれない。しかし、既存のプログラムはどうしようか・・・。せっかく小細工して１０％パフォーマンスアップしたが、メンテナンスコストは５０％悪化みたいなことをしていたら、もう存在する価値がなくなる。

こんなときにDIで取り替えることができたら・・・。今までキャッシュしていたけど、DIコンテナの設定１つでキャッシュなしにできる。そんな設計になっていないと意味がないわな。

つまり、アプリケーション層で一生懸命キャッシュ管理していて、DIでDBアクセサを切り替えられるようになっていたとしても、DBアクセサなんて１０年 間取り替える必要もなかったのに、キャッシュなしにしたいと思ったら、全部アプリケーションを作り直しだったみたいなことになりそうです・・・。

なんでこんなことを書いたかというと、ローカルとネットワークは厳密に区別していた。私なんかはDOS世代なので、ローカルがデフォルトで、必要なときだ けネットワークにつなげるみたいな感覚がまだまだ残っている（これでもADSLを引いてから常時接続にはなっていますが・・・）。

近い将来、ローカルでもネットワークでもパフォーマンスが変わらなくなったらどうなるだろうか。その時代に新規開発したものは良いのだが、今あるものはや はりネットワークは遅いからローカルでキャッシュしてみたいな発想をあちこちでしているのではないだろうか。それは簡単に取り外すことができるのだろう か・・・。