Up to date Rust bindings for LMDB
crates.io
Up to date Rust bindings for LMDB
1–10 of 15 posts
Re: Up to date Rust bindings for LMDB
#2not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help.
some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not use it.
chose to keep the version in step with LMDB (current looks like 0.9.70 in the lmdb.h).
will regenerate anytime i become aware of a version bump for LMDB.
Re: Up to date Rust bindings for LMDB
#3not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help. some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not u…
> not sure why all the existing crates have gone so far out of date.
Pure speculation on my part: maybe people are choosing Rust-based embedded key value stores like sled or redb?
Re: Up to date Rust bindings for LMDB
#4not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help. some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not u…
> not sure why all the existing crates have gone so far out of date. Pure speculation on my part: maybe people are choosing Rust-based embedded key value stores like sled or redb?
Re: Up to date Rust bindings for LMDB
#5not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help. some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not u…
> not sure why all the existing crates have gone so far out of date. Pure speculation on my part: maybe people are choosing Rust-based embedded key value stores like sled or redb?
Only slightly off topic, but any of these support fast concurrent writes? LMDB really slows down for me when I'm trying to write a lot to it and locking means i cant use concurrency to speed it up.
Re: Up to date Rust bindings for LMDB
#6For those of us who don't know, LMDB is a DB, somewhat akin to sqlite or Berkeley DB. It took a bit of time to find the info by chasing links.
Please add READMEs to your projects with appropriate links, folks.
https://crates.io/crates/liblmdb ... which links to the repo
https://github.com/ordinarylabs/liblmdb
Which has a link to the LMDB repo here (just a submodule) ...
https://github.com/LMDB/lmdb/tree/9c9d34558cc438f99aebd1ab58...
Which has no info about the project, but links to
https://www.openldap.org/software/repo.html
Which also has no info about the project, but has an LMDB link which leads to
Which finally explains:
> Symas LMDB is an extraordinarily fast, memory-efficient database we developed for the OpenLDAP Project. With memory-mapped files, LMDB has the read performance of a pure in-memory database while retaining the persistence of standard disk-based databases.
> Bottom line, with only 32KB of object code, LMDB may seem tiny. But it’s the right 32KB. Compact and efficient are two sides of a coin; that’s part of what makes LMDB so powerful.
There's also a wikipage:
https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...
Re: Up to date Rust bindings for LMDB
#7For those of us who don't know, LMDB is a DB, somewhat akin to sqlite or Berkeley DB. It took a bit of time to find the info by chasing links. Please add READMEs to your projects with appropriate links, folks. https://crates.io/crates/liblmdb ... which links to the repo https://github.com/ordinarylabs/liblmdb Which has a link to the LMDB repo here (just a submodule) ... https://github.com/LMDB/lmdb/tree/9c9d34558cc43…
Funny how people use the web differently :)
I also saw "LMDB", didn't knew what it was, searched LMDB on Kagi, got https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa... as the first hit. Bing and Google also has it in the top, seems to be relatively known.
Re: Up to date Rust bindings for LMDB
#8not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help. some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not u…
LMDB Python maintainer here. 0.9.70 is not really the latest release. It isn't binary compatible with official "releases" though it has sneaked out in a few bindings.
Latest is 0.9.31.
Re: Up to date Rust bindings for LMDB
#9What kinds of use cases do you all use LMDB or other key-value stores for? I can somehow never really find a good one. Almost all databases, no matter how trivial, will sooner rather than later need more features so I always reach for SQLite instead.
Still, I'd really like to make use of it. But for what? Caching?
Re: Up to date Rust bindings for LMDB
#10Earlier quoted context omitted.
> not sure why all the existing crates have gone so far out of date. Pure speculation on my part: maybe people are choosing Rust-based embedded key value stores like sled or redb?
Only slightly off topic, but any of these support fast concurrent writes? LMDB really slows down for me when I'm trying to write a lot to it and locking means i cant use concurrency to speed it up.
Batching helps, and if you can avoid syncing after every write that helps too. In practice I get great throughout, but then I’m OK with losing a small amount of data if my server dies during writes, as long as that doesn’t lead to corruption, which it doesn’t with MDB_NOSYNC and kernel guided fsyncing