- 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.
Multimaster replication is convenient, but if you accidentally add the IP of the current replica to the replicaset, the entire cluster will crash if any of the nodes shuts down for any reason (note, not immediately, but days or even weeks after starting the cluster with everything working perfectly until one of the nodes crashes or shuts down).
Enabling diskless replication in multimaster mode causes either deadlocks, or immediate crashes, depending on the overall LA of the system (!).
These are just the issues I remember right now, because the related issues I opened in the repo are still open almost a year later; we had other crashes we had to workaround, too.
1. The non threaded architecture of Redis need more management since you have to shard to many instances, but it is optimal from the POV of CPU utilization, especially if you do pinning to different NICs and so forth. And the risk of bugs in threaded code is very large.
2. Redis threadoffs such as copy-on-write during persistence is not optimal all the times, but the worst case behavior is predictable, and whatever is the layout of the data structure, you copy 4k pages. When more complex techniques are emplyed, sometimes you can do much better, sometimes you fail in a quite pathological way.
3. In general simplicity is there for a reason, and if you go with a fork that is more compelx, has ways less users, less developers and so forth, things can be less pleasent than they appear in READMEs with fancy benchmarks.
4. Redis is conceived to be easy to understand and modify by the folks that run it at scale. So the simplicity also is a way to say: come in, change things in your fork, make it particularly adapt for your use case: it's not going to be too complex to do it. Hackability is the contrary of vendor lock-in.
Have used redis for years, have scratched more than the surface but I feel like there is so much more underneath I'm missing and my knowledge is (as is often the case) cobbled together from using it, reading bits of the docs and blog posts.
I definitely would have paced things out better if I could go back in time.
It works great and the development is really active.
Database server is not yet open source though
Also, has anyone here used SkyTable as an alternative to Redis?
"Production" doesn't seem well-defined, so in practice this is probably a crayon license; and reverting to Apache gives you all the problems of permissive licenses. But it's a wonderful idea!
can you explain a bit more? how does it work?
It becoming OSS in the future is somewhat of an insurance against its maker going out of business or making unacceptable changes and users being stuck with software they can't improve or fix.