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.