This seems to keep the important bit about Redis single threading, that is that you have exclusive access to the db in a script or `multi`. That property allows for a lot of things that wouldn't be possible otherwise. Also leads to very predictable performance characteristics.
That said, Redis has always been faster than I've needed, and that's leaning on it pretty heavily, so I kind of agree with antirez that adding this complexity may not come with much benefit. Will be interesting to see where this goes.
According to the README all access to the data is effectively single threaded. Only the network work is actually multi-threaded.
> Access to the core hash table is guarded by spinlock. Because the hashtable access is extremely fast this lock has low contention. Transactions hold the lock for the duration of the EXEC command.
This will be improved in future versions. One of my major goals is to make KeyDB work well for large value sizes, >1MB. There’s no reason you shouldn’t be able to cache images as well as text.
FLASH support was the first step, and we’ve removed a bunch of unnecessary copies along the way but there is still more work to do.
That said, Redis has always been faster than I've needed, and that's leaning on it pretty heavily, so I kind of agree with antirez that adding this complexity may not come with much benefit. Will be interesting to see where this goes.