[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LMDB vs FastDB
Tobias Oberstein wrote:
Am 21.03.2013 21:58, schrieb Howard Chu:
Tobias Oberstein wrote:
Hello,
I have read the - very interesting - performance comparison
http://symas.com/mdb/microbench/
I'd like to ask if someone did benchmark LMDB (and/or the others)
against http://www.garret.ru/fastdb.html
FastDB is an in-memory ACID database that works via shadow paging, and
without a transaction log.
OK, like LMDB it uses shadow root pages. I think the similarity ends there.
Ah. Ok.
It is a relational database with an ASCII query language, while LMDB is
strictly a key/value store. That automatically means for simple get/put
operations LMDB will be orders of magnitude faster (just as it is so
much faster than SQLite3 and SQLite4).
Mmh. The overhead of parsing a "SELECT value FROM kv WHERE key = ?" or
executing a prepared version of the former versus a direct "kv.get(key)"
is there, sure, but _orders_ of magnitude larger?
Measure it for yourself and let us know, if you have any doubts.
Btw: could LMDB be used as a backend of sqlite4? I.e. does LMDB support
ordered access?
Yes. We have that already under way.
FastDB is also written in C++ which is another inherent disadvantage
compared to LMDB which is pure C.
Yes, though I'm a C++ fan, I agree with this point. E.g., here is a nice
Python wrapper
https://github.com/dw/py-lmdb/
which interfaces using Cython and wouldn't be possible if LMDB would be C++.
Exactly. If you want to write a tool that's useful, don't choose a language
that automatically precludes other uses. People writing libraries in Java,
this means you. (e.g. SimpleDBM, which I stumbled on a few years ago while
looking into B-link trees. http://code.google.com/p/simpledbm/)
You could adapt the LevelDB microbenchmarks to test it but ultimately I
believe it would be a waste of time.
Thanks for your detailed answer and sharing information! It seems LMDB
deserves much more visibility in the community.
Totally. I've been hitting every relevant conference that comes my way.
http://symas.com/mdb/
but there's only so much time, and travel interferes with development. As is
so often the case in OpenLDAP, huge numbers of people/projects use our work
but very few publish their success stories.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/