Redis 4 is now deployable on Compose and although the user visible changes are few, the improvements in the engineering make for a better Redis for all.
Today, we're making Redis 4 available on Compose. The Redis 4 series took around a year to develop and has focussed on enhancing how Redis works internally. In a tightly tuned server like Redis, that means improvements all around. Better replication, better cache capabilities, new non-blocking of flushing and deletion, and active memory defragmentation all work to make Redis 4 a smoother experience.
If you want to upgrade to Redis 4 on Compose, you can do so from the Settings tab in the Compose console and use the Change Version panel to do the upgrade to Redis 4.0.2. New deployments will default to Redis 4.0.2.
Redis 4 has a whole new synchronization engine by the name of PSYNC2. It changes how data is propagated between masters and slaves and most importantly reduces the number of times a full resynchronization is needed to bring a master or slave node online. For Compose users, this means faster, more reliable failover.
One of the most important things with a cache is how it makes space. Redis has traditionally used an LRU (Least Recently Used) policy to evict old data. This wasn't a precise eviction; Up until Redis 3.0, Redis sampled a small number of keys and then evicted to ones with the oldest access time. Redis 3.0 added a pool of likely candidates for eviction which helped.
Redis 4.0 adds the LFU, Least Frequently Used, policy to the options available. This does the same kind of sampling as LRU, but instead of looking at how long ago the data was last accessed, it looks at how often it was accessed using a decaying counter so that the passing of time has an impact on the access count. Whether using LRU or LFU is appropriate for your Redis depends on your workload. You can test each mode by using the Settings tab on Compose and adjusting maxmemory-policy. We recommend you read Using Redis as a Cache from the Redis documentation before changing adjusting values.
Nearly all operations on Redis block other operations from running because Redis is a single threaded database. That's what gives Redis it's atomic operations, but what happens when operations take a long time? Take
FLUSHALL which delete all the keys in the current database or all the databases. They can take some time to execute so in Redis 4 both commands get an
ASYNC option which when added which does the deletion in the background on its own thread. Particularly useful if you want to clear and
SWAPDB between Redis's internal databases.
There is also a non-blocking version of the
DEL key deletion command. The
UNLINK command works like
DEL but instead of actually deleting keys it just removes references to the keys and Redis will tidy up the results later.
Active memory management
Within Redis and when running on Linux platforms, the jemalloc library is used. This library lets Redis participate more with the process of allocating, and more importantly deallocating memory. This in turn means Redis can more efficiently reclaim and release memory.
Which brings us to the new
MALLOC-STATS. Most of these commands exist for debugging of things like the active memory management.
MEMORY USAGE takes a key and shows you how much memory that key is consuming, which could be more generally useful when tracking down overconsumption of RAM.
More in Redis 4
Compose Redis 4 today
As you can see, Redis 4 is built to make the engineering of in-memory data structure store more predictable, more reliable and a little less single-threaded where needed. Many of the changes we can see offering solutions to Compose Redis users so, welcome to Redis 4 on Compose.
Read more articles about Compose databases - use our Curated Collections Guide for articles on each database type. If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at firstname.lastname@example.org. We're happy to hear from you.
attribution Samuel Zeller