rails smart cacheの実現に関する考え方の下書き.
最近railsのcache設計を研究したところ、気に入らないところがいくつかありました.
*cache expiryの作成が煩雑
*ページングキャッシュのクリアは、既存のcache実装のサポートが不十分です
*大量のキャッシュを一度にクリアしたときに、汚れたデータの読み取りの問題が発生します.
私はいくつかのblogと関連する文章を調べて、彼らの愚痴と設計からいくつかの啓発を得て、cacheはもっとよくすることができて、もっと知能的で、更に開発者の仕事量を減らすことができると思います.以下は私の設計構想のいくつかの下書きで、深く分析して、実行可能だと思ったら、彼に手を出すことができます.
*cacheパケットはサポートされています.
*シンプルなexpiry rulesをサポート
*適切な設計により、大量のキャッシュを一度に消去する際のダーティデータの読み取り確率とタイムウィンドウを低減
*memcacheのサポートのみを考慮します.
*可能な限り既存のフレームワークに基づいてシンプルな拡張を行い、開発量を削減します.
cacheパケットのサポートは同時に多くのメリットをもたらすことができます.第一に、ページングキャッシュの1回のexpireをサポートします.同時に「汚いデータの読み取りを減らすタイムウィンドウ」にも役立ち、cacheグループの設計は設計全体の重要な考え方の一つである.次にcacheグループの設計について説明します.
*メモリはhashを開きます.keyはgroup IDです.valueは特有のGroupオブジェクトで、このGroupオブジェクトの設計目的は
同じグループのすべてのcache keyをできるだけ簡単に、できるだけ早くクリアします.
*expireと同じグループのすべての汚いキャッシュデータには、2つのポリシーがあります.1)cacheKeyに従って1つずつ明確にします.2)クリアせずにバージョン番号を付けます.
1つ目のポリシーは、GroupとCacheKeyの一対の多関係を保存する必要があることを意味します.この保存はデータベースで保存する必要がある可能性があります.複雑さとパフォーマンスのオーバーヘッドは選択されていないようです.
2つ目のポリシーは、キャッシュをクリアしたり、データベースをクエリーしたりする必要はありません.しかし、この戦略にはいくつかの作業が必要です.キャッシュに追加するときは、既存のcacheKeyを変更し、Version=1のようなバージョンIDを追加する必要があります.get cacheの時
同じ仕事もしなければなりません.expireがGroupを汚す場合は、Groupオブジェクトのversionプロパティを1つ増やすだけです.既存の汚れたデータはmemcacheの自動クリーンアップポリシーによって自動的にクリアされます.
この分析から見ると、第2の戦略を選んだほうがいいと思います.
全体smart_Cacheの設計実装は既存のcache実装に基づいてalias_method(railsのAOP)は私たち自身の中間論理に参加した.このように開発量が最も少ない.
設計のもう一つの鍵はexpiry rulesの設計であり、現在rails cacheのexpireの作成は比較的簡単であり、私たちはさらに、初歩的な
configディレクトリの下にcacheを追加するように設計されています.expiry_rules.rb、サンプルコードは以下の通りです.
上のコードのキー:
:expire_rules=>[cud_rule(User,Department,Room),rule(User.update*)])
ここでcudは、あるmodelオブジェクト上のcreate,update,deleteメソッドが完了した後を表す.
後のrule(user.update*)は、UserModel上のルールに合致するいくつかのメソッドが呼び出された後を表します.
既存のキャッシュメソッドcacheは、cache fragmentの作成などのgroup=>your groupのプロパティを最後に追加する必要があります.
参考記事:
* web agile devel....
*
http://www.railsenvy.com/2007/2/28/rails-caching-tutorial
*
http://blog.leetsoft.com/2007/5/22/the-secret-to-memcached
*
http://blog.craigambrose.com/past/2007/11/13/caching_makes_your_brain_explode/
*
http://cfis.savagexi.com/articles/2007/09/05/rails-unusual-architecture
.............
*cache expiryの作成が煩雑
*ページングキャッシュのクリアは、既存のcache実装のサポートが不十分です
*大量のキャッシュを一度にクリアしたときに、汚れたデータの読み取りの問題が発生します.
私はいくつかのblogと関連する文章を調べて、彼らの愚痴と設計からいくつかの啓発を得て、cacheはもっとよくすることができて、もっと知能的で、更に開発者の仕事量を減らすことができると思います.以下は私の設計構想のいくつかの下書きで、深く分析して、実行可能だと思ったら、彼に手を出すことができます.
*cacheパケットはサポートされています.
*シンプルなexpiry rulesをサポート
*適切な設計により、大量のキャッシュを一度に消去する際のダーティデータの読み取り確率とタイムウィンドウを低減
*memcacheのサポートのみを考慮します.
*可能な限り既存のフレームワークに基づいてシンプルな拡張を行い、開発量を削減します.
cacheパケットのサポートは同時に多くのメリットをもたらすことができます.第一に、ページングキャッシュの1回のexpireをサポートします.同時に「汚いデータの読み取りを減らすタイムウィンドウ」にも役立ち、cacheグループの設計は設計全体の重要な考え方の一つである.次にcacheグループの設計について説明します.
*メモリはhashを開きます.keyはgroup IDです.valueは特有のGroupオブジェクトで、このGroupオブジェクトの設計目的は
同じグループのすべてのcache keyをできるだけ簡単に、できるだけ早くクリアします.
*expireと同じグループのすべての汚いキャッシュデータには、2つのポリシーがあります.1)cacheKeyに従って1つずつ明確にします.2)クリアせずにバージョン番号を付けます.
1つ目のポリシーは、GroupとCacheKeyの一対の多関係を保存する必要があることを意味します.この保存はデータベースで保存する必要がある可能性があります.複雑さとパフォーマンスのオーバーヘッドは選択されていないようです.
2つ目のポリシーは、キャッシュをクリアしたり、データベースをクエリーしたりする必要はありません.しかし、この戦略にはいくつかの作業が必要です.キャッシュに追加するときは、既存のcacheKeyを変更し、Version=1のようなバージョンIDを追加する必要があります.get cacheの時
同じ仕事もしなければなりません.expireがGroupを汚す場合は、Groupオブジェクトのversionプロパティを1つ増やすだけです.既存の汚れたデータはmemcacheの自動クリーンアップポリシーによって自動的にクリアされます.
この分析から見ると、第2の戦略を選んだほうがいいと思います.
全体smart_Cacheの設計実装は既存のcache実装に基づいてalias_method(railsのAOP)は私たち自身の中間論理に参加した.このように開発量が最も少ない.
設計のもう一つの鍵はexpiry rulesの設計であり、現在rails cacheのexpireの作成は比較的簡単であり、私たちはさらに、初歩的な
configディレクトリの下にcacheを追加するように設計されています.expiry_rules.rb、サンプルコードは以下の通りです.
SmartCache::Rules do |config|
config.add_rule(:group=>"user list",:expire_rules=>[cud_rule(User,Department,Room),rule(User.update*)])
config.add_rule(:group=>"department list",:expire_rules=>[cud_rule(Department,Room),rule(Department.update*)])
end上のコードのキー:
:expire_rules=>[cud_rule(User,Department,Room),rule(User.update*)])
ここでcudは、あるmodelオブジェクト上のcreate,update,deleteメソッドが完了した後を表す.
後のrule(user.update*)は、UserModel上のルールに合致するいくつかのメソッドが呼び出された後を表します.
既存のキャッシュメソッドcacheは、cache fragmentの作成などのgroup=>your groupのプロパティを最後に追加する必要があります.
<% cache :controller="user",:action=>"list",:page=>"params[:page]",:group=>"user list" do %>
//rhtml code here to renderring view
<% end %>
caches_action :list, :show,:group="test group"
参考記事:
* web agile devel....
*
http://www.railsenvy.com/2007/2/28/rails-caching-tutorial
*
http://blog.leetsoft.com/2007/5/22/the-secret-to-memcached
*
http://blog.craigambrose.com/past/2007/11/13/caching_makes_your_brain_explode/
*
http://cfis.savagexi.com/articles/2007/09/05/rails-unusual-architecture
.............