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

Reply via email to