Vladan Djeric wrote:
- Also be careful about using SQLite
<https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature>
Definitely good advice. SQL is way overkill for most common storage
needs. A Key/Value engine may be too simple, at the opposite extreme.
It's worthwhile to think about what data is being stored and what data
model is actually most suitable for it. E.g. the config system consists
entirely of hierarchical keywords - this is ill-suited to an RDBMS but
is a natural fit for a hierarchical data model like LDAP/X.500. It would
be worthwhile to explore the Samba project's LDB API, which lets you
transparently use the LDAP data model either with a local DB file or
with a socket to an LDAP server. This gives you hierarchical storage and
the power of LDAP search filters, making life much more convenient than
a simple K/V store, but without all the bloat of SQL.
On the topic of SQLite itself, and tying into the mention of LMDB in
this thread, you may also want to check out my SQLightning fork
https://gitorious.org/mdb/sqlightning
Using LMDB as the underlying Btree engine removes a number of the
problems mentioned on that wiki page.
* LMDB uses no WAL or journal, so storage footprint issues are reduced
* SQLightning uses a hashed index, not full values
* LMDB uses no cache of its own. Since by default it uses a read-only
mmap, it can never hog memory in the face of system memory pressure. The
OS will simply mark its pages as unmapped if it needs them. (Clean pages
don't need to be written back to the filesystem, they can be reclaimed
and reused immediately, and all of the pages in a read-only mmap are
always clean.)
* LMDB is far more CPU efficient than all other DB engines. It is far
more battery-efficient as a consequence.
* LMDB requires zero DB maintenance
* LMDB has zero startup/recovery time. Unclean shutdowns are irrelevant.
* LMDB supports multithread/multiprocess access with no wasted memory
overhead.
I had a build of Seamonkey using SQLightning some months ago. It broke
recently and I haven't had time to investigate what changed in the
Mozilla code, but I'd guess it can be fixed up again easily enough.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
