Redis 2.6 RC8 is out

Redis 2.6 RC8 is out Friday, 05 October 12

I just released Redis 2.6.0-RC8 that is likely our latest RC release. Plans are to release 2.6.0 before the end of October.

There are a few new things in RC8 that are worth mentioning.

SRANDMEMBER <count>

The first is the SRANDMEMBER command that now accepts an optional argument to return multiple random elements.

If you want non-repeating elements, use a positive count:

redis 127.0.0.1:6379> sadd myset 1 2 3 4 5 6 7 8 9 10
(integer) 10
redis 127.0.0.1:6379> srandmember myset 3
1) "6"
2) "4"
3) "7"

If you want random elements in a "put the extracted element back in the box before next extraction" fashion (so elements may be repeated), just use a negative count.

redis 127.0.0.1:6379> srandmember myset -3
1) "1"
2) "5"
3) "1"

Long story short the command has a non trivial implementation to bring you the best of the performances even in the non-repeating elements case and even when the requested elements are near to the max number of elements in the set. Hint: sometimes is much faster to copy the set and remove random elements.

SORT by nosort

Expert Redis users already know that SORT can be used in a special way when we are not interested in sorting anything, but just to use the accessory capabilities of SORT like its GET option.

In this mode SORT used to shuffle sorted sets at random. Not in RC8, where the order of elements in the sorted set is respected, LIMIT is optimised using a O(log(N)) algorithm to seek to the right index, and DESC and ASC will do the right thing. Unfortunately this is yet not explicit documented in the SORT man page, but I'll do it in the next days.

New hash function: murmurhash2

The hash table implementation is now using the murmurhash2 hash function together with a randomised seed to prevent attacks. We observed some speed regression with synthetic benchmarks, but in workloads with random access to keys we observed an improvement in performances. Long story short if there is no proof that this change is a bad idea, is better to go for the added security and the better distribution of the new hash table, even if sometimes better distribution means worse cache locality so there are benchmarks where it will always perform poorly compared to djbhash.

On the other hand it is very likely that the new hash function will improve the quality of the distribution of elements returned by SPOP, RANDOMKEY, SRANDMEMBER, and other similar commands.

More resistance to clock skews

When your system clock dances, now it is a lot less likely that this will result in something odd, even if we can't still claim that Redis is clock skew resistent.

Sentinel is inside 2.6!

This may sound strange, but the thing is, Sentinel is going to be central in future developments, and it lives in a complete separated C file with almost no interaction with the rest of the system. So basically it will be trivial to take it in sync with 2.8 / unstable branches progresses in the Sentinel side.

Why, you may ask. Because we want people able to try Sentinel with minimal efforts in the future, in order to enlarge the user base of testers and speedup the process of making the system mature.

In Sentinel land there will be more stress in 2.8 about how to integrate Redis with Sentinel, how client libraries should interact with Sentinel, and so forth, we need to make all the components Sentinel-aware to guarantee the best monitoring / failover experience.

Milestones

The plan is to release Redis 2.6.0 before the end of October, to start hacking on the new things, that are:

Redis 2.8, that is, while hacking to unstable we'll try to merge as much as possible into 2.8 and release it. We did this with 2.6 and it worked well, I'm going to do it again.
Redis Sentinel: we need to improve the system to make it more reliable, documented, and integrated with Redis instances (auto configuration and alike), client libraries, and so forth.
Redis Cluster: I've some plan when 2.6.0 is stable enough to do what I did with Sentinel, to focus on Cluster for one/two months full time in order to bring it from alpha to beta stage, so that is something that users can start testing / using, more or less like it is happening now with Sentinel.

More news soon, have a splendid week end :-)

EDIT: we are looking for Redis talents! VMware has an open position for a great Redis Engineer. If you have solid C and POSIX skills and want to hack on Redis, this job is a good fit! If you prefer just contact me directly.

home