Like BerkeleyDB, and unlike most other key/value stores around today, #LMDB is more than just a simple K/V store. Its support for multiple tables, and txns spanning multiple tables, lets you implement other features like 2ndary indexing, metadata storage, etc., that ordinary K/V stores just can't do. Here, #HarperDB describes how they designed their data model on top of LMDB https://docs.harperdb.io/docs/technical-details/reference/storage-algorithm
YuDB - embedded database using mmap, inspired by #LMDB, with different tradeoffs to improve write perf (but at the cost of 2x slower read perf) https://github.com/yuyuaqwq/yudb
So while he's doing extra administrative work (fine tuning to search for safe memory allocation parameters) he's getting orders of magnitude slower performance using #InnoDB than #LMDB, and none of the crash reliability that he claims to value. http://www.lmdb.tech/bench/memcache/
(Note that they claimed to have found 1 flaw in #LMDB that occurred in 0.05% of their test runs, but it was actually a bug in the ext3 fs driver. One that had been fixed in Linux 2+ years before they began their research. In fact LMDB's reliability is flawless.) LMDB is the only DB that is perfectly crash-proof.
Despite having the slowest single writes, LMDB has the fastest bulk load speed. This is no accident; while we don't worry too much about runtime write perf, we absolutely want to get a freshly reloaded server up and running ASAP, and fast bulk load enables that. #rustlang
Just discovered : #ziolmdb next & previous operations also work with any identifiers even not in use ones, #lmdb will just peek the nearest one ! As https://github.com/dacr/sotohp#sotohp is using #ULID (time based) I'll get instant move to any date for free :) Going to add a #javafx#scalafx time navigate UI component
There's an art to debugging with print statements. You need to show enough to be able to identify problems happening, without being so verbose as to overwhelm with useless noise. When #LMDB is built with debug logging enabled, the output can be too voluminous to sift thru.
But it shows exactly what the code is doing, in such a way that you can parse the log and rerun the exact same operations, and get an identical database as a result.