Scroll To Top

Build Scalable Solutions with REDIS

Build Scalable Solutions with REDIS

Redis = Remote Dictionary Service

If you can list all complex use case to REDIS and discover you aren’t at risk of running out of RAM by using REIDS there is a great chance you should probably use REDIS.
It’s a “NoSQL” key-value data store. accurately, it is a data structure server.

Not like other NO-SQL DB i.e MongoDB (which is a disk-based document store), though MongoDB could be used for similar key/value use cases.
The nearest analog is probably to think of REDIS as Memcached, but with built-in persistence (snapshotting or journaling to disk) and more datatypes.

Those two additions may seem pretty minor, but they are what make Redis pretty incredible. Persistence to disk means you can use Redis as a real database instead of just a volatile cache. The data won’t disappear when you restart, like with memcached.

The additional data types are probably even more important. Key values can be simple strings, like you’ll find in memcached, but they can also be more complex types like Hashes, Lists (ordered collection, makes a great queue), Sets (unordered collection of non-repeating values), or Sorted Sets (ordered/ranked collection of non-repeating values).

This is only the tip of the Redis iceberg, as there are other powerful features like built-in pub/sub, transactions (with optimistic locking), and Lua scripting.

The entire data set, like memcached, is stored in-memory so it is extremely fast (like memcached)… often even faster than memcached. Redis had virtual memory, where rarely used values would be swapped out to disk, so only the keys had to fit into memory, but this has been deprecated. Going forward the use cases for Redis are those where its possible (and desirable) for the entire data set to fit into memory.

Redis is a fantastic choice if you want a highly scalable data store shared by multiple processes, multiple applications, or multiple servers. As just an inter-process communication mechanism it is tough to beat. The fact that you can communicate cross-platform, cross-server, or cross-application just as easily makes it a pretty great choice for many many use cases. Its speed also makes it great as a caching layer.

10 Common Web/API Use Cases Solved In Redis that can be implemented in your next app
Common Redis primitives like LPUSH, and LTRIM, and LREM are used to accomplish tasks programmers need to get done, but that can be hard or slow in more traditional stores. A very useful and practical article. How would you accomplish these tasks in your framework?

  • Show latest items listings in your app home screen. This is a live in-memory cache and is very fast. LPUSH is used to insert a content ID at the head of the list stored at a key. LTRIM is used to limit the number of items in the list to 5000. If the user needs to page beyond this cache only then are they sent to the database.
  • Leaderboards and related problems. A leader board is a set sorted by score. The ZADD commands implements this directly and the ZREVRANGE command can be used to get the top 100 users by score and ZRANK can be used to get a users rank. Very direct and easy.
  • Order by user votes and time. This is a leaderboard like Reddit where the score is formula the changes over time. LPUSH + LTRIM are used to add an article to a list. A background task polls the list and recomputes the order of the list and ZADD is used to populate the list in the new order. This list can be retrieved very fast by even a heavily loaded site. This should be easier, the need for the polling code isn’t elegant.
  • Implement expires on items. To keep a sorted list by time then use unix time as the key. The difficult task of expiring items is implemented by indexing current_time+time_to_live. Another background worker is used to make queries using ZRANGE … with SCORES and delete timed out entries.
  • Counting stuff. Keeping stats of all kinds is common, say you want to know when to block an IP addresss. The INCRBY command makes it easy to atomically keep counters; GETSET to atomically clear the counter; the expire attribute can be used to tell when an key should be deleted.
  • Unique N items in a given amount of time. This is the unique visitors problem and can be solved using SADD for each pageview. SADD won’t add a member to a set if it already exists.
  • Real time analysis of what is happening, for stats, anti spam, or whatever. Using Redis primitives it’s much simpler to implement a spam filtering system or other real-time tracking system.
  • Pub/Sub. Keeping a map of who is interested in updates to what data is a common task in systems. Redis has a pub/sub feature to make this easy using commands like SUBSCRIBE, UNSUBSCRIBE, and PUBLISH.
  • Queues. Queues are everywhere in programming. In addition to the push and pop type commands, Redis has blocking queue commands so a program can wait on work being added to the queue by another program. You can also do interesting things implement a rotating queue of RSS feeds to update.
  • Caching. Redis can be used in the same manner as memcache.
  • Inquire Now










      Without our clients, our work would have no meaning

      Let’s start Discussion Inquire Now