Show HN: KeyDB – A Multithreaded Fork of Redis

github.com

17 points·jdsully··5 comments

Open articleView on HN

I'd like to hear more on why you believe the Redis team is incorrect?

Some reasons against: http://antirez.com/news/126

Three main reasons:

1) Modern NICs have multiple queues, and are best used with multiple threads.

2) A single core is not capable of saturating DRAM bandwidth.

3) Sharding is annoying, the more you can get out of one instance the better.

Those were the reasons we made the attempt. It certainly does make the code more complicated, but there's no feature in Redis that prevents it. The beauty of open source is you get a chance to try these things.

Cutting latency in half was a big benefit for us.

Interesting. My personal response to that list would be:

1) Binding a specific CPU->NIC like one often does for LB's such as HAProxy is likely more performant.

2) Multiple instances of Redis on a single box; one per physical CPU core

3) I can't argue that it's annoying, but generally with Redis you're going to want shards across physical machines anyway.

Not trying to attack, just curious. As you say, that's the beauty of OSS so props to you!

Looks like a wonderful project. In general, the primary value to in-memory data stores is lower latency and higher throughput, so I'm excited to give KeyDB a try.

Are existing Redis clients compatible with KeyDB?

Yes, its the exact same protocol. Compiling is also just as easy, except you need NASM.

Reply on news.ycombinator.com