This graphic outlines our basic scenario of a simple two-product online storefront from which we will construct our Redis schema.

Imagine that you have an online storefront selling paper products and you want to manage different stationary products that are offered for sale. Embedded within this seemingly simple business need, the following narrative starts with these separate steps:

Redis's rich ecosystem offers a number of object mappers for Redis that hide the key naming management from the designer and the user while offering, through client-side code, a functionality that may be present in other data storage technologies. Examining how a Redis object mapper implements this functionality with a particular pattern of keys and data structures can help you learn about existing patterns and allow you to extend and improve your own Redis-based applications. Using a Redis object mapper can also be helpful if you do not want to re-implement a functionality that may already exist and run it in production environments in your code base. A few of the more popular programming languages have these object mapper projects that all provide ways to persist object semantics and data in Redis while offering more object-oriented methodologies and techniques for the developer who may be more familiar with these techniques and ideas in their...

As you may already know and fully appreciate, Salvatore Sanfilippo intentionally documents the worst-case algorithmic performance of each Redis command on Redis's website at http://redis.io/commands/. This focus on an algorithmic measure of performance as a core actionable metric differentiates Redis from the other data storage technologies. A mathematical definition of Big O is that it "symbolically expresses the asymptotic behavior of a given function.2. Within computer science and more pertinent to our understanding of the big O notation within Redis, with this notation and understanding, we can classify the performance of a Redis command by how the commands perform with increasing inputs to the command over time.

Graphing Big O Notation

In the Redis documentation for each command, the time complexity of each Redis command is given in these big O cases:

With this understanding of the computing big notation, we'll next briefly review Redis's basic data structures, paying attention to the time complexity implications of using the data structure with the current commands supported by Redis.

In Redis, the sorted-set data type combines the characteristics of both Redis lists and sets. Similarly to those of a Redis list, a sorted set's values are ordered, and like a set, each value is assured to be unique. Of all the various data structures in Redis, the sorted set is the closest to a killer feature. The flexibility of a sorted set allows for multiple types of access patterns depending on the needs of the application. Using a single sorted set for a player's scores in a game both the top and the bottom players are easily fetched for a leaderboard by either the ZRANGE or ZREVRANGE Redis commands.

For sorted sets, the ZADD command adds a member with a score to the sorted set. The time complexity of ZADD is O(log(n)), meaning that as the size of the sorted set increases, the rate of increase in the processing time is a constant. Therefore, the difference between adding a new member to a large sorted set is trivial; the difference between log(10000) ~ 9.21034037...

Similarly to sets, sorted sets in Redis support the set operations of union and intersection, although the time complexity of these operations for sorted sets is worse than for sets. Another problem with the sorted set operations is that when using a Redis cluster, union and intersection operations can only be used when the sorted set keys have been sharded to the same hash slot and run on the same node. The ZINTERSTORE Redis command has a time complexity of O(nk)+O(mlog(m)), where n is the size of the smallest sorted set; k, the total number of sorted sets being intersected, and m, the number of elements in the resulting final sorted set. Likewise, for the ZUNIONSTORE command, the time complexity is O(n)+O(M log(M)) with n being the total size of all the sorted sets and m being the total number of elements in the final sorted set. Given the characteristics of sorted sets, the additional time required for these two set operations may be an acceptable trade...