
Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB - benschermel
https://docs.keydb.dev/blog/2020/04/15/blog-post/
======
bognition
These benchmark posts are good but they are a bit unsatisfying, I wish they’d
spend more time a laying out the fundamental differences of each technology
and the trade offs that are the result of how the different systems are built.

At the end of the day an engineer shouldn’t pick database because it’s the
fastest but because it fits their use case the best.

I get that reddis, memcached, and keydb are all roughly in memory hashmaps but
beyond that knowing what makes them different, how hard are they to operate,
what they are good at and bad at is going to be more helpful in selecting
which technology to use than a simple throughout benchmark.

~~~
hackingthenews
> At the end of the day an engineer shouldn’t pick database because it’s the
> fastest but because it fits their use case the best.

Every comparison article doesn't need to (and shouldn't) include a comparison
about every kind of detail about two technologies.

> I get that reddis, memcached, and keydb are all roughly in memory hashmaps
> but beyond that knowing what makes them different, how hard are they to
> operate, what they are good at and bad at is going to be more helpful in
> selecting which technology to use than a simple throughout benchmark.

If a post is about speed/performance, and you want to know implementation
details (or accessibility or how well it plays with your stack) then look for
something else. A quick google search quickly gives me whatever details I want
to know about whatever two widely used technologies:

For example redis vs memcached:
[https://stackoverflow.com/questions/10558465/memcached-vs-
re...](https://stackoverflow.com/questions/10558465/memcached-vs-redis)

But more importantly its okay for a post to be narrow in scope. The
requirement should be that it is not misleading in whatever question it sets
out to answer.

------
briffle
This is interesting, but why not add in a benchmark for regular redis as a
'baseline'. Is it really worth upgrading to me?

~~~
manigandham
It does use regular Redis, from the new 6.0 release. This post is comparing
different products, not versions of Redis.

If you want to see how much Redis itself improved from 5.0 to 6.0 then you can
look at Salvatore's updates:
[https://twitter.com/antirez/status/1110973404226772995](https://twitter.com/antirez/status/1110973404226772995)
and other benchmarks: [https://itnext.io/benchmarking-the-experimental-redis-
multi-...](https://itnext.io/benchmarking-the-experimental-redis-multi-
threaded-i-o-1bb28b69a314)

------
aledalgrande
Excellent post! I wonder why, given the performance, KeyDB is not more
popular? Is there lack of hosted services?

~~~
sidlls
Redis (single-threaded) is just fine for all but the biggest scale, is well-
tested, and because it's a simpler model less likely to have all the terribly
complicated edge-case bugs the introduction of concurrency implies.

Also there's a matter of need. It does one no good if a KV store can churn
through 200 kops/s if you can only deliver 100kops/s. If one or two redis
instances (plus replicas, etc., or maybe a minimal three-master cluster) can
serve the entire workload, saving two or three nodes by "upgrading" to the
likes of KeyDB doesn't seem worth it. I mean, unless you're aiming to get to
the melt-the-metal it's so "hot" all the time performance.

~~~
aledalgrande
Interesting, yeah more bugs due to the complexity of multi threaded
programming is the first thing that came to mind.

------
twoodfin
I’m not familiar with Memtier, but those YCSB numbers for, say, the read-only
Workload C look surprisingly low for an in-memory store. 25k/second/thread? Is
that just hitting the limits of how fast you can round-trip a request over the
network?

------
bsamuels
why a separate project for keydb? couldn't all this just be merged into the
main project?

are there significant architectural changes/tradeoffs in keydb that made it
not-ideal to merge into redis?

~~~
jzoch
KeyDB has some hacker news posts in the past where it was shared but these
modifications were not accepted into redis. At the time Redis was not
considering multi-threading.

------
JulianMorrison
(Note to the KeyDB people who are probably reading this. On your front page,
"Atlernative" is a typo.)

