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

caching: All content tagged as caching in NoSQL databases and polyglot persistence

Using Riak as Cache Layer

Sean Cribbs explains how to use Riak as a caching solution:

  1. Bitcask or Memory backends
  2. The possibility of configuring the cluster for lower guarantees of per-key availability

Then benchmark the system for your scenario.

Original title and link: Using Riak as Cache Layer (NoSQL database©myNoSQL)

via: http://lists.basho.com/pipermail/riak-users_lists.basho.com/2012-October/009680.html


Powered by Redis: PUMA.com

Puma.com and other related web properties are using Redis’ hashes, lists, and sets (sorted and unsorted) for fragment caching and third party responses caching:

We used Redis as our cache store for two reasons. First, we were already using it for other purposes, so reusing it kept the technology stack simpler. But more importantly, Redis’ wildcard key matching makes cache expiration a snap. It’s well known that cache expiration is one of two hard things in computer science, but using wildcard key searching, it’s dirt simple to pull back all keys that begin with “views” and contain the word “articles” and expire them everytime an article is changed. Memcached has no such ability.

Original title and link: Powered by Redis: PUMA.com (NoSQL database©myNoSQL)

via: http://www.viget.com/extend/puma-on-redis/


Optimizing Memcached Performance on a Rapidly Growing Site

Predicting operational growth by monitoring the correct metrics:

Such simple data can reveal a wealth of insights. Most important is the cache’s miss rate: how frequently do we need to regenerate data? It is the miss rate that ultimately impacts site performance. Using such data, we were shocked to discover that we were caching a lot less than we thought, and that our cache actually behaved quite erratically, with a greater than 2x difference between peak and trough miss rates

The story reminded me of the Foursquare accident.

Original title and link: Optimizing Memcached Performance on a Rapidly Growing Site (NoSQL databases © myNoSQL)

via: http://technology.posterous.com/planning-and-engineering-your-cache-for-maxim-0


RavenDB and HTTP Caching

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


CouchDB Web Caching: Cache-Control Headers

Good question on CouchDB mailing list related to CouchDB caching:

Is there a way to control HTTP header: Cache-Control in CouchDB?

☞ permalink.gmane.org

Just to connect the dots:

Original title and link: CouchDB Web Caching: Cache-Control Headers (NoSQL databases © myNoSQL)