Redis Redux

I for one welcome our new NoSQL overlords!

At Scalr, we’ve been following Redis for some time, loving its data model (a key-value store with a bit more structure than memcached), its speed (it’s a bloody fast in-memory database), and have been planning on using it internally to complement our usage of MySQL.

WHY YOU SHOULD USE REDIS

Redis is great for the following web use cases (taken from my friend Todd’s excellent blog at HighScalability, more details here):

• Latest items in a Craigslist or eBay clone
• Leaderboards or Digg & Reddit style voting sites
• Counters and Rate Limiting like number of API calls per client per month
• Stats tracking, like unique pageviews
• Pub/Sub, like Amazon SNS (topic-based message filtering, although content-based filtering can be achieved in your app)
• Message queues, like Amazon SQS
• Caching html fragments, like you would do with memcached

HOW REDIS WORKS

Persistence. As an in-memory database, Redis holds the whole dataset in RAM. Since RAM is volatile (a power down or crash results in total loss of all memory data), Redis offers two persistence models: Snapshotting (a semi-persistent durability mode where the dataset is asynchronously transferred from memory to disk from time to time), and Append-only (a file or journal that is written as operations modifying the dataset in memory are processed, which allows Redis to rewrite the append-only file in the background in order to avoid an indefinite growth of the journal).

Scaling. Scaling Redis can be done through replication (read scaling) and sharding (write scaling). Pretty much the same as MySQL.

Replication. For those of you thinking about read scaling or data redundancy, Redis supports master-slave replication. Data from any Redis server can replicate to any number of slaves; a slave may even be a master to another slave, for example (aka cascading replication, or a single-rooted replication tree). Worthy of note is that Redis slaves are writable, permitting intentional and unintentional inconsistency between instances.

Sound good? Well we have good news for you then! Redis is now available as its own automatically replicated, automatically backed up, automatically persisted, and automatically monitored role in Scalr.

Sharding. Sharding with Redis isn’t done on the (Redis) server side, but rather on the client side, next to your code running on your web server, with a client library that performs consistent hashing. That is, every request’s key is hashed, and the hash determines where to find or put some data. The hashing needs to be consistent, so the same key always gets hashed to the same location. More on consistent hashing.

SCREENSHOTS

Redis status: replication, backups, and more

Redis settings: backup schedule, persistence method, storage engine, and more

Check Redis' status from the Options menu

Create a Redis role (image) on any cloud with the Role Builder

**Special thanks to VMware for sponsoring development of this great project.**