[ddorian43]

I like LMDB, but why does ~most sql/nosql use LSM/rocksdb compared to it ? At least the ones going for read-speed ? Cause of missing WAL ?

There is also a fork? who claims is better/more-features than LMDB: https://github.com/leo-yuriev/libmdbx

[espeed]

To understand the tradeoffs between LSMs, B-Trees, and Fractal Trees, see the references in this previous post on TokuDB and Bε trees...

* BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage https://news.ycombinator.com/item?id=18202935

Memory model considerations and storage architecture design gets even more interesting now that NVMe has become a thing. For example, in addition to LMDB, how much more interesting have things become for Redis on NVMe?

* Caching Beyond RAM: The Case for NVMe https://news.ycombinator.com/item?id=17315494

* Intel Optane DC Persistent Memory is officially in Google Cloud https://news.ycombinator.com/item?id=1834816

And there are a few new forward-thinking DB architectures emerging on the scene, some that have been in the works for more than 10 years. Look at the work being done by the Berkeley RISELab team and the architecture behind Fluent DB.

* Ground: A Data Context Service (2017) [pdf] (berkeley.edu), https://news.ycombinator.com/item?id=18415456

What might have been conventional wisdom in the realm of DBs years ago will not be the best practices of today. Architectures have changed too much.

And this is not just true for storage, it's true for compute too. The availability of CPU/GPU/TPU accelerators in the data centers is driving a rethink in compute toward parallel algorithms in the form of Vector/Matrix/Tensor multiplication. The best way to store and index these arrays is something to consider too.

[ddorian43]

Can these be used for async filesystem access (AIO) that seastar framework does ? (i don't think so for now)

At least it doesn't support mmap so removes lmdb.

[isaachier]

Google started the trend of LSM with its release of leveldb. But leveldb hasn't been updated in a long time. Facebook forked leveldb and renamed it to rocksdb. Those are the only two LSM databases I know of, and IMO they are really the same thing. Meanwhile, lmdb vs. rocksdb/leveldb is a frequently asked question that seems to have no clear answer. Test on your hardware to find the best solution for your use case.

[rakoo]

It primarily depends on your requirements, as a rule of thumb:

* If your workload is random-writes heavy, choose lsm

* If your workload is serial-writes heavy, both are similar

* If your workload is read-heavy (random or not) go for lmdb

[hyc_symas]

If your writes are larger than ~1/2 a page, LSMs are slower, regardless of random or sequential access pattern.

http://lmdb.tech/bench/ondisk/

Also, if your writes are mostly smaller than ~1/2 a page, you can reduce your B+tree pagesize and regain performance.

[erthink]

All improvements over LMDB are listed here = https://github.com/leo-yuriev/libmdbx#improvements-over-lmdb