Redis is a great little tool for storing little bits of information that you want to keep around but don’t care that much about. It is a basic key-value store, but it does things like hashes, sets, sorted sets, lists, and message streams. There is also basic master/slave replication available. There are also things it does not have: security, durability (in standard mode), consistency, atomicity, online-backups, or real transactions. It keeps all its data in memory, although there is a feature that allows you to basic page or swap, but it is still not recommended to use it to store larger datasets than available memory. It is also a single-process, so no locks, but no use of the multi-processor, multi-core architecture common in many systems.
Installing and building Redis
Although I have used Redis on both Linux and Windows, I’ll just talk about using it on Windows since there’s already enough material on using with Linux. To get started, I simply downloaded the source from Google code and extract to whatever directory you want to use. It is made for Posix-complaint systems, and since Windows is not such a system, I used Cygwin to emulate Linux just because that’s what I have the most experience with. You just use make and gcc, and viola, you have a redis-server.exe. You can just copy that and the cygwin.dll and you have yourself a build.
To configure redis, you just modify the redis.conf file. There are some basic things to configure: where to put the log, how often to save, which port to use, whether you want this instance to be slave of another, and a password if you want security.
Start the exe, and you have yourself a server. I used telnet to play around with it at first, and the protocol is really simple:
*n CR LF (where n is the number of statements you’re sending)
$n CR LF (where n is the number of characters you’re going to send next)
You can also just send things like:
SET foo bar
I wrote a basic proof and then sent it off to a co-worker who was writing benchmarking software for a performance comparison suite. We did some tests, and decided that Redis would be the solution for a many read, single write, single key access pattern.
After a couple months, I wrote my own and implemented a basic program that saved users and tasks (a little to-do software that I want to write later on). I also implemented Oracle with this tool, and so I was able to run some comparisons. The difference was clear, but understandable given that Redis doesn’t store the data immediately, but instead waits to flush it in bulk.
Writing the actual implementation took a little less time than in SQL using Oracle’s JDBC connector and Jedis, a Redis-client, but with Redis you just point your application to a database and shoot. No preparation is required. I didn’t ever use the nifty lists, sets, and hashes features of Redis, but they are definitely cool. I would recommend Redis for when you have data that is neatly accessible by one field, it is okay if you lose data, and if your schema is simple or does not need to be understood by the database. Using tools like this is extremely helpful when you need them, but don’t try to force your application into a NoSQL box, just because all the cool kids are doing it.
As a side note, Berkeley DB has been doing this for forever but it does not come with server bindings. I doubt Redis would be an option if this was the case, as the risk of a new product is pretty high. Two other fresh faces in the DB world, MongoDB and CouchDB, are notorious for losing data, and Mongo’s solution to this problem is to maintain another replica of the data, even though the second replica can also be lost if for instance the data was maliciously erased. Redis does not guarantee that a value saved is a value written, and there are no tools for a corrupt snapshot. Final lesson: know how your DB works, and be careful when getting a new babysitter for your precious data.