dragonfly
KeyDB
Our great sponsors
dragonfly | KeyDB | |
---|---|---|
49 | 23 | |
23,037 | 9,823 | |
3.7% | 12.6% | |
9.9 | 8.6 | |
4 days ago | 3 days ago | |
C++ | C++ | |
BSL 1.1 | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dragonfly
-
Redict is an independent, copyleft fork of Redis
https://github.com/dragonflydb/dragonfly is another option. Not a fork but API-compatible reimplementation.
-
Redis License Changed
Check out DragonflyDB (BSL): https://www.dragonflydb.io/
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.
-
Dragonfly Cache Design
If you have not heard about Dragonfly - please check it out. It uses - what I hope - novel and interesting ideas backed up by the research from recent years [1] and [2]. It's meant to fix many problems that exist with Redis today. I have been working on Dragonfly for the last 7 months and it has been one of the more interesting and challenging projects I've ever done!
-
Generating Income from Open Source
I recently ran across the the license for Dragonfly [1] which has some restrictions (rights reserved), but 5 years after the license date the license switches to Apache 2.0. Basically a timed-limited rights reservation. I don't hate it. I might even contribute to such a project for free.
I would consider something like this: When I release code, it's rights reserved for 5 years, then open-source (and this baked into an irrevocable license). Anyone may use the software for non-commercial purposes. Anyone may contribute, those who contribute will be granted permission for commercial use if I deem their contributions significant enough. Anyone may distribute the software under these terms.
If such a model became popular, I have a hard time imagining it could make things any worse. It might even accelerate open-source development. You might say, "but it's not open-source", fair enough, but we can view it as open-source contribution with a delay. For example, if this model became wildely popular this year, and we saw great progress with this model, then come 2028 we would be flooded with new open-source software and ultimately might be better off than it would have been without this model.
(And this whole thing makes me rethink copyright and patents and how much they really contribute to society. Perhaps they should be shortened?)
[1]: https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.m...
-
Dragonfly – The most performant in-memory data store on Earth
2. You are right, I need to shut the fuck up and let self-righteous hn crowd with torches do what they do best - find a weakness, and push it until they get bored and switch to beat another builder. You asked me about my perspectives and priorities? These are my priorities: https://github.com/dragonflydb/dragonfly/graphs/contributors
> Developers do not want to manage a cluster of single cpu processes. Not on their laptops and not in the production. And it's not just about management complexity. See this https://github.com/dragonflydb/dragonfly/issues/1229 and it's just one example. Single cpu - is just not enough for today use-cases.
That may all very well be the case – let us assume it is for the sake of the argument although I have some comments about that as well – but that still means the argument is "Redis is too complex to run on multiple CPUs" and/or "Redis is poor for these workloads" (I didn't investigate that issue in-depth), and not "Redis is unable to do much work with this very powerful AWS instance". There two are very different things. There is no nuance anywhere in the benchmark. A reader might very well believe that this is all the performance they're going to get out of Redis on that machine, which that's clearly not the case.
License is important: 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.
Nokia was designed as strongest and most affordable phone, yet you use Iphone that costs 1000$. it's not about how it was designed but whether it addresses your current needs. Developers do not want to manage a cluster of single cpu processes. Not on their laptops and not in the production. And it's not just about management complexity. See this https://github.com/dragonflydb/dragonfly/issues/1229 and it's just one example. Single cpu - is just not enough for today use-cases.
-
The first version of Redis, written in Tcl
I think this is relevant... These are 3 OSS databases that can be an alternative to Redis:
- KeyDB: https://github.com/snapchat/keydb
- Dragonfly: https://github.com/dragonflydb/dragonfly
- Skytable: https://github.com/skytable/skytable
I have used keyDB before. The raft consensus makes building an HA Redis easy.
KeyDB
-
KeyDB: A Multithreaded Fork of Redis
Can you explain what lead you to believe it's dead?
Looking at the Issues in their Github, a couple of days ago they mentioned to be working on some features in a branch.
https://github.com/Snapchat/KeyDB/issues/798#issuecomment-20...
-
Redict is an independent, copyleft fork of Redis
https://github.com/Snapchat/KeyDB
KeyDB is an existing fork that’s well supported and has a solid community for those interested. It takes a different philosophy to Redis but can be a drop in replacement in many cases
-
Redis License Changed
Check out DragonflyDB (BSL): https://www.dragonflydb.io/
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.
-
The first version of Redis, written in Tcl
I think this is relevant... These are 3 OSS databases that can be an alternative to Redis:
- KeyDB: https://github.com/snapchat/keydb
- Dragonfly: https://github.com/dragonflydb/dragonfly
- Skytable: https://github.com/skytable/skytable
I have used keyDB before. The raft consensus makes building an HA Redis easy.
To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470).
- I deleted 78% of my Redis container and it still works
-
So, you call yourself the fastest key/value store? It's 5X, 10x and 25X faster
- KeyDB: https://github.com/snapchat/keydb
-
Global Presence; I made a thing
KeyDB is a fork of (everyone's favourite cache store) Redis, and it's messaging protocol and API is 100% compatible with Redis. What that means is you can just point any Redis client (like Hiredis or redis-rb) at a KeyDB instance, and it'll Just Work™️, with no changes required. The KeyDB selling points are: 1) multi-threading by default, and a lot of work was ploughed in to high performance around multi-threading in KeyDB, 2) compatible with all the features of regular Redis, 3) some advanced features which Redis only offers in it's paid/enterprise version are included for free in KeyDB, and the big one for me is multi-active replication, which is what I'm playing with here.
What are some alternatives?
keydb-operator - A KeyDB (Drop-In Alternative to Redis) Operator for Kubernetes
SSDB - SSDB - A fast NoSQL database, an alternative to Redis
mini-redis - Incomplete Redis client and server implementation using Tokio - for learning purposes only
tikv - Distributed transactional key-value database, originally created to complement TiDB
skytable - Skytable is a modern scalable NoSQL database with BlueQL, designed for performance, scalability and flexibility. Skytable gives you spaces, models, data types, complex collections and more to build powerful experiences
Tendis - Tendis is a high-performance distributed storage system fully compatible with the Redis protocol.
Redis - Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.
Memcached - memcached development tree
memKeyDB - MemKeyDB is a fork of Redis, adjusted to store objects on both Intel Optane Persistent Memory and DRAM.
sled - the champagne of beta embedded databases
dynomite - A generic dynamo implementation for different k-v storage engines