Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Great Redis Misapprehension: Redis is NOT a Database

DZone's Guide to

The Great Redis Misapprehension: Redis is NOT a Database

· Cloud Zone
Free Resource

Download this eBook outlining the critical components of success for SaaS companies - and the new rules you need to play by.  Brought to you in partnership with NuoDB.

Redis is NOT a database.

It's closer to memcache than mysql, for example. However, it's not a cache either.

This is the biggest point I want to drill in people's heads. For some reason, people seem to think it's a key-value store, or some persistent database, but that's totally not it at all.

I myself thought this, and had a tough time learning why it was useful since that was stuck in my head, so if you've been thinking it's persistent, get that OUT of your head now!

Redis is a data structure server

It's super low level things like lists, sets, and yes, key-value, but that's not the heart of it.

There's no one killer feature of Redis. The best way to learn its value is just to look through the docs at interesting things.

You sort of feel like a toddler playing building blocks, but these building blocks are freaking awesome.

It has some persistence support, but does not appear to be super durable. If you're thinking of using like that though, you're misunderstanding the tool.

EDIT: This comment on persistence has been met with much criticism from the community, so I will add to this: Redis can be configured to be a durable store. It is out of scope for this article, but the docs describe possible configurations very clearly: http://redis.io/topics/persistence

The following is 3 example use-cases for Redis

Leaderboards

If you're designing a leaderboard, you need to be using Redis. One of the few data types it supports is called 'sorted sets' and honestly, they should've just called the damn things 'leaderboards'.

It's pathetically easy to use. Say we're building Tetris, and we want to show a high score table.

Each time a user gets a score, use ZADD to add their score to the system:

ZADD highscores 1337 dickeytk
ZADD highscores 100 whatgoodisaroad

Now let's get the top 5 players using ZRANGEBYSCORE:

ZRANGEBYSCORE highscores -inf +inf WITHSCORES LIMIT 0 5

I don't even need to explain that. It's fast enough for you, in case you're a worry wort.

Check the docs for more information on sorted sets.

Queue

You can do some super simple queuing things with Redis. I mean dead simple too, literally one line of code in almost every programming language I would say.

It works just like you would expect.

Put something at the end of the queue:

RPUSH my_list 6

 (RPUSH means 'push data onto the right side of the list')

Grab the next thing from the beginning of the list:

LPOP my_list

 (LPOP means 'pop data from the left side of the list')

A common issue in web development though, is that your queue may not have anything in it! In which case it is often helpful to maybe do something like this:

data = None
while not data:
    data = redis.('LPOP', 'mylist')

 Just loop until you get your data. However, there's a better way, using BLPOP. BLPOP is just a blocking version of LPOP:

data = redis.('BLPOP', 'mylist')

 

Which just blocks until it returns! Marinate on just how useful that is for a second.

A caching example!

EDIT: The community was very upset about this section in my post. I still maintain that it is a perfectly acceptable way to handle cache invalidation, however, if you are implementing this in a production system, you definitely need to read http://redis.io/commands/keys thoroughly. Still though, even if this isn't preferable for performance reasons, it's pretty cool!

Redis is pretty much a drop-in replacement for memcache. If you've used memcache, you probably have a caching pattern using keys like this:

post/83/body

or

post/83

or maybe like this

article:28:related_tags

 Basically, you're namespacing the tags so they don't conflict. Good on you for that! Now, as you've probably noticed, invalidation is no easy task, since in memcache, you can delete

post/83

but that won't delete

post/83/body

 since it's just a string, memcache doesn't parse anything.

Now, this is where Redis comes in. You can find keys on wildcards! So you can just query it like so:

keys post/83*

And that will return all the keys you need to invalidate!

As tabbyjabby on ycombinator mentioned that Antirez (one of the creators of Redis) wrote a very good article on many of the same things I have discussed here: http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

Source: http://jeffdickey.info/the-great-redis-misapprehension

Learn how moving from a traditional, on-premises delivery model to a cloud-based, software-as-a-service (SaaS) strategy is a high-stakes, bet-the-company game for independent software vendors. Brought to you in partnership with NuoDB.

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}