
Show HN: KeyDB – A Multithreaded Fork of Redis - jdsully
https://github.com/JohnSully/KeyDB
======
NuSkooler
I'd like to hear more on why you believe the Redis team is incorrect?

Some reasons against:
[http://antirez.com/news/126](http://antirez.com/news/126)

~~~
jdsully
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.

~~~
NuSkooler
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!

------
hackerjnews
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?

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

