Hi Harald,
It gives non-blocking access to the data - directly in-memory. Yet it
also
persists the data to disk in the background. So in case the software is restarted, it can pick off exactly where it left its dataset.
AFAICT from a very quick look at the source code, the writing-to-disk is
not
performed "in the background" but it is rather performed as blocking
write()
calls in the process/context at which the data is acessed?
We use it in MDB_NOSYNC mode. In practice this seems to result in no waiting for writes in the user thread at any point. Waiting for reads is never an issue because the LMDB design does not support reading from disk.
The LMDB benchmarks talk about many thousands of transactions per second. I can confirm that these benchmarks are not lying.
So to me, LMDB more looks like BerkeleyDB or SQLite but with a layer of
zero-copy
memory cache/access at runtime on top of it?
The cool thing about LMDB is that it has no cache, no layers. The "database" is an area of memory that the LMDB functions help access using key/value functions.
BR, Michael A