3 ms·
I don't think it potentially taking a long time was the primary reason for not making redis multithreaded. In the redis manifesto it is stated that one of the g
by remon 8y ago
I don't think it potentially taking a long time was the primary reason for not making redis multithreaded. In the redis manifesto it is stated that one of the guiding principles is to avoid complexity if they can.
Also not that the benchmarks shown seem to be an apples and oranges comparison. If you want to compare the performance if redis vs a multithreaded fork the proper comparison involves running a redis cluster (one node per core) versus the multithreaded single node.
All else being equal I'd prefer a multithreaded approach as KeyDB is pursuing but that's just because it makes it easier to more easily utilise system resources of a single (virtual) machine.
- jdsully 8y agoI’m kinda against running a “cluster” on the same machine. That was a primary motivator for doing this. It’s offloading complexity from the developers to the users which I don’t think is the right approach. Also clusters have limitations over single instance redis. You’ll also get more Queries/GB with a Multithreaded approach.
- throwaway12iii 8y agoHow is a cluster more difficult for users in 2019? Most devs I know never even set up Redis. It just works through Docker/Ansible/cloud. Have you benchmarked cluster VS locks and threads approach?