12 Oct
2018
12 Oct
'18
11:23 a.m.
Hi Harald,
not
> 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 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