Live data from Hacker News

A multithreaded fork of Redis that is faster

docs.keydb.dev

121–130 of 164 posts

Re: A multithreaded fork of Redis that is faster

#121
I'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time.

Anecdotal, but it leaves me slightly confused

Re: A multithreaded fork of Redis that is faster

#122
post #20

Any 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…

As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when li…

Ok, what is a job/second?

Re: A multithreaded fork of Redis that is faster

#123
post #20

Any 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…

Facebook just published a blog about moving petabytes per hour. I read it, I find the design interesting. I don't need it. But if I do, it's good to know that it's possible, that someone has solved, to have a reference and to possibly use their tool if it's free. So relax, I for one welcome whatever folks are working on out there. If it's true, we can learn from it and apply it in order domains too.

>Facebook just published a blog about moving petabytes per hour.

But it's not like that's through one pipe. We don't talk about how many zillions of tons of steel per minute are moved on freeways.

Re: A multithreaded fork of Redis that is faster

#124
post #121

I'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time. Anecdotal, but it leaves me slightly confused

Higher traffic loads result in latency increasing. This benchmark covers the maximum load so latency will be much higher.

Re: A multithreaded fork of Redis that is faster

#125
post #51

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.

The Redis version does not thread query parsing. Its limited to only IO which is why its performance is much lower.

Re: A multithreaded fork of Redis that is faster

#126
post #121

I'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time. Anecdotal, but it leaves me slightly confused

Higher traffic loads result in latency increasing. This benchmark covers the maximum load so latency will be much higher.

Thanks for explaining.

Re: A multithreaded fork of Redis that is faster

#127
post #122

Earlier quoted context omitted.

As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when li…

Ok, what is a job/second?

Look up what Sidekiq is. It is awesome.

Re: A multithreaded fork of Redis that is faster

#128
post #20

Any 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…

As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when li…

May have been better to use GPL2?

Re: A multithreaded fork of Redis that is faster

#129

Earlier quoted context omitted.

> ...it's rarely just raw performance. KeyDB has other advantages like multi-threading... What are the advantages of "multi-threading" other than for performance?

Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a grea…

> Taking advantage of all your cores.

That means nothing at all, if performance is not your concern.

Re: A multithreaded fork of Redis that is faster

#130

Earlier quoted context omitted.

As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when li…

May have been better to use GPL2?

Better how? If using GPLv2 means companies stay away from the project instead of building on top of it, that's not a win for anyone.
Post reply on HN