5 ms·

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 th

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 7y ago
> 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-redis 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.
sciurus 7y ago
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-keydb-elasticache-and-redis-different 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.
sa46 7y ago
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.
coleifer 7y ago
Missing the point all over the place.
manigandham 7y ago
> "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.
aabbcc1241 7y ago
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.

hackingthenews 7y ago

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

sciurus 7y ago

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-keydb-elasticache-and-redis-different 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.

sa46 7y ago

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.

coleifer 7y ago

Missing the point all over the place.

manigandham 7y ago

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

aabbcc1241 7y ago

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.