So this year on RedisConf Antirez demoed threaded version for Redis (only transport needs to be multi-threaded, core remains single threaded). Numbers were already amazing. I will pick the community version of Redis any day over forks.
A multithreaded fork of Redis that is faster
51–60 of 164 posts
Re: A multithreaded fork of Redis that is faster
#52On 32 cores? Doesn't seem like particularly great scaling.
It looks like 8 to me. The 32 core mention was the test apparatus used to generate the requests.
Re: A multithreaded fork of Redis that is faster
#53Since this has been around for awhile, why hasn't Redis adopted this strategy into core?
https://news.ycombinator.com/item?id=19368955
Previous discussion about keydb, commented by antirez.
Re: A multithreaded fork of Redis that is faster
#54Earlier quoted context omitted.
The human-readable/writable protocol is one of my favorite things about Redis, tbh. I can see cases where a really optimized system could benefit from a binary protocol, but I suspect it'd be a loss for most people.
Why not just offer both?
That was my thinking as well, though taking a peek at the actual code suggests that there's a pretty deep expectation that the client is speaking strings, e.g. in code that handles the ZRANGE command[1] I see
if (c->argc == 5 && !strcasecmp(c->argv[4]->ptr,"withscores"))
% grep argv src/*.c | grep -c -e 'str\(case\)*cmp'
482
[1] https://github.com/antirez/redis/blob/unstable/src/t_zset.c#...
Re: A multithreaded fork of Redis that is faster
#55Earlier quoted context omitted.
Not parent but the single threaded approach really shines when executing Lua scripts in Redis. Except for some very specific edge cases, the execution of a script is atomic and since no command is ever processed concurrently you can rule out data races. I am sure it would be possible to provide these guaranties while offering concurrent execution but most likely at the expense of a simple design.
It shines right up until the moment someone writes a Lua command that takes more than a trivial amount of time, now your entire server is blocked in a pile-up of connections waiting on some relatively trivial amount of code being executed.
Couldn't you just rollback the change or fix the lua script?
Re: A multithreaded fork of Redis that is faster
#56Earlier quoted context omitted.
True, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes it better at utilizing your server resources and handling larger scales.
But isn't the point of Redis is to be used as a caching layer instead of persistent layer
You can use redis as a write-back cache that serves spikes well and streams the state to disk (or an RDBMS) in a rate-limited manner in the background.
Re: A multithreaded fork of Redis that is faster
#57Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
The idle CPU might very well be due to redis being single threaded. It might be hitting is limits and still show low CPU utilization.
Also, you didn't mention that, but I've seen this happening often, you should never use redis as a primary data store if your data is important.
Re: A multithreaded fork of Redis that is faster
#58Earlier quoted context omitted.
From Antirez's (Redis Maintainer) blog: > Another thing to note is that Redis is not Memcached, but, like memcached, is an in-memory system. To make multithreaded an in-memory system like memcached, with a very simple data model, makes a lot of sense. A multi-threaded on-disk store is mandatory. A multi-threaded complex in-memory system is in the middle where things become ugly: Redis clients are not isolated, and da…
This should be top comment. I came here to chat about potential downsides introduced by complexity of having multiple threads accessing the internal data structure. Until someone runs this in production where they actually use the performance it delivers over and above vanilla redis, I'll probably hold off. I'd like to know it's stable under very high load with contention. No offense to the creator(s) and I have a to…
No offense taken. KeyDB has different goals than Redis so you’ll see us try things Redis might not. I’m willing to make the code more complex if it makes the user’s life easier in some way.
Re: A multithreaded fork of Redis that is faster
#59Any time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-us…
I've personally written a (somewhat hacky but simple) setup for multiplexing high-throughput job queues for a Rails app across multiple Redis instances because our chosen job framework at the time relied a lot on Lua operations on large sets in Redis, and these could easily result in 100% CPU utilization for the Redis process.
We picked the job queue framework long before we started moving tens of thousands of jobs a second through it with a later feature, and probably exceeded its design constraints - in that instance we effectively were using Redis + jobs as a pauseable and throttleable write buffer for MySQL.
With major tooling changes we likely could have come up with something a lot more elegant, I'm not longer with that company, but our plan was always to get rid of the need for that system to hit MySQL at all, which would eliminate a lot of our need to control throughput with our Redis buffer. Of course, doing that would have taken a lot more time and effort, and in our case doing "the simplest possible thing that would work reliably and serve our customers" meant that we probably could have used a faster Redis instead of multiplexing requests and workers across multiple Redis instances on the same hardware.
Sometimes an "improved" version of a tool you're already using can be really useful, if you find yourself in a bind and the alternative is major architectural changes.
Re: A multithreaded fork of Redis that is faster
#60You went to the effort of forking Redis but didn’t bother to fix the glaring lack of TLS support?
What is the fucking point of a replicated KV store if the connections between nodes aren’t encrypted.