Hacker News new | past | comments | ask | show | jobs | submit login

Your point eludes me? For a start that is not tuning it. It is still using synchronous IO



Note that the LevelDB, Kyoto Cabinet, and SQLite3 configs are identical to what the Google LevelDB authors used in their original benchmark. http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html

The only thing different about the Symas LMDB tests is that LMDB and BDB were added.


Did you look at http://symas.com/mdb/microbench/db_bench_sqlite3.cc?

Search for 'write_sync'


Ahh yea i missed, apologies

     std::string sync_stmt = (write_sync) ? "PRAGMA synchronous = FULL" :
                                           "PRAGMA  synchronous = OFF";

Still. how is it a valid compare if it is getting it to ssd/hdd and the others are writing to memory? Just open sqlite3 with :memory:


You're still not understanding. LMDB is a disk-based database. It is not only writing to memory.


MDB in those stats is writing to disk? I assume its some kind of lazy write though where the memory store is eventually persisted? in that case thats fairly impressive for a lot of use cases. Though a k/v store has a lot less to do than something like sqlite3.

I'll look into it (never heard of it before). Might fix fairly well with something I'm working on right now (currently implemented using sqlite3).


In fully synchronous mode, which is LMDB's default mode, everything is persisted upon commit. This is a memory-mapped database, not a main-memory/in-memory database. It is fully persistent to disk, it just so happens that it uses mmap() instead of read()/write() and a user-level page cache.

People are always confusing "memory-mapped" with "memory-only". LMDB is not a memory-only database.

http://www.openldap.org/lists/openldap-devel/201111/msg00064...


I guess (as i did) assumed it meant memory-mapped I/O as opposed to something like memory-mapped file I/O or port mapping.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: