When to use a key/value store such as Redis instead/along side of a SQL database?

I have read great things about key/value stores such as Redis but I can't seem to figure out when it's time to use it in an application.

Say I am architecting a web-based application; I know what stack I am going to use for the front-end, back-end, database(s), etc..what are some scenarios where I would go "oh we also need Redis for X,Y, or Z."

I would appreciate node.js examples as well as non-node.js examples.

Solution 1:

I can't seem to figure out when it's time to use it in an application.

I would recommend you to read this tutorial which contains also use cases. Since redis is rather memory oriented it's really good for frequently updated real-time data, such as session store, state database, statistics, caching and its advanced data structures offers versatility to many other scenarios.

Redis, however, isn't NoSQL replacement for classic relational databases since it doesn't support many standard features of RDBMS world such as querying of your data which might slow it down. Replacement are rather document databases like MongoDB or CouchDB and redis is great at supplementing specific functionality where speed and support for advanced data structures comes handy.

Solution 2:

I think nothing explains better the use cases for Redis than this article: http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

I bet you'll have an aha! moment. ;)

A quote from a previous reader:

I've read about Redis before and heard how companies are using it, but never completely understood it's purpose. After reading this I can actually say I understand Redis now and how it's useful. Amazing that after hearing so much about it all it took was a relatively simple article.

A quote from the article:

Redis is different than other database solutions in many ways: it uses memory as main storage support and disk only for persistence, the data model is pretty unique, it is single threaded and so forth. I think that another big difference is that in order to take advantage of Redis in your production environment you don't need to switch to Redis. You can just use it in order to do new things that were not possible before, or in order to fix old problems.

Use cases the article touches on:

• Slow latest items listings in your home page
• Leaderboards and related problems
• Order by user votes and time
• Implement expires on items
• Counting stuff
• Unique N items in a given amount of time
• Real time analysis of what is happening, for stats, anti spam, or whatever
• Pub/Sub
• Queues
• Caching

Solution 3:

• I would love to use redis on the real time projects. I did recently for one gps tracking system which was previously built on mysql as a database.

  ADVANTAGE

  1. Every time the tracker broadcast data I do not need to open mysql connection and store on it. We can save it on redis and later migrate to mysql using some other process. This will avoid concurrent connection from mutiple tracker to mysql.
  2. I can publish all those gps data and other clients(javascript/android) can subscribe in a real time using message queue based on redis
  3. I can trigger real time alerts

Solution 4:

One thing off hand is that Redis isn't a relational database. If you're going to be needing an SQL "JOIN" then you won't want to use Redis, nor any other non-relational database. Redis is faster though than most relational databases. If you're only going to be doing key:value pair queries, then you'll want to use Redis.