LMDB comparison benchmark improvements

[Kerollmops]

In this PR, I introduce the compaction of the LMDB database. It requires compacting the data into another file and reopening the environment afterward.

The following results were run on my iMac M3 computer. I do not understand how the individual writes of LMDB and RocksDB are so low compared to the README you provided on GitHub 🤔

	redb	lmdb	rocksdb	sled	sanakirja
bulk load	2652ms	1513ms	8188ms	7168ms	1346ms
individual writes	405ms	7ms	4ms	426ms	68ms
batch writes	4880ms	2776ms	324ms	1338ms	4478ms
len()	0ms	0ms	273ms	727ms	54ms
random reads	1051ms	1130ms	3251ms	1484ms	1293ms
random reads	1034ms	1117ms	3113ms	1488ms	1271ms
random range reads	2538ms	1651ms	5648ms	5844ms	1820ms
random range reads	2524ms	1658ms	5655ms	5909ms	1827ms
random reads (4 threads)	370ms	333ms	1281ms	516ms	623ms
random reads (8 threads)	247ms	179ms	787ms	385ms	778ms
random reads (16 threads)	245ms	172ms	800ms	338ms	790ms
random reads (32 threads)	239ms	163ms	583ms	322ms	772ms
removals	4124ms	1221ms	3042ms	2234ms	1236ms
compaction	2077ms	114ms	522ms	N/A	N/A
size after bench	311.23 MiB	283.01 MiB	106.26 MiB	445.50 MiB	4.00 GiB

[cberner]

I do not understand how the individual writes of LMDB and RocksDB are so low compared to the README you provided on GitHub 🤔

Ah ya, that's probably a bug in the durability of LMDB & RocksDB on OSX. On OSX you need to call libc::fcntl(fd, libc::F_FULLFSYNC) instead of msync / fsync -- std::File does this correctly. I fixed a similar issue with sled here:

redb/benches/common.rs

Line 309 in 8d0859b

// Workaround for sled durability

Looks like I need to add similar code for lmdb & rocksdb

[Kerollmops]

Ah ya, that's probably a bug in the durability of LMDB & RocksDB on OSX. On OSX you need to call libc::fcntl(fd, libc::F_FULLFSYNC) instead of msync / fsync -- std::File does this correctly. I fixed a similar issue with sled here:

redb/benches/common.rs

Line 309 in 8d0859b

// Workaround for sled durability

Looks like I need to add similar code for lmdb & rocksdb

Wow! Shouldn't this be directly fixed in LMDB and RocksDB source code? It seems to be a real issue, right? If you commit and you cannot be sure it's durable.

I'm wondering what @hyc thinks about this?

[Kerollmops]

Ho! BTW @cberner, you forgot to update the README 😅

[hyc]

Ah ya, that's probably a bug in the durability of LMDB & RocksDB on OSX. On OSX you need to call libc::fcntl(fd, libc::F_FULLFSYNC) instead of msync / fsync -- std::File does this correctly. I fixed a similar issue with sled here:

redb/benches/common.rs

Line 309 in 8d0859b

// Workaround for sled durability

Looks like I need to add similar code for lmdb & rocksdb

Wow! Shouldn't this be directly fixed in LMDB and RocksDB source code? It seems to be a real issue, right? If you commit and you cannot be sure it's durable.

I'm wondering what @hyc thinks about this?

Looks legit, feel free to open a ticket on bugs.openldap.org with the patch. Thanks.

[Kerollmops]

For your information, @cberner and Howard 👋

I proposed a patch to LMDB to be applied to the mdb.master and mdb.master3 branches.

Thank you again for the information and for the help cberner,
very appreciated 💟
kero