PPL 30 Day 1: Redis
This is part of the Peer Pressure Learning 30 series. To learn more about what in the hell that means, see the intro to the series, A Good Time To Learn.
Today I learned as much as I could about Redis, a member of the growing NoSQL genre of data stores.
Installation
I love homebrew.
brew install redis
Resources I Used
Twitter Clone in PHP
Downloaded retwis-0.3. Followed along with the guide to Retwis here. I found this a bit difficult to wade through, ultimately.
EngineYard Redis Intro
A good overview from EngineYard called To Redis or Not to Redis. This one is easy to follow, but isn’t a very deep pool.
Using Key Value Stores from Ruby by James Edward Gray II
The Redis series of Gray II’s Using Key Value Stores from Ruby is more in depth than the EngineYard series, but is still easy to understand. I’m glad I took some extra time to read through it.
What I Think I Now Know
Redis is super-fast, as data is held in memory. (And even then, some reports I In addition to simple strings as value types, it also has sets and lists, upon which operations are atomic. Those two things are great! The operations that can be performed on sets and lists are numerous. Everything else is a string. Compared to the ‘data model’ that I know I’ll encounter when I check out Cassandra, Redis is very straightforward, with just enough extra to be really powerful.
The downside is that it doesn’t have the most mature scaling facilities, though some client libraries make up for this. It’s also risky; though data is dumped to disk periodically (this circumstance is configurable), data is primarily held in RAM. A failure could cause some data loss.
Also, having messed around with it a bit, Ezra’s redis-db makes working with Redis in Ruby pretty simple.
It seems to me, and Gray II definitely agrees, that Redis would be great as a combination of Memcached replacement and user-tracking data store. It has advantages over Memcached in speed ( check out this benchmark comparison ), data types, and that it will persist to disk (eventually).
I could definitely see using this in the near future.