ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close
Wednesday, 12 January 2011
‹ Back

RavenDB and HTTP Caching

About:
,
,
,

Ayende writing about choosing between implementing RavenDB cache similar to Hibernate second level cache1 or HTTP caches:

RavenDB is an HTTP server, in the end. Why not use HTTP caching? […] HTTP Caching is a somewhat complex topic, if you think it is not, talk to me after reading this 24 pages document describing it. But in essence, I am actually using only a small bit of it.

Firstly, if you really want to understand web caches I strongly recommend Mark Notthingham’s Caching tutorial for web authors and webmasters.

Getting back to Ayende’s post, a couple of comments

  1. the mechanism described in the post is called conditional GET. According to the HTTP/1.1 RFC:

    The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

  2. an HTTP caching mechanism should also consider reversed proxies’ behavior. For these to work freshness (Expires) and cache-control (Cache-control) headers must be used

  3. without reversed proxies, query caching based only on ETags will in most cases just reduce the bandwith (by not sending back a response), but will continue to fetch the data for calculating the query ETag. Basically, the benefits are smaller.

On the topic of HTTP-based caching, you should also check the article CouchDB and Varnish caching .

  1. I’m still confused why he mentiones Hibernate’s second level caching as that is related to caching query results, while the post focuses on single value access caching. Thanks to ewhauser this was clarified.  ↩

Original title and link: RavenDB and HTTP Caching (NoSQL databases © myNoSQL)

via: http://ayende.com/Blog/archive/2011/01/11/ravendb-amp-http-caching.aspx