Question

My main interest resides in use cases where these tools could be used to performance tune existing transactional RDBS-based applications.
Are there good sources for common design patterns involving these tools?

After some reasearch I found the following sample use-cases for Redis, more difficult (surely slower) to implement on a SQL datastore:

• Feeds or tail-like logic (last post appears on top)
  Thanks to Redis’ list-management features:

    LPUSH post:<id>:comments <comment> //posts comment  
    LRANGE post:<id>:comments 0 9      // instantly gets last 10 comments 
  

• Tag management
  Leveraging Redis’ Set-management functionalities (and set intersaction) it’s easy to implement tag systems

• Score boards on high-concurrency high-volume services
  Redis can insert scores in O(log(N)) (i.e. fast enough) and then use sorted sets to retrieve score boards that in SQL would require

    SELECT * FROM table
    ORDER BY score LIMIT 0 10 
  

Answer 1

Redis and Memcached are in-memory data store. The main difference is that Memcached is not persistent (the content is flushed when the server is restarted) while Redis is. Additionally, Redis provides support for several data structures, such as Sets.

The most common use cases for in-memory data store is caching. Memcached has been the favourite choice for several years. Redis can solve almost all Memcached tasks with the propert configurations.

Because Memcached is not persistent, it can’t trusted to store persistent data. This is the reason why its best usage is as cache store.

Redis is, after all, a database. It means caching is just one of its applications. Generally speaking, Redis is a very good choice whenever you need to have a very fast-data store. The user cases include logging, queue systems, indexes.

A few examples:

• Resque is a Redis-backed Ruby library for creating background jobs
• Hoptoad changed the infrastructure in order to use Redis as fast-storage to store User data. Data is then post-processed to MySQL.