What is special about internal design of LMDB? -
what performance difference (reads/writes) between c++ implementation of in-memory b-tree (for example google btree) , lmdb (without taking consideration feacures of lmdb such transactions, isolation, shared access etc.)?
this 2014 lmdb design presentation architect howard chu covers design , tradeoffs of lmdb.
to summarize: lmdb copy-on-write, bottom-up updated, double-buffered, b-tree implementation favors simplicity whenever clashes other considerations.
the smart design choices make 1 of highest performance , corruption-resistant b-tree implementations out there.
- copy-on-write means data never overwritten avoiding many possible corruption scenarios
- bottom-up updates leaf root make root update equivalent commit
- double buffering of past versions keeps last-two roots in db file
- complex multi-level caching schemes avoided -
lmdbrelies on underlying os caching - the whole code base small compared other dbs avoiding cpu cache misses
obviously, these choices mean lmdb not friendly complex scenarios such as:
- multi-version db rollbacks (only last 2 available)
- long-lived transactions , delayed commits: these lead append-only behavior , potentially unlimited growth of db file
- multiple concurrent writers:
lmdbfavors simpler multiple readers , single writer schemes
there's more in full (over 100 pages) presentation. above summary of spirit of lmdb.
lmdb used core storage engine in prominent open source projects such open ldap , memcached , in both cases speed-ups of orders of magnitude have been observed compared alternatives can seen in micro-benchmark results.
Comments
Post a Comment