Sep 7, 2022

An introduction to Redis®

Take a look at all the ins and outs of Redis, and where it sits on the data continuum.

Redis®* is an in-memory, single-threaded, open-source, NoSQL datastore.

Imagine you’re implementing a leaderboard (top 10 players list) in one part of your game’s UI. You need a solution that smoothly handles user-visible updates on the fly. You also need to write a user session cache to handle the “sticky” login state of users connecting to different authentication services. In yet another part of your Microservices Architecture, you need to temporarily store player-level state.

This requires a simple data store that’s extremely fast, lightweight, relatively format-agnostic, and leverages RAM.

You may be familiar with NoSQL data stores and the flexibility they introduce when compared to an RDBMS. ACID-compliant database solutions in the cloud, best suited for transactional data, ensure record completeness and isolation, but impose a few different costs:

Inflexible schemas: your events must adhere to the same schema as the database, or else throw an error
Write-time, partition, replication, and latency costs.

This simply won’t scale to a large-scale game or social network, where each of several million users needs a list or unique session data updated essentially in real-time.

Think of constantly-updating lists, counters and views on popular social media, games, shared computing and collaboration platforms. Consider the constantly-changing data on Facebook statuses, top Twitter trends and LinkedIn Profile View counts.

Or consider the results counters on search engines: would something like Google results counters really work almost instantaneously for billions of users if rigid transactional mechanisms wrote and read ACID- consistent data over latent network connections for each and every user?

Fortunately, there is an open-source solution purpose-build for precisely such use cases - Redis.

In this post, we’ll look at how an in-memory key-value store (and more) handles data, the use cases it supports and how it supports them via the available Redis data types.

What is Redis?

Redis, or Remote Dictionary Server, is an in-memory, single threaded, open-source NoSQL datastore. Its high performance makes it a favorite fast data store, cache, and even lightweight message broker.

Dubbed “the data structure server” by Redis folks themselves, the value part of the key-value pair can hold strings, lists, sets, sorted sets, hashes, bitmaps, and hyperloglogs, which we’ll cover below. It’s the range of operations that these data types support that makes Redis a flexible and easy choice to spin up on-the-fly solutions for which a relational datastore would be overkill.

With these features, Redis can accommodate a range of problems that map almost directly onto Redis’ data types themselves. But you don’t need to switch to Redis; most use it as a complement to other data stores in their architectures.

What Redis does (and doesn’t do)

You can think of Redis as an out-of-the-box cache where you can store and recall data on the fly. Redis can do more than 100k SETs (writes) and 81k GETs (reads) per second. And with frequent — and configurable — disk writes on the off-cycles, your persisted data is still available when you reinitialize.

Some programming language libraries - think of Ruby’s resque and sidekiq libraries - even use Redis lists under the hood to implement background jobs for fast data sorts.

Unlike SQL databases, Redis doesn’t implement ACID-supporting database schemas such as tables and columns. Instead, the storage format is {key}. Being memory-resident, single threaded, and written in a low level language as C, it’s an excellent choice for fast changing stores and caches.

So how do Redis’s supported data types enable this super-fast execution? Redis users create data structures on the fly and run operations directly on them.

Keys are items which are used to uniquely identify and search for the items (values) associated with them. Since keys are binary safe, they can be human-readable text or even binary strings, just as JPEG files.

Redis value types include the following:

Strings are the simplest values one can associate with a key. Strings are good for storing anything you might think of as plaintext, like code fragments, complete HTML pages, or IP addresses. Redis allows up to a 512MB size for strings.
Lists are collections of strings or linked lists in order of insertion. Lists can contain duplicate values, and you can add items to either the beginning or end.
Sets are like lists, except they cannot contain duplicate values, and are unsorted. Sets can make use of unions, intersections and subtractions. Because they only accept unique, distinct values, they are the go-to for managing cardinality.
Sorted sets are sets where every string is ordered by a float score. In sorted sets, scores can repeat but their associated values cannot.
Hashes are maps of value-associated fields representing distinct objects. Hashes can hold up to 4 billion fields. As such, hashes offer an efficient way for a single Redis instance to hold a very large number of objects and operate on them.
Bit arrays and bitmaps are handled like strings: you can set and clear individual bits, find the first set (or unset) bit, or count all bits set to a specific binary value, among other things.
HyperLogLog or HLL is unique to Redis: "a probabilistic data structure used to estimate the cardinality of a set." HLLs themselves contain only state information and employ algorithms to consume a constant amount of memory (12k at worst) instead of an amount of memory proportional to the numbers of items counted. HLLs read and write their input data from strings, so you’d use string operations for adding, retrieving and counting items from their cardinality calculations.
Streams with a type of pub/sub pattern can be used as part of a mechanism to channel non-critical items to consumers or groups. You can implement new data types or support external modules to enhance Redis’ functionality.

Getting started

Why not give Redis a spin? Aiven for Caching is easy to set up, either on the Aiven Console.

Wrapping up

In this post, we've looked at Redis: how it handles data, the use cases it supports, and how it supports them. And we’ve gotten started with Aiven for Caching from both Aiven Console and Aiven CLI.

If you’d like try out, risk-free hosted and managed Aiven for Caching yourself, check it out with our no commitment, 30-day trial, or read all about it on the product page! In the meantime, subscribe to our blog and changelog RSS feeds, or follow us on Twitter and LinkedIn to be in the know.

References

Redis in Action

https://redis.io/topics/data-types-intro

http://oldblog.antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

http://highscalability.com/blog/2011/7/6/11-common-web-use-cases-solved-in-redis.html

* Redis is a trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Aiven is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Aiven Oy.

Related resources

What is Redis?

What Redis does (and doesn’t do)

Some programming language libraries - think of Ruby’s resque and sidekiq libraries - even use Redis lists under the hood to implement background jobs for fast data sorts.

So how do Redis’s supported data types enable this super-fast execution? Redis users create data structures on the fly and run operations directly on them.

Redis value types include the following:

Strings are the simplest values one can associate with a key. Strings are good for storing anything you might think of as plaintext, like code fragments, complete HTML pages, or IP addresses. Redis allows up to a 512MB size for strings.

Lists are collections of strings or linked lists in order of insertion. Lists can contain duplicate values, and you can add items to either the beginning or end.

Sets are like lists, except they cannot contain duplicate values, and are unsorted. Sets can make use of unions, intersections and subtractions. Because they only accept unique, distinct values, they are the go-to for managing cardinality.

Sorted sets are sets where every string is ordered by a float score. In sorted sets, scores can repeat but their associated values cannot.

Hashes are maps of value-associated fields representing distinct objects. Hashes can hold up to 4 billion fields. As such, hashes offer an efficient way for a single Redis instance to hold a very large number of objects and operate on them.

Bit arrays and bitmaps are handled like strings: you can set and clear individual bits, find the first set (or unset) bit, or count all bits set to a specific binary value, among other things.

HyperLogLog or HLL is unique to Redis: "a probabilistic data structure used to estimate the cardinality of a set." HLLs themselves contain only state information and employ algorithms to consume a constant amount of memory (12k at worst) instead of an amount of memory proportional to the numbers of items counted. HLLs read and write their input data from strings, so you’d use string operations for adding, retrieving and counting items from their cardinality calculations.

Streams with a type of pub/sub pattern can be used as part of a mechanism to channel non-critical items to consumers or groups. You can implement new data types or support external modules to enhance Redis’ functionality.

Wrapping up

In this post, we've looked at Redis: how it handles data, the use cases it supports, and how it supports them. And we’ve gotten started with Aiven for Caching from both Aiven Console and Aiven CLI.

An introduction to Redis®

What is Redis?

What Redis does (and doesn’t do)

Getting started

Wrapping up

References

Further reading

Stay updated with Aiven

Related resources

What is Redis?

What Redis does (and doesn’t do)

Getting started

Wrapping up

References

Further reading