(If you haven’t read Part 1 yet, please do so before continuing.)

A list is an ordered collection of values. Think of it like an array in your favorite programming language. You can insert values at the beginning (left) and end (right) of the list, retrieve single and ranges of elements, and delete elements.

To follow along with these examples, start the Redis server and then connect with telnet, just like we did in part 1.

Inserting Elements

Let’s create a new list:

    % LPUSH vowels 1
    % a
    +OK

Inserting an element is called pushing. Because the key vowels doesn’t exist yet, a new list is created with a single value, a. Let’s add two more values to the list, this time at the end:

    % RPUSH vowels 1
    % e
    +OK

    % RPUSH vowels 1
    % i
    +OK

We’ve pushed three values into our list; let’s make sure Redis agrees.

    % LLEN vowels
    :3

Now that we have some values in the list, how do we get them back out?

Retrieving Elements

Redis has a few commands for retrieving list elements; which command to use depends on how many elements we wish to retrieve.

We can get a single value back with the LINDEX command. Lists in Redis are zero-based, so the first element of a list has index 0, the second has index 1, and so on. So far our list has values a, e, and i. Let’s get each by its index.

    % LINDEX vowels 0
    $1
    a

    % LINDEX vowels 1
    $1
    e

    % LINDEX vowels 2
    $1
    i

If we try to get the value at an index that doesn’t exists, Redis returns a null value.

    % LINDEX vowels 3
    $-1

Suppose we want the last (right-most) value in the list, but we don’t know how long it is. Using a negative index, we can get elements starting at the end of the list:

    % LINDEX vowels -1
    $1
    i

    % LINDEX vowels -2
    $1
    e

We can retrieve more than one value using the LRANGE command, which takes three arguments: the key, the start index, and the end index. To get the first two elements in the list:

    % LRANGE vowels 0 1
    *2
    $1
    a
    $1
    e

(The first line reads *2, which means two elements are being returned.)

LRANGE accepts negative indices, just like LINDEX. Let’s get all the elements in the list:

    % LRANGE vowels 0 -1
    *3
    $1
    a
    $1
    e
    $1
    i

By making both indices negative, we can get the last two values out of the list:

    % LRANGE vowels -2 -1
    *2
    $1
    e
    $1
    i

Deleting Elements

Suppose we executed a few more commands and now vowels looks like this: y, j, u, x, o, j, a, e, i, x, j, j. Let’s clean it up by removing the extra elements.

First, let’s delete the y at index 0. One way is to use the LPOP command. LPOP removes and returns the first element of the list:

    % LPOP vowels
    $1
    y

We can also RPOP, which does the same thing to the last element of the list.

Another option is to trim the list to a smaller version of itself. We can do this with the LTRIM command. LTRIM works exactly like LRANGE except instead of returning the range Redis overwrites the key with it:

    % LTRIM vowels 1 -1
    +OK

This command sets vowels to be the range starting at index 1 and ending at the last element. vowels now contains these elements: u, x, o, j, a, e, i, x, j, j.

Let’s get rid of those js using the LREM command. LREM takes three arguments: a key to operate on, the number of matching elements to remove, and the value to remove¹.

Let’s remove the first j:

    % LREM vowels 1 1
    % j
    :1

The first 1 tells Redis to start searching at the first element and to remove one instance of j. (The second 1 is the size in bytes of the value for which to search.) Redis responds with :1, the number of elements removed.

Let’s remove two more js, this time from the end of the list:

    % LREM vowels -2 1
    % j
    :2

The -2 tells Redis to remove two elements and, because of the negative sign, to search starting at the end of the list. Two elements have been removed, so Redis says :2.

Now our list is u, x, o, a, e, i, x. Let’s remove all of the xs in one go:

    % LREM vowels 0 1
    % x
    :2

By sending 0 as the second argument we’re telling Redis to remove all x elements.

Sorting

We have a complete list of vowels–u, o, a, e, i–but they’re in the wrong order. Let’s get a sorted list of vowels:

    % SORT vowels ALPHA
    *5
    $1
    a
    $1
    e
    $1
    i
    $1
    o
    $1
    u

SORT is a powerful command with many options and we’ll cover it later in greater detail. For now, here are a couple more things you can do with SORT.

Sort in the opposite direction:

    % SORT vowels ALPHA DESC
    *5
    $1
    u
    $1
    o
    $1
    i
    $1
    e
    $1
    a

Limit the returned list to 3 elements, starting at index 1:

    % SORT vowels LIMIT 1 3 ALPHA
    *3
    $1
    e
    $1
    i
    $1
    o

So far, we’ve only had a taste of why Redis is so exciting. Next time we’ll look at sets and things will really pick up.

1. Redis can’t remove an element by index. There will always be a delay between when a command is sent and executed–during that delay, the list could be modified by another client and the index would then reference the wrong element.

I’ll start with setup and basic commands; continue with lists, sets, and some fancier stuff like key expiration; and finish with a simple Ruby application that will demonstrate the covered topics.

Redis is the coolest bit of software I’ve seen in ages and I hope this series helps to spread the word and get more people to try it.

What Is Redis?

Redis is a key-value database. Unlike a relational database, which is comprised of tables containing columns of data definitions and rows of data, a key-value database stores values, each of which is referenced by a unique key. To get a value out of the database, we send the corresponding key. It’s a little like the hash, associative array, or dictionary data type in your favorite programming language.

Redis has several features that make it unique among key-value database projects:

• It stores strings, yes, but also lists and sets, so it’s flexible.
• It loads the entire dataset into RAM, so it’s fast.
• It writes the database to disk, so it’s persistent.
• It supports master-slave replication, so it’s scalable.
• It’s easy to run, so you aren’t endlessly futzing with mammoth config files
• Maybe most important, it’s easy to use, so you spend less time working with the database and more time writing your application.

I’ll cover each of these topics in greater depth as we go. Right now, let’s install it and start playing.

Setup

Redis is cake to build¹. Observe:

    % curl -O http://redis.googlecode.com/files/redis-1.02.tar.gz
    % tar xzf redis-1.02.tar.gz
    % cd redis-1.02
    % make

The redis-server binary is in the current working directory; we can run it directly, copy to /usr/local/bin, or whatever.

To start Redis:

    % redis-server

Redis is now available on localhost at port 6379. In a real application, we would interact with Redis via a client library for our language of choice. For now, we’ll just use telnet.

Open a new shell and run:

    % telnet 127.0.0.1 6379

We’re now connected to Redis; let’s send it some commands.

Basic Commands

Here’s our first command (I will prefix commands with % but you won’t see an actual prompt):

    % DBSIZE
    :0

DBSIZE returns the number of keys in the database. This is a new database with no keys, so Redis says :0.

The database is empty, but let’s try to GET a value:

    % GET hello
    $-1

GET fetches the value at the provided key. The key hello doesn’t exist, so Redis says $-1, which is like nil or null. Let’s set a value for that key:

    % SET hello 5
    % world
    +OK

SET takes three parameters: the name of the key, the size of the value in bytes, and, after a newline, the value itself. Here, we SET the key hello to the 5-byte value world, and Redis says +OK. Now if we GET again:

    % GET hello
    $5
    world

We receive the value we just set, but with an extra line that reads $5. Just like with SET, the size of the value in bytes is returned first, then a newline, then the value.

We can ask Redis if a key exists:

    % EXISTS bigkahuna
    :0

    % EXISTS hello
    :1

Here, :0 and :1 mean false and true, respectively.

Let’s delete the hello key:

    % DEL hello
    :1

DEL deletes the value stored at the key hello. The command succeeds and Redis says :1, the number of records deleted. We can delete multiple keys by separating them with a space.

Say we want to set the value of a key only if that key doesn’t exist. Enter SETNX:

    % SETNX bigkahuna 22
    % that is a tasty burger
    :1

    % GET bigkahuna
    $22
    that's a tasty burger

    % SETNX bigkahuna 4
    % d'oh
    :0

    % GET bigkahuna
    $22
    that's a tasty burger

The second SETNX fails because the key bigkahuna, having been created by the first SETNX, now exists.

Let’s create a few more keys: english, englash, and englosh. Set the value to whatever you want, remembering to enter the number of bytes and a newline first, then the value.

Redis returns data only if we feed it a valid key–it’s impossible to search for some value and get back its key. Suppose we don’t know what keys are in the database. How do we figure it out?

The KEYS command searches all the keys for the provided pattern. Let’s get a list of every key in the database:

    % KEYS *
    $33
    englosh englash english bigkahuna

The pattern can include globs:

    % KEYS *a*
    $17
    englash bigkahuna

    % KEYS engl?sh
    $23
    englosh englash english

    % KEYS engl[ia]sh
    $15
    englash english

Finally, we can purge all of the keys from the database:

    % FLUSHDB
    +OK

    % DBSIZE
    :0

Increment & Decrement

Redis lets us increment and decrement our values. First, let’s create a counter and set it to 1:

    % SET counter 1
    % 1
    +OK

To increment:

    % INCR counter
    :2

To decrement:

    % DECR counter
    :1

Nothing to it, right? We can also increment and decrement by values other than one:

    % INCRBY counter 5
    :6

    % DECRBY counter 6
    :0

Why do the increment and decrement commands exist? Say we’re using Redis to track the pageviews for a web site. Every URL maps to a key whose value is a counter. When a user visits a URL, we increment the counter. Imagine two visitors, v1 and v2, visit the same URL, /about, at the same time. Here’s how it might play out in pseudocode, using only the GET and SET commands:

    redis.get("/about") == 5      # 5 visits so far
    v1 = redis.get("/about")      # visitor 1 grabs the count
    v2 = redis.get("/about")      # visitor 2 grabs the count
    redis.set("/about", v1 + 1)   # visitor 1 sets the count + 1
    redis.set("/about", v2 + 1)   # visitor 2 sets the count + 1
    redis.get("/about") == 6      # wha?? should be 7

The problem is clear: v2 changed the counter after v1 retrieved the value but before setting the new one. The increment and decrement commands prevent this problem because they’re atomic: reading the value and changing it occur in one motion and can’t be interrupted.

We can close both Redis and our telnet session by sending the SHUTDOWN command:

    % SHUTDOWN
    Connection closed by foreign host.

And that’s it for part 1. Already, we know enough commands to build a real application, but Redis has much more to offer–next time, we’ll explore lists.

1. Mac OS X users must install the Developer Tools. Windows users should get along just fine using Cygwin. Linux/UNIX users shouldn’t need my help. ↩

1. Create tasks in a task manager.
2. Meticulously sort them by project and priority.
3. Select some of them as today’s tasks.

There’s a massive industry built around this method, and for good reason: it sounds nice and makes sense. Define your tasks, then do them. Write a blog article, fix the toilet, buy groceries, code the products page.

But I never get anything done this way. Tasks seem easy when I read them, so I schedule too many at a time. After work, only a handful are checked off, sometimes none. I feel unproductive and lousy :(

The thing about tasks is they’re reminders, abstractions that communicate what to do, not how or how long. I write down “code the product pages” so I don’t forget to do it. I may need to do twelve other things to code the page, but I don’t write those down because they tell me how to do it, and I already know that. If I don’t know how to do something, I probably shouldn’t be doing it in the first place. I just need a little reminder.

Task-based schedules fail precisely because they’re abstractions—they represent a large jobs that requires significant and uncertain effort. With this kind of schedule, the task is the basic unit of work. Productivity is determined by the number of completed tasks. I might estimate three hours to code the products page, but after starting I discover an issue that balloons the time to seven hours. My schedule is blown, I check off one task instead of however-many-scheduled, and I feel bad, despite working those extra for hours on something productive and necessary.

The reader who loves his task manager is shouting that I’m doing it wrong: my tasks are too big and I should break them down into sub-tasks. Kay. To code the products page, I must generate the model and controller, write tests, code the views, test in several browsers. Aren’t those instructions? I don’t need instructions because I know how to do the damn thing. Tasks are reminders, remember? Breaking down the original task only creates extra work and more to manage. Plus it does nothing to address the unexpected work which caused the extra time.

The real solution is to stop scheduling tasks and start scheduling time. Make time the basic unit of work. Seconds, minutes, hours, whatever. Instead of saying “what tasks can I complete today,” say “what can I get done in 60 minutes?”

Here’s how I work now:

1. Commit to working a fixed block of time, usually two or three hours.
2. Set a timer and keep it visible on the screen.
3. Work until the timer runs out, then stop.

The only goal is to work for a set amount of time. I usually do two or three of these sessions per day, and as long as I spend the entire time working, I’ve succeeded. Tasks are no longer metrics for success and productivity, they’re back to being reminders. If I finish a task before the timer is done, then I say “yay!” and start the next one. More important, if I don’t finish a task when the timer ends, no biggie, I feel good anyway because I met my goal. Bonus: no matter how frustrating my work is, I can look at the timer tick-tocking to zero and know that soon I can do something else, and the harder I work the faster the time will go.

The result is I get far more done than I ever did by managing tasks. Because I don’t define my tasks upfront, I can reflect on all the little things I finished instead of feeling bad about the big things still incomplete. That’s a big morale boost and it energizes me to dive in to the next session, something I rarely experienced with my task-based workflow.