On 06/07/2013 11:26, Philip Chee wrote:
"LMDB is an ultra-fast, ultra-compact key-value data store developed by
Symas for the OpenLDAP Project. It uses memory-mapped files, so it has
the read performance of a pure in-memory database while still offering
the persistence of standard disk-based databases, and is only limited to
the size of the virtual address space, (it is not limited to the size of
physical RAM)."
It looks like LMDB has speed and size advantages on memory constrained
systems like Android and B2G.
Ehr, I wrongly replied instead of following-up, let me paste again:
As for many other dbms around, comparisons are pretty much hard, just
relying on microbenchmarking doesn't help much. What's best, LMDB,
levelDB, kyotoCabinet, Sqlite4? It's hard to tell just by looking at
these graphs, you'd need measurements done directly on your most
compelling use-cases. Just getting those measures is a project by itself.
Then there's the cost of conversion and added code size, for which
Sqlite4 may be a winner, considered we'd need less changes and we'd
likely have more code reuse from Sqlite3.
Then there's memshrink, I couldn't find the maximum and average used
memory in the reported benchmarks, we are currently using a max of 2MB
per DB connection, would it be comparable?
I finally wonder how they solved the problem of mmap corruption, also
Sqlite can use mmap IO, and it may be up to ten times faster, but has no
protection for memory corruption due to stray pointers or buffer
overflows in the application.
So, it's definitely an option to consider when we decide to start
working on a new generic storage, but we need far more details to be
able to properly evaluate.
Fwiw, Sqlite4 will support swappable engines, so you can use lmdb as the
Sqlite4 engine, and a backend is already under development from what I
read on the lmdb page.
-m
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform