[Thaxll]

It's multithreaded but what about Redis running on a single core in a cluster? Like running 8 Redis on a single 8 cores CPU. I don't really understand the reason to run Redis on multiple core since you can run multiple Redis on a single CPU with clustering which will have better perforamce than running KeYDB with the same number of cores.

[jdsully]

Take the scenario where you have an 9 node redis cluster. With KeyDB you could shrink that down to 3 nodes with 3 threads while getting the same throughput. This reduces the maintenance burden while also reducing latency. There's overhead to connecting to a different cluster server each time you access a seperate shard.

Even better you might be able to avoid having a cluster at all. For many that’s the biggest win with KeyDB.

[mayank]

> There's overhead to connecting to a different cluster server each time you access a seperate shard.

While I agree with your point, this concern is easily addressed with connection pools.

[asperous]

This what redis’s creator antirez suggests: “ the way I want to scale Redis is by improving the support for multiple Redis instances to be executed in the same host, especially via Redis Cluster” http://antirez.com/news/126

It’s basically back to the multi-threading vs multiprocessing debate that also exists in Python. With multiprocessing, you have more overhead but the client itself is simpler.

It’s kind of a weird in between where you need more scalability then a single redis but no so much that you want to go to a cluster.