Redis 7 – New Features
Redis 7 has been out for a while and we at Instaclustr have enjoyed getting to know it. We started offering Instaclustr for Redis 7, our managed Redis service, on our platform back in October 2022 and thought it was about time we talked about some of our favourite new features. It’s worth diving into yourselves as there is a lot worth exploring. In this blog, we will look at a few of our favourites to get you excited!
At a high level the ones we’re going to talk about here are:
As always, be careful when going between major versions. Check release notes carefully. We encourage you to try your preferred managed Redis version in your non-production environments first in order to confirm compatibility with your clients, before using it in production environments.
Redis Functions
Coding within Redis has thus far been the domain of ephemeral Lua scripting. These scripts in versions prior to Redis 7 were considered part of the application, not the database, and had to be managed by the application or client. In versions prior to Redis 7, the EVAL command could be used for sending Lua scripts to the server for execution. Redis would cache the script, but did nothing else in terms of managing, loading, or sharing scripts with other applications or clients that would connect to the same instance of Redis.
With the release of Redis 7, Redis functions have come along to supersede the use of EVAL within Redis. Redis functions are considered within Redis’ domain, instead of belonging to the application. This means they can be loaded at startup and called by different applications or clients. It allows the scripts, still using Lua, exposure to a richer set of Redis modules and APIs. Redis has also made it easier to trace the execution of functions from different applications or clients.
Redis Functions are also persisted to both the .rdb and .aof files and are replicated between masters and replicas, treating functions as a first class citizen of the Redis database. Another new advantage is that Redis functions allow code sharing. Every Redis function belongs to one library, and each library can contain many functions. This allows us to call functions from other functions that are in the same library.
Redis functions can be thought of as a user defined extension of the Redis database itself. The current execution engine that Redis ships with is for Lua 5.1. However, the Redis Functions page suggests that that support for other engines will be added in the future.
Redis first introduced Access Control Lists (ACLs) in Redis 6.0. Now, Redis 7 has evolved ACLs and is calling them ACLsv2. Redis 7 allows the use of selectors to define more granular access rules; continue reading for a brief insight into what selectors allow you to do. Redis has gone into a good level of detail in their announcement blog.
Redis 6 released the ability to fine grain some of the commands that a user could access with ACLs. For example, we could allow the user to get keys, but not set keys. Redis 7 builds on this in 2 important ways.
The first is the ability to restrict controls down to the key’s name. For example, allowing a user to only modify certain keys, or only read certain keys. This is demonstrated in the screenshot below, run on an Instaclustr Redis cluster. (If you don’t have a Redis cluster, sign up for a free trial account with Instaclustr here.) Here we are allowing user tests to GET name and SET surname, but nothing else is allowed by default.
The second is the introduction of selectors. Selectors are multiple sets of rules that are evaluated independently. To run a command the root selector will be evaluated, followed by any other selectors in the order they were added. Selectors can be added within brackets (). The screenshot below gives a simplistic example of adding selectors and showing that they are evaluated in the order they are added.
The screenshot below shows the ACLs, and their selectors at the end of each of the screenshots.
Performance Gains
Redis 7 claims performance gains across the board, and hails it as the unsung hero of the release. Performance tests can be tricky as there are so many variables to consider, instance sizes, regions, networking, rack layout, where the test script is being run, whether the underlying OS has been updated since the last time the test was run, and which variables have been included within the performance test itself, such as number of requests. The variables to consider when running the tests and then considering whether the results are comparable are endless. Running in the cloud can further complicate it by trying to work out whether any boost in your instance size or network occurred during the performance test.
As always, it’s best to take your infrastructure, networking, instance sizes into account before expecting any such gains.
And many more…
It’s hard to express just how much has gone into Redis 7. We keep finding little changes that make our lives easier that aren’t highlighted elsewhere. Here are a few small examples below:
ACL DRYRUN
You may have noticed in the screenshots above that we are using a command ACL DRYRUN to illustrate how ACL has evolved in Redis 7. ACL DRYRUN is also new in Redis 7. It provides an excellent way to play with your selectors, and allows users to work out if they are doing what you expect them to do.
cluster-port
cluster-port configuration addition allows users to set the internal cluster port, instead of having the default redis-port + 10000. Fixing the port provides a way, for example, to simplify any security rules that require ports.
Hostnames
The request for hostnames is an old github issue and it has finally been marked as closed with the release of Redis 7. While it’s not something that is being given as much fanfare as other changes in Redis 7, we consider it an important addition.
Adding a hostname to Redis is as simple as modifying a few config variables https://github.com/redis/redis/blob/7.0/redis.conf#L1736. We’re planning on using hostnames within Instaclustr’s Redis offering and combining it with a load balancer to be able to offer Redis with AWS Privatelink (to be released shortly), as we have done for some of our other bundles.
CLUSTER SHARDS
CLUSTER SLOTS has long been a much used and useful command, however, with Redis 7 it is considered deprecated in favour of CLUSTER SHARDS. The detail in the new command is much easier to read and super useful. It’s been extremely helpful while we’ve been playing with things like hostnames and cluster-ports and endpoints in Redis 7.
To give an example for the following 3 master, 3 replica cluster.
CLUSTER SLOTS returns the following:
It shows us the 3 shards with the following information
- Start slot
- End slot
- master
- Ip address
- Port
- Id
- A map of additional networking metadata (hostnames etc).
- Replica
- Ip address
- Port
- Id
- A map of additional networking metadata (hostnames etc).
For the same cluster CLUSTER SHARDS returns the following:
As with the SLOTS command it returns in “SHARDS”. A shard in Redis is a logical split of the slots, so shard 2 in the screenshot above stores slots 0-5460, and it stores these on 2 nodes, one of which is a master and one is a replica. For each node we see 16 lines, every second one is telling you what the next piece of data is. So (1) is “id”, and (2) is the value of id. As well as all of the data we see from SLOTS we also see information about replication offset, the health and the role of the node, and it’s in a much easier to read format. A small change, but a welcome one.
If there’s something you’ve been hanging out for Redis to do to make your life easier we’d recommend checking out the release notes—perhaps it’s been addressed! https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES
Notes
https://github.com/redis/redis/blob/7.0/redis.conf