Dragonfly – Performant in-memory data store
dragonflydb.io
dragonflydb.io
That's exactly what they are doing, but if they had any brains, they'd have a human read the answers before they publish:
https://www.dragonflydb.io/faq/is-memcached-good
> As an AI language model, I am unable to make subjective judgments on whether Memcached is "good" or not. However, I can provide information about the features, benefits, and limitations of Memcached.
If the dragon fly devs are reading this, stop this nonsense seo gaming. This makes me trust your db less and cheapens everything that you stand for.
From this bad episode alone, how can we judge if they are bad at keeping the data safe/secure?
I am trying to remember when I last checked Redis' or Clickhouse's homepage or other pages on their site. I only care about their documentation pages and if they deliver what they are promising.
Are you disputing that the FAQ page tries to rank your site higher by having autogenerated answers to questions your site is not authoritative on? Are any of the questions on the FAQ actually written or meant to be read by a human?
Either way, if you want to keep a positive image going, don't take internet comments personally. Just incorporate the feedback and make changes if you feel it's warranted.
It might suggest that your perspectives and priorities are still wonky.
I would prioritize immediately and permanently removing the material and the practice, over posting questionable whataboutism arguments vs. spam.
The vertical scaling and performance seem extremely interesting, but for our use cases we need HA.
From a business perspective I’m interested to hear about the plans. Will there be a per core licensing fee of some sort?
What might have been interesting would be to test on a range of cores / clusters, and consider the overhead of managing 1VM vs 64VMs etc.
But there is nothing stopping you from running 64 Redis instances on one machine if it has 64 cores, which is what Redis did (actually, they ran just 40). That actually seems like a nicer design overall, as it scales "naturally" to multiple machines without any extra effort/code, it keeps the code simpler, you can also have one of these Redis instances segfault without bringing your entire cache down.
Other than that, they seem to have run the same benchmark. YMMV for other types of workloads of course, and perhaps Dragonfly could be configured better in some way.
Either way: it seems the Dragonfly benchmark is not just biased, but highly misleading. And while the Redis benchmark may be biased, it certainly doesn't seem highly misleading.
Yes, using a Redis cluster is the only way to get Redis to actually use system resources effectively, but its a relatively complex thing to create and manage compared to just running 1 server.
If you want to say "but this is more difficult": okay, fair enough (although in my experience it's not difficult at all), but then say that instead of posting a misleading benchmark which runs Redis in a way it's not supposed to run. You can place all sorts of artificial "yeah but I don't want to do it like this" constraints on all sort of things.
> Nokia was designed as strongest and most affordable phone, yet you use Iphone that costs 1000$
Actually I have a Nokia :-)
These are all fair and reasonable opinions to have, and to some degree I even agree with it, but none of that is captured in the rather simplistic benchmark. Everyone understands that even with the best of efforts it's hard to capture everything in a benchmark, but in this case it's just missing a very obvious way to run Redis.
It's like benchmarking PostgreSQL connections and coming to the conclusion there is no way PostgreSQL can handle more than n connections and that OtherSQL is much better. Is this true? Yes. But it's also true that half the world is running pg_bouncer and that this is widely seen as the way to run PostgreSQL if you need loads of connections. Is it a pain you need to run this and something that should be addressed in PostgreSQL? Absolutely. Such a benchmark would be correct in a strict narrow technical sense, but at the same time also misrepresentative of the real-world situation.
Provide more advanced benchmarks which demonstrates those types of differences better.
The situation is that the differences are complex, both in terms of performance and operationally (e.g. running multiple instances is not a huge obstacle, but it is harder). That's always going to be hard to capture in a single graph or a single tagline; I appreciate this isn't easy.
It's your website; you can do what you want with it. And maybe I'm just a grumpy old curmudgeon who has seen too many hype cycles, but to me it just comes off as "too good to be true" – which it kind of is – and leaves a more negative than positive impression. The same applies to "The most performant in-memory data store on Earth" tagline, which seems a bit hyperbolic (what is "fastest" depends, as you mentioned that Redis will always be faster on a single core – some people only need a single core!)
I have the business acumen of a goat, so what do I know? But it seems to me that a lot of people appreciate when products are straight-forward about their weaker points as well, and even straight-up say they're not the best fit for all scenarios, and in that in the long run this is more beneficial.
What if the database was designed to be run that way?
> You're comparing a box of Apples to a single apple.
Precisely. Dragonfly is a box of apples. Redis is a single apple that can be put in a box with other apples. If you run a "benchmark" comparing your box of apples against a sole apple, you're being either stupid or dishonest.
> The Dragonfly benchmark runs one Redis instance on a 64-CPU machine and compares it with one Dragonfly instance on the same machine.
They were not running 40 tiny VMs!
They clearly are not running 64 VMs in the test they are describing.
They compare both databases on one VM of the exact same size, both deployed as their makers recommend to deploy them.
https://github.com/dragonflydb/dragonfly/releases/tag/v1.3.0
If you want to integrate it, you also need to check the Software License.
https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.m...
Dragonfly Business Source License 1.1
License: BSL 1.1
Licensor: DragonflyDB, Ltd.
Licensed Work: Dragonfly including the software components, or any portion of them, and any modification.
Change Date: March 15, 2028
Change License: Apache License, Version 2.0, as published by the Apache Foundation.
Additional Use Grant: You may make use of the Licensed Work (i) only as part of your own product or service, provided it is not an in-memory data store product or service; and (ii) provided that you do not use, provide, distribute, or make available the Licensed Work as a Service. A “Service” is a commercial offering, product, hosted, or managed service, that allows third parties (other than your own employees and contractors acting on your behalf) to access and/or use the Licensed Work or a substantial set of the features or functionality of the Licensed Work to third parties as a software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar services that compete with Licensor products or services.
...
AGPL allows all of that, allows you to run it as a service, allows you to earn money, and if amazon ever reuses it you have access to their differentiating sauce so the playing field is leveled profiting everyone, including you. Most likely though amazon won't use it, which is also the original goal.
You mean make a hosted dragonfly a service you provide? (I'm not sure why the €10 matters - maybe I'm missing something) Yeah, that's exactly the point of that licence. You can do it in 5 years if you want.
Yes, why not ?
> (I'm not sure why the €10 matters - maybe I'm missing something)
That's a standard fee members pay to cover expenses the org may have
> Yeah, that's exactly the point of that licence. You can do it in 5 years if you want.
Good! At least there's a recognition of not being of public service and not doing this for everyone but only for themselves. I wish they chose another license, but it's a start
That's one specific case out of all possible uses that's not allowed with this licence. It honestly doesn't sound like much of a limitation. It would also be an extremely weird service to run as a non-profit.
> That's a standard fee members pay to cover expenses the org may have
Yes, but why did you mention it? It seems irrelevant to the question of what service you can build.
Amazon etc can just "take inspiration" from it and develop something from scratch that's almost the same
Why do we need faster storage? We need better models & domains that improve our developer experience. Not something faster. We don't need cars that go 650km/h. We need better roads and superior security controls
Blazingly fast wasn't enough; now we add "on Earth" to be impactful enough to capture our attention
Are people really running software that is making 1k Redis calls/message?
As for email, if email was broken down and nicely distributed over the same period I likely would have no issues. However, there are times where there is much more scanning going on, and a good 4 hours of peak time. This is where issues can crop up. If rspamd scan can't get a return fast enough, that test will be skipped. It still works, but I'd rather have all tests go through. So lets then take a single email and where redis is used
*Ratelimit checking
* Replies plugin
* Some multi map are stored in redis
*mx check module
* neural module (a bit like bayes but automatic and short term)
* fuzzy module used from spam traps
* history module - for redis admin, stats
So a single email is doing more than a single redis query for each email. The mail server (for smtp), which is not rspamd, is also using redis on its own.
Now imagine a spike of emails, perhaps a large spamming activity that is being stopped. Needing to scan 100 emails in a second isn't impossible at peak. The scanning is also for incoming and outgoing email.
Even at 100 ops/message you should be able to do > 1k messages/sec without breaking a sweat.
Yeah but sometimes it is and its a way better dev experience to scale up than out.
I am not sure if the latest version improves performance but those are some bold claims of Dragonfly.
"KeyDB – A Multithreaded Fork of Redis (keydb.dev)"
> We ran our tests on AWS Graviton2 EC2 instances, which are network-optimized and provide the best performance for web applications. We used memtier_benchmark — a widely used benchmarking tool developed by Redis Ltd. — to test throughput and latency, and Prometheus to monitor and visualize memory usage.
It is easy to reproduce and check the claims. Redis also countered with a blog post [2]
[1] - https://www.dragonflydb.io/blog/scaling-performance-redis-vs...
[2] - https://redis.com/blog/redis-architecture-13-years-later/
I'm most interested in latency to store the coordinates of thousands of players in real time. Well definitely check this out
So, exactly like redis?