List of Figures

Chapter 1. Getting to know Redis

Figure 1.1. An example of a STRING, world, stored under a key, hello

Figure 1.2. An example of a LIST with three items under the key, list-key. Note that item can be in the list more than once.

Figure 1.3. An example of a SET with three items under the key, set-key

Figure 1.4. An example of a HASH with two keys/values under the key hash-key

Figure 1.5. An example of a ZSET with two members/scores under the key zset-key

Figure 1.6. Reddit, a site that offers the ability to vote on articles

Figure 1.7. Stack Overflow, a site that offers the ability to vote on questions

Figure 1.8. An example article stored as a HASH for our article voting system

Figure 1.9. Two sorted sets representing time-ordered and score-ordered article indexes

Figure 1.10. Some users who have voted for article 100408

Figure 1.11. What happens to our structures when user 115423 votes for article 100408

Figure 1.12. The newly created ZSET, score:programming, is an intersection of the SET and ZSET. Intersection will only keep members from SETs/ZSETs when the members exist in all of the input SETs/ ZSETs. When intersecting SETs and ZSETs, SETs act as though they have a score of 1, so when intersecting with an aggregate of MAX, we’re only using the scores from the score: input ZSET, because they’re all greater than 1.

Chapter 2. Anatomy of a Redis web application

Figure 2.1. A cached database row for an item to be sold online

Chapter 3. Commands in Redis

Figure 3.1. What happens when calling conn.zinterstore('zset-i', ['zset-1', 'zset-2']); elements that exist in both zset-1 and zset-2 are added together to get zset-i

Figure 3.2. What happens when calling conn.zunionstore('zset-u', ['zset-1', 'zset-2'], aggregate='min'), elements that exist in either zset-1 or zset-2 are combined with the minimum function to get zset-u

Figure 3.3. What happens when calling conn.zunionstore('zset-u2', ['zset-1', 'zset-2', 'set-1']); elements that exist in any of zset-1, zset-2, or set-1 are combined via addition to get zset-u2

Chapter 4. Keeping data safe and ensuring performance

Figure 4.1. An example Redis master/slave replica tree with nine lowest-level slaves and three intermediate replication helper servers

Figure 4.2. Example user inventory and user information. Frank has 43 e-dollars and an item that he’s considering selling from his inventory.

Figure 4.3. Our basic marketplace that includes an ItemA being sold by user 4 for 35 e-dollars

Figure 4.4. list_item(conn, "ItemM", 17, 97)

Figure 4.5. Before the item can be purchased, we must watch the market and the buyer’s information to verify that the item is still available, and that the buyer has enough money.

Figure 4.6. In order to complete the item purchase, we must actually transfer money from the buyer to the seller, and we must remove the item from the market while adding it to the buyer’s inventory.

Chapter 5. Using Redis for application support

Figure 5.1. A HASH that shows the number of web page hits over 5-second time slices around 7:40 a.m. on May 7, 2012

Figure 5.2. A ZSET that shows some known counters

Figure 5.3. Example access time stats for the profile page. Remember that ZSETs are sorted by score, which is why our order seems strange compared to our description.

Chapter 6. Application components in Redis

Figure 6.1. A recent contacts autocomplete showing users with names starting with je

Figure 6.2. The structure of our marketplace from section 4.6. There are four items in the market on the left—ItemA, ItemC, ItemE, and ItemG—with prices 35, 48, 60, and 73, and seller IDs of 4, 7, 2, and 3, respectively. In the middle we have two users, Frank and Bill, and their current funds, with their inventories on the right.

Figure 6.3. Items purchased completed in 60 seconds. This graph has an overall V shape because the system is overloaded, so when we have five listing processes to only one buying process (shown as 5L/1B in the middle samples), the ratio of listed items to bought items is roughly the same ratio, 5 to 1.

Figure 6.4. The number of retries when trying to purchase an item in 60 seconds. There are no retries for either types of locks, so we can’t see the line for “with lock” because it’s hidden behind the line for fine-grained locks.

Figure 6.5. Average latency for a purchase; times are in milliseconds. The maximum latency for either kind of lock is under 14ms, which is why both locking methods are difficult to see and hugging the bottom—our overloaded system without a lock has an average latency of nearly 500ms.

Figure 6.6. Basic semaphore ZSET

Figure 6.7. Fair semaphore owner ZSET

Figure 6.8. Call sequence for acquire_fair_semaphore()

Figure 6.9. A first-in, first-out queue using a LIST

Figure 6.10. A delayed task queue using a ZSET

Figure 6.11. jack451 has some messages from Jill and his mother waiting for him.

Figure 6.12. Some example chat and user data. The chat ZSETs show users and the maximum IDs of messages in that chat that they’ve seen. The seen ZSETs list chat IDs per user, again with the maximum message ID in the given chat that they’ve seen.

Chapter 7. Search-based applications

Figure 7.1. The inverted index for docA and docB

Figure 7.2. The process of tokenizing text into words, then removing stop words, as run on a paragraph from an early version of this section

Figure 7.3. The SET intersection, union, and difference calls as if they were operating on Venn diagrams

Figure 7.4. An example document stored in a HASH

Figure 7.5. The data that’s examined during a union-then-intersect calculation of ad-targeting bonuses includes all ads in the relevant word bonus ZSETs, even ads that don’t meet the location matching requirements.

Figure 7.6. The data that’s examined during an intersect-then-union calculation of ad-targeting bonuses only includes those ads that previously matched, which significantly cuts down on the amount of data that Redis will process.

Chapter 8. Building a simple social network

Figure 8.1. Example user information stored in a HASH

Figure 8.2. Example status message stored in a HASH

Figure 8.3. When someone visits their home timeline on a site like Twitter, they see the most recently posted messages that people they follow have written. This information is stored as a ZSET of status ID/timestamp pairs. Timestamp information provides the sort order, and the status ID shows us what information to pull in a second step.

Figure 8.4. To know who’s following a user, we store user ID/timestamp pairs in a ZSET. The user IDs are the people who’re following that user, and the timestamp is when they started following the user. Similarly, the users that a user is following are stored as a ZSET of user ID/timestamp pairs of the user ID of the person being followed, and the timestamp of when the user followed them.

Chapter 9. Reducing memory use

Figure 9.1. How long LISTs are stored in Redis

Chapter 10. Scaling Redis

Figure 10.1. An example Redis master/slave replica tree with nine lowest-level slaves and three intermediate replication helper servers

Chapter 11. Scripting Redis with Lua

Figure 11.1. First and last shard IDs for sharded LISTs

Figure 11.2. LIST shards with data

Appendix A. Quick and dirty setup

Figure A.1. Redis running in Windows