4 ms·

I think this is relevant... These are 3 OSS databases that can be an alternative to Redis: - KeyDB: https://github.com/snapchat/keydb https://github.com/snapch

by didip 3y ago

I think this is relevant... These are 3 OSS databases that can be an alternative to Redis: - KeyDB: https://github.com/snapchat/keydb https://github.com/snapchat/keydb - Dragonfly: https://github.com/dragonflydb/dragonfly https://github.com/dragonflydb/dragonfly - Skytable: https://github.com/skytable/skytable https://github.com/skytable/skytable I have used keyDB before. The raft consensus makes building an HA Redis easy.

danogentili 3y ago
We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability. 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.
- jdsully 3y ago
  Sorry it didn't work well for you. In the 6.3 release we tried to pack in too much although we've ironed out most of the issues. The hardest change has been moving away from fork() for background saving which has historically caused a lot of pain for running it in production and makes it difficult to do persistence. I definitely would have paced things out better if I could go back in time.
  - micw 3y ago
    To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494 https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470 https://github.com/Snapchat/KeyDB/issues/470).
- antirez 3y ago
  Yep in general when people consider Redis forks or alternaives that use more complex models, they don't realize the cost associated to the fact Redis is made in a certian way to be very stable and solid, and different choices lead to more fragility. Things that sometimes gets unnoticed: 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.
  - noir_lord 3y ago
    If someone wanted to truly master redis as a tool, is there a book or a starting point you would recommend? 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.
    - antirez 3y ago
      Unfortunately the book I wish existed didn't exist. I was about to write one for O'Reilly, but after the first exchanges I understood they were not the right match for me, so I abandoned the project. This happened several years ago, now I'm outside the Redis project so I'll not certainly write this book anymore. Later I started writing fiction, and during the process I understood that the bad vibes I had with O'Reilly were justified: the editor I had worked with tried to impose me a given shape for the book, a shape that I thought was not the right one. Their editing is massive and in the case of the Redis book they were destrying the book I had in mind. Writing a book is an insane amount of work, if you can't make it as you wish it is not worth the effort at all.
avinassh 3y ago
Dragonfly is not open source, rather source available. Also, has anyone here used SkyTable as an alternative to Redis?
- wizzwizz4 3y ago
  Dragonfly's source available license reverts to Apache on 2028-03-15. I think this "Business Source License" is a wonderful idea: there are business reasons to have proprietary code (yet another indictment of how we've structured our society), but this retains a decent chunk of the long-term benefit-to-the-user that open source provides (namely, reduced vendor lock-in; ability to exercise GDPR data portability rights; ability to keep stuff going after the company goes bankrupt and its assets get bought by a creative-tax-accounting "business"). "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!
  - tuananh 3y ago
    > Dragonfly's source available license reverts to Apache on 2028-03-15 can you explain a bit more? how does it work?
    - detaro 3y ago
      The license says that the license will change to Apache2 on that date.
      - tuananh 3y ago
        what's the rationale for that? why would that benefit users when selecting which OSS to adopt?
        detaro 3y ago
        It's not OSS. 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.
mobilio 3y ago
Also SSDB: https://github.com/ideawu/ssdb https://github.com/ideawu/ssdb
hivacruz 3y ago
We use Kvrocks[0] at work. It is Redis on disk, powered by "RocksDB" (hence the name) and compatible with most of the Redis clients since it respects the Redis protocol. It was incubated by Apache earlier this year. It works great and the development is really active. [0]: https://kvrocks.apache.org https://kvrocks.apache.org
tuppinsabound 3y ago
Also Opatomic https://opatomic.com/ https://opatomic.com/ Database server is not yet open source though

by didip 3y ago

danogentili 3y ago

We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability. 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.

jdsully 3y ago
Sorry it didn't work well for you. In the 6.3 release we tried to pack in too much although we've ironed out most of the issues. The hardest change has been moving away from fork() for background saving which has historically caused a lot of pain for running it in production and makes it difficult to do persistence. I definitely would have paced things out better if I could go back in time.
- micw 3y ago
  To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494 https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470 https://github.com/Snapchat/KeyDB/issues/470).
antirez 3y ago
Yep in general when people consider Redis forks or alternaives that use more complex models, they don't realize the cost associated to the fact Redis is made in a certian way to be very stable and solid, and different choices lead to more fragility. Things that sometimes gets unnoticed: 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.
- noir_lord 3y ago
  If someone wanted to truly master redis as a tool, is there a book or a starting point you would recommend? 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.
  - antirez 3y ago
    Unfortunately the book I wish existed didn't exist. I was about to write one for O'Reilly, but after the first exchanges I understood they were not the right match for me, so I abandoned the project. This happened several years ago, now I'm outside the Redis project so I'll not certainly write this book anymore. Later I started writing fiction, and during the process I understood that the bad vibes I had with O'Reilly were justified: the editor I had worked with tried to impose me a given shape for the book, a shape that I thought was not the right one. Their editing is massive and in the case of the Redis book they were destrying the book I had in mind. Writing a book is an insane amount of work, if you can't make it as you wish it is not worth the effort at all.

avinassh 3y ago

Dragonfly is not open source, rather source available. Also, has anyone here used SkyTable as an alternative to Redis?

wizzwizz4 3y ago
Dragonfly's source available license reverts to Apache on 2028-03-15. I think this "Business Source License" is a wonderful idea: there are business reasons to have proprietary code (yet another indictment of how we've structured our society), but this retains a decent chunk of the long-term benefit-to-the-user that open source provides (namely, reduced vendor lock-in; ability to exercise GDPR data portability rights; ability to keep stuff going after the company goes bankrupt and its assets get bought by a creative-tax-accounting "business"). "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!
- tuananh 3y ago
  > Dragonfly's source available license reverts to Apache on 2028-03-15 can you explain a bit more? how does it work?
  - detaro 3y ago
    The license says that the license will change to Apache2 on that date.
    - tuananh 3y ago
      what's the rationale for that? why would that benefit users when selecting which OSS to adopt?
      - detaro 3y ago
        It's not OSS. 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.

mobilio 3y ago

Also SSDB: https://github.com/ideawu/ssdb https://github.com/ideawu/ssdb

hivacruz 3y ago

We use Kvrocks[0] at work. It is Redis on disk, powered by "RocksDB" (hence the name) and compatible with most of the Redis clients since it respects the Redis protocol. It was incubated by Apache earlier this year. It works great and the development is really active. [0]: https://kvrocks.apache.org https://kvrocks.apache.org

tuppinsabound 3y ago

Also Opatomic https://opatomic.com/ https://opatomic.com/ Database server is not yet open source though