On 18/07/2013 20:34, highland...@gmail.com wrote:
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.
First you need to distinguish SQLite (3 or 4) from the others, which are simply
key/value stores. Do you really need complex multi-column tables and complex
SQL queries for managing your data? I don't see why; you would probably do much
better with just a K/V store.
With interchangeable engine in SQLite4, you would also get the key/value
store engine, accessible from the outside. And you can choose the one
you like more. So you can build a wrapper for SQL, and a key/value API,
out of a single library.
Yes, in some cases we need complex SQL queries, it's not mandatory
clearly, but helps maintainability of some features (the awesomebar for
example). And in some case we also need FTS. Surely it's not many
cases, but we already reduced a lot our "fancy" database usage.
Definitely we need both options and to be wise when making a choice.
LMDB is protected from all of these problems. It uses a read-only memory map,
so stray pointer writes will kill the app with SEGV, nothing corrupts the data
on disk.
Thanks, that's interesting information.
Yes, but SQLite4 is very very far away from ready for public consumption. The
storage engine interface is pretty simple, plugging LMDB in is trivial. But
until the frontend work is done (query optimizers and all that) it's not going
to do anyone any good.
That's something we can have a very positive influence on, if we'd ever
decide to start using it. Their test harness is also quite good.
-m
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
