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.
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.
5 comments
[ 0.26 ms ] story [ 28.8 ms ] threadSome reasons against: http://antirez.com/news/126
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.
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!
Are existing Redis clients compatible with KeyDB?