Bug#1067413: RFP: keydb -- persistent key-value database with network interface
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Chris Lamb <lamby@debian.org>, Sascha Steinbiss <satta@debian.org>
* 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
Reply to: