Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB | Hacker News Reader

Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

docs.keydb.dev

127 pointsbenschermel20 comments

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.

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

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.

The post covers all the points you mention. The benchmark only covers Redis forks so it doesn’t get a whole lot more apples-to-apples than this.

> So there are 3 offerings by 3 companies, all compatible with eachother and based off open source Redis: Elasticache is offered as an optimized service offering of Redis; RedisLabs and Redis providing a core product and monetized offering, and KeyDB which remains a fast cutting edge (open source) superset of Redis. This blog looks specifically at performance, however there is a section at the end of this blog that also outlines other key differences.

The last paragraphs give a good overview of the differences.

I think this criticism is misdirected.

First, you mentioned memcached, but the article doesn't cover that at all. Perhaps you meant to say elasticache?

Second, I think the closing section at https://docs.keydb.dev/blog/2020/04/15/blog-post/#how-are-ke... does a reasonable job of answering the "fundamental differences of each technology and the trade offs". If it's not more in depth, that's mostly because it's comparing Redis with two forks of the codebase that haven't diverged that much.

> "This blog looks specifically at performance, however there is a section at the end of this blog that also outlines other key differences."

Memcached is not a part of this comparison, only Redis and forks.

It's hard to summarize much more in a single blog post and is really up to the dev to do the research before picking a solution.

The article mentioned KeyDB is multithreaded fork of Redis. It multithreads several aspects including placing the event loop on multiple threads, with network IO, and query parsing done concurrently.

Missing the point all over the place.

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

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 and other benchmarks: https://itnext.io/benchmarking-the-experimental-redis-multi-...

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

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.

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

Redis has been around a long time. ElastiCache has been around a while and is deployable in AWS very easily.

KeyDB is new.

And that comes with lots of libraries, tools, and documentation to make using them easy

KeyDB is compatible with existing Redis libraries and tools. If you use some of the newer features your library may lack direct support but most have extensiblity features built in.

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?

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?

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.

Yes, the overview page covers it: https://docs.keydb.dev/docs/intro/

KeyDB offers more performance, functionality and deployment features that are not possible or won't be allowed in mainline Redis.

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

Reply on news.ycombinator.com