Bug#1067413: RFP: keydb -- persistent key-value database with network interface
On 2024-03-25 17:43:58, Guillem Jover wrote: > Hi! > > On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote: >> > I'm CCing Chris, who might perhaps be interested in replacing Redis with >> > KeyDB as its spiritual successor and taking this on? Or if not, at least >> > to perhaps potentially coordinate some kind of transition, even though >> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so >> > that might be tricky or not feasible at all. >> >> Thanks for including me here. I had not yet looked into potential >> Redis replacements nor the exact and precise details of the new >> license etc. and this activity around KeyDB feels like a good start. >> I thought I'd let the dust settle for a bit before making any >> decisions — perhaps the change even gets reversed (!), and no doubt >> there might be new alternatives that will fork the code immediately >> prior to the license change. > > Yeah, fair enough. > >> My personal and professional usage of Redis has dropped off in the >> past few years, so it would make more sense for me to help out in a >> team maintainership role, at least with respect to KeyDB. > > Ack. > >> However, I'd be interested in coordinating around some kind of >> Redis→KeyDB/something transition if need be. > > For KeyDB, that would also depend on whether KeyDB adds Redis 7 support > or not I guess. > > https://github.com/Snapchat/KeyDB/issues/420 > > and if that does not materialize, a potential migration path via: > > https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311 > > In our, case we migrated from Redis 6 to KeyDB, so the above did not > really affect us. After reading https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/, i have the feeling valkey is probably a better bet for a smooth transition. I filed a RFP about it in https://bugs.debian.org/1068342 A. -- We know the road to freedom has always been stalked by death. - Angela Davis
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
Hi! On Fri, 2024-03-22 at 12:35:47 +, Chris Lamb wrote: > > I'm CCing Chris, who might perhaps be interested in replacing Redis with > > KeyDB as its spiritual successor and taking this on? Or if not, at least > > to perhaps potentially coordinate some kind of transition, even though > > we've had issues migrating persistent DBs from newer Redis to KeyDB, so > > that might be tricky or not feasible at all. > > Thanks for including me here. I had not yet looked into potential > Redis replacements nor the exact and precise details of the new > license etc. and this activity around KeyDB feels like a good start. > I thought I'd let the dust settle for a bit before making any > decisions — perhaps the change even gets reversed (!), and no doubt > there might be new alternatives that will fork the code immediately > prior to the license change. Yeah, fair enough. > My personal and professional usage of Redis has dropped off in the > past few years, so it would make more sense for me to help out in a > team maintainership role, at least with respect to KeyDB. Ack. > However, I'd be interested in coordinating around some kind of > Redis→KeyDB/something transition if need be. For KeyDB, that would also depend on whether KeyDB adds Redis 7 support or not I guess. https://github.com/Snapchat/KeyDB/issues/420 and if that does not materialize, a potential migration path via: https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311 In our, case we migrated from Redis 6 to KeyDB, so the above did not really affect us. > (Incidentally, why did your work switch to KeyDB?) We did this several years ago, AFAIR mainly for its active-active replication mode for our HA setup. The multi-threading was a nice improvement too. And I cannot recall exactly, but I think at that time Redis Inc was already going into a weird licensing path with its other adjacent projects, so we might have taken that too as a nice side effect to get away from. Thanks, Guillem
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
affects 1067413 + redis-server thanks Hi Guillem, > I'm CCing Chris, who might perhaps be interested in replacing Redis with > KeyDB as its spiritual successor and taking this on? Or if not, at least > to perhaps potentially coordinate some kind of transition, even though > we've had issues migrating persistent DBs from newer Redis to KeyDB, so > that might be tricky or not feasible at all. Thanks for including me here. I had not yet looked into potential Redis replacements nor the exact and precise details of the new license etc. and this activity around KeyDB feels like a good start. I thought I'd let the dust settle for a bit before making any decisions — perhaps the change even gets reversed (!), and no doubt there might be new alternatives that will fork the code immediately prior to the license change. My personal and professional usage of Redis has dropped off in the past few years, so it would make more sense for me to help out in a team maintainership role, at least with respect to KeyDB. However, I'd be interested in coordinating around some kind of Redis→KeyDB/something transition if need be. (Incidentally, why did your work switch to KeyDB?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Processed: Re: Bug#1067413: RFP: keydb -- persistent key-value database with network interface
Processing commands for cont...@bugs.debian.org: > affects 1067413 + redis-server Bug #1067413 [wnpp] RFP: keydb -- persistent key-value database with network interface Added indication that 1067413 affects redis-server > thanks Stopping processing here. Please contact me if you need assistance. -- 1067413: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067413 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
Hi Guillem, [RFP] I'll try to do this during this week or next one, but if someone would like to package this right ahead, I can speed this up. Cool. If my old packaging helps in any way, feel free to steal anything from it! [0] [...] I'm also CCing Sascha who might be interested (given the keydb packaging repo in salsa). That was a one-off that never made it from a testing prototype into anything upload-worthy, let alone into production. We used it to evaluate KeyDB internally within my organization as a potentially faster Redis replacement, but we found out that it didn't help in our particular use case. I just packaged it for Debian to allow for easier installation/removal, so really simply for our convenience. I didn't polish the packaging, did not do time-consuming things like checking licenses, looking for the presence of code copies, etc. like I would for something to be uploaded to the official archive. You can also see that I just copied the debian directory from a different project (e.g. in d/upstream/metadata). I also wouldn't want to support KeyDB in Debian long-term, given that I already have >100 packages on my list and, as I said, I don't use KeyDB myself anymore. So please feel free to salvage the (unfortunately quite old) repo. Just fork, remove me from the maintainer list and upload at will Best regards Sascha [0] https://salsa.debian.org/satta/keydb OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
Package: wnpp Severity: wishlist X-Debbugs-Cc: Chris Lamb , Sascha Steinbiss * Package name: keydb Version : 6.3.4 Upstream Contact: https://github.com/Snapchat/KeyDB * URL : https://keydb.dev/ * License : BSD-3-clause Programming Lang: C, C++ Description : persistent key-value database with network interface keydb is a key-value database in a similar vein to memcache but the dataset is non-volatile. keydb additionally provides native support for atomically manipulating and querying data structures such as lists and sets. . The dataset is stored entirely in memory and periodically flushed to disk. This project started as a fork from redis, for improved performance and multi-threading support. We switched at work to it some time ago, and had pending sending an RFP/ITP, but given the just announced license change for redis to make it non-free [L], this seems more relevant now. We've got the packaging bits around, which I'll try to send to this bug report, but there's still some work that might be needed before an upload, at least: - Unvendor more stuff (we have at least unvendored jemalloc and rocksdb, but most of the rest need to go too). - Switch to use _keydb:_keydb as user and group (instead of keydb:keydb). - Review and improve the maintscripts (as I think we initially based our packaging on the upstream provided templates). I'll try to do this during this week or next one, but if someone would like to package this right ahead, I can speed this up. I'm CCing Chris, who might perhaps be interested in replacing Redis with KeyDB as its spiritual successor and taking this on? Or if not, at least to perhaps potentially coordinate some kind of transition, even though we've had issues migrating persistent DBs from newer Redis to KeyDB, so that might be tricky or not feasible at all. I'm also CCing Sascha who might be interested (given the keydb packaging repo in salsa). (I'm not sure we are up for sole maintainership if no one takes this on, but we'd be happy to give a hand in a team maintainership setting and that might be an option for us if someone else is interested in driving this.) [L] https://lwn.net/Articles/966133/ Thanks, Guillem
