#LMDB #performance on #Optane #SSDs vs. #RocksDB but not other #databases
on 02023-07-04#LMDB benchmarks against other #databases; only #LevelDB is close in #performance, and still beats LMDB on writes (except batched sequential writes or writes of large values). This was when it was still called "OpenLDAP MDB". In particular it beats SQLite3 by generally about an order of magnitude and sometimes more.
on 02023-07-04#LMDB looks like an interesting point in the #databases design space: a zero-copy MVCC key-value transactional B+tree, similar to Berkeley DB, but writers don’t block readers, and new data doesn’t overwrite existing data
on 02023-07-04discussion of #performance in #databases and #mmap; author of #LMDB says read-only mmap and pwrite works well for LMDB. Also pcmulqdq explains where #LevelDB came from from their experience with the Bigtable folks. “Every HDD since the 1980s has guaranteed atomic sector writes.”
on 02023-07-04the #mmap = 💩 #paper #PDF. The problems for #databases are transactional safety (write ordering), I/O stalls (memory access blocks a process), error handling (all you get is SIGBUS, and you can't checksum your data on its way in and out), and #performance: “Specifically, we have identified three key bottlenecks that plague mmap-based file I/O: (1) page table contention, (2) single-threaded page eviction, and (3) TLB shootdowns.” Mentions #LMDB. In the paper they got better performance, even for reads, with O_DIRECT and pread, but I think that doesn't generalize to arbitrary numbers of reader processes.