Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
1–10 of 21 posts
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#2At 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.
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#3These 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…
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.
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#4Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#5Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#6Excellent post! I wonder why, given the performance, KeyDB is not more popular? Is there lack of hosted services?
KeyDB is new.
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#7are there significant architectural changes/tradeoffs in keydb that made it not-ideal to merge into redis?
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#8Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#9why 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?
Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB
#10These 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…
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.