キャッシュ
なんか考えてたら寝れない。
キャッシュというのは、
- 一種のCSE(Common Subexpression Elimination)
- ランダムアクセスを高速化するタグ検索
- プリフェッチ、遅延ストア用のバッファ
のみっつの効果がある。
上ふたつについては、局所性というひとことでまとめられるのだが、CellのSPEのように、いわゆるキャッシュではないローカルメモリを使った実装の場合、ひとつめのほうはカバーできるが、ふたつめのランダムアクセスのほうはカバーできない。なので、個人的には分けたい。
だからなんだというわけではないのだが、いや、ほんと、だからなんだというわけではないのだが…
まず、最初のCSEについて。
これは、ふたつのストレージへのアクセスがあった場合に、一回目に近くに置いておいて、二回目は近くのデータを参照する、というような感じ。
これのためにキャッシュを使うのは大変偲びない。なぜかというと、コードの書きかたで改善できるので、下位レイヤのキャッシュとして実装する必要は無いからだ。
これを下位レイヤとして実装してしまう理由として、CPUのキャッシュについては回避しようが無いし、I/Oのキャッシュは多少余分なロジックが入ってもそれをカバーするだけ高速化できる、そのうえ、アプリケーションロジックは書きかえないでよい、というのがある。
が、個人的には、これは早急に滅びるべきであると思っていて、
- 最悪時間が伸びのびする
- 性能予測がしづらくなる
- タイミングによって再現しない問題である一貫性の問題を見えにくくする
などなど。まあ、これは僕個人が最悪時間を重視したがるというのがあるかもしれん。
大半の人にとって最悪時間はどうでもいいし、性能予測がしづらいのは、ある意味抽象化してあると言えるし、一貫性の問題…って何だろうか？
次にランダムアクセス。
これは仕方ない。一定より広い領域にアクセスする場合の平均時間を短縮するには、タグ付きキャッシュ以外の方法は無い。最悪時間は何をどうやっても短縮しない。
次にプリフェッチ、遅延ストアバッファ。
これも必要…だが、一貫性の問題を起こす。特に遅延ストアバッファは書き込みが保証されないという問題があるので、全体の設計に影響が。
そもそも、RDBMSが遅いのは、ちゃんと書いたのを保証して、次の瞬間にはそれが読めることを保証する必要があるからであって、memcachedで高速化した時に何が失われてるかの説明が無いのがいいのかそれはという感じであった。
いや、memcached的なものが便利な状況というのはわからなくもなくて、
- ストレージが500GBとか以上とか
- データが消えてもよい
- 一貫性があまり重要ではない
- 数倍速くなれば十分
というのを全て満たす場合、というのがぱっと思い付くのだが、この条件を全て満たすwebアプリケーションがそんなにあるという気がしなくて、あと最近のwebプログラマは一貫性の問題とか把握できるのかというのが心配なのだが、失礼な心配だな…
上の文章はあまり関係無くて、
- 今までディスクに残していたものをメモリに置いたら速くなりました
- 今までローカルに置いていたものをネットワーク上に置いたら速くなりました
というのが当たり前のように使われているというのが考えれば考えるほど気持ち悪くて眠れない。ちょっとどっかの勉強会でも行ってみるか…もしくは問い詰められてもいいという人がいれば連絡ください。
あと全然関係無いが
http://www.atmarkit.co.jp/news/analysis/200812/22/chrome.html
一方、IEやFirefoxでは、どうして今までDNSプリフェッチのような仕組みを考えつかなかったのだろうかと問うことには意味があるように思う。
この一文を見つけてしまってさらに眠れない。(誰かが勝手にやる分には許されてもプラットフォームになろうという人がやるのは許されないと思うのだが…)
一般的なキャッシュの副作用については誰か説明を書くべきではないだろうか…
- 一貫性の問題を起こす
- 最悪時間は伸びる
- 余計なアクセスが増えて共有リソースを無駄遣いする(これはプリフェッチの問題か…)
