Welcome to another post in our key value series! This week, Redis! Redis is a persistent in-memory key-value store written in C by Salvatore Sanfilippo. It's currently in version 1.0. So let's get down to it, "To Redis or Not to Redis?" that's the question...
So, let's say you have a situation where...
- You want a key-value store that's blazingly fast
- Your data set is small enough that it can fit in available RAM
- It's OK if some recently updated records are lost in a catastrophic failure
- Your life would be a lot easier if it was cheap and easy to do set and list operations atomically
If this describes your situation, you should take a serious look at Redis. It provides a very fast store in part because it keeps the data set in memory. It handles persistence by asynchronously writing changes after a configurable number of seconds or number of updates have occurred, which means that if the Redis server goes down unexpectedly, it is possible to lose some records. (Redis does offer a master-slave replication mode which mitigates this risk, though). Finally, Redis provides storage for data structures other than strings.
With Redis, a value can also be a list or a set, and Redis provides atomic operations for manipulating those values. This feature eliminates the need for a lot of potentially troublesome locking antics if you need to maintain consistent lists or sets that are manipulated by multiple clients at the same time.
Furthermore, while Redis doesn't inherently support a sharded, horizontally scalable architecture like Cassandra does, some Redis clients, including the Ruby one (by our own Ezra Zygmuntowicz), support consistent hashing and distribution of data across multiple servers. So, at least when using a client library that supports it, like the Ruby library does, Redis offers a compelling combination of performance with scalability.
After you've installed Redis and started up an instance of
redis-server, you're ready to use it. If you haven't already, grab Ezra's redis-rb library and install it.
Functionally, this is a lot more like what you're probably used to when thinking about a key-value store, (versus what you saw with Cassandra's data storage model). Redis does have a concept of multiple databases, where each database is a separate key-value namespace, but Redis keeps it simple. Databases are numbered simply, starting with 0, and if you don't tell Redis which database you want to use, it assumes you are using database 0.
Redis supports several atomic operations on the data in a database, including moving data from one database to another, as well as incrementing and decrementing values.
Notice a few things in the above example: first of all, Redis value data types are either strings, lists, or sets. So, when a numeric 1 was assigned as the value for a key, the client actually stored the
to_s version of that value,
Second, notice that you don't need to initialize a counter before using it. If you reference a key in an increment or decrement operation that doesn't exist, it will be automatically vivified for you. Finally, as mentioned just a moment ago, numbers don't appear anywhere in the list of Redis data types, so the increment/decrement operations work on a simple principle—try to interpret the value as a long, and then work with whatever you get. So, be careful not to increment or decrement a key that has non-numeric data in it. Rather than throwing some sort of exception, Redis will happily attempt to do what you are asking, and clobber your data along the way.
Dealing with a really fast, straightforward key-value store with atomic increment/decrement is pretty useful in itself, but Redis really starts to shine when you look at what can be done with list and set operations. Let's say that you want to keep an audit log of of client sessions in your application. You might start with something like this: audit_log.rb
Sets in Redis are also easy to work with. Just like everything else, there's no special preparation necessary. You just open up the Redis database and start using them. Imagine that you are creating the world's next great dating site. You allow people to enter lists of keywords to describe themselves, and then you use the intersection of these keywords to help determine how well two people match each other. date_keywords.rb
It works like a charm. Given a long list values in the set, Redis intersected them for us. Using that algorithm, though, it doesn't look like those two people have a lot in common. Unless opposites really do attract, maybe they should keep looking. Because this was all atomic, it works in the typical web scenario where there can be multiple processes simultaneously inserting, removing, and intersecting data. No need to worry about locking.
The joy of using Redis is that it's simple to use, but there's considerable depth to the API. It's likely that any string, list or set value operation you can think of is there already. Keys can have TTL values, so that they time out of the data store. You can get and set in one operation. You can increment or decrement by more than one. You can pull random keys, or rename keys, or get the db size. You can push, pop, get ranges, etc... from lists, and do any set operation imaginable on sets. Complex sorting is supported. And there's a lot more than that. The API really has impressive depth.
Given all of this, we come back to the title of this article - To Redis or Not to Redis. As an alternative, Tokyo Cabinet is very fast for a synchronous key value store, and it does support some features that Redis does not, such as tables. Redis permits a master/slave setup, which can alleviate fears of data loss from failure, but it's not as certain as something like Tokyo Cabinet, which will write the data as soon as it gets it. On the other hand, Redis is blazingly fast, incredibly easy to use, and will support just about anything you can think of doing with your data.
If you have a large data set that cannot comfortably fit into RAM, Redis is not the key value store for you to use, but if you have smaller sets, and if you can live with the asynchronous write behavior, then, for me, the answer is definitely "to Redis."