[ldng]

I did not delve into the details as you might have, but whenever I see mmap associated with huge perf I tend to wonder about corruption. I've seen to many bench comparing ondisk stores with in mmap stores flushed to disk one in a while. Then you need extra steps/configs to get good enough reliability that hinder perf.

[jules]

That's certainly a possibility but I'll have to assume that they are running with the same durability guarantees unless proven otherwise :)

[hyc_symas]

Correct. In synchronous mode full ACID semantics are guaranteed. Writable mmap avoids memcpy()/write() overhead but msync() is still performed.

[snaky]

>whenever I see mmap associated with huge perf I tend to wonder about corruption

If that was the case with lmdb implementation, that works as OpenLDAP backend all over the world, most probably you would have heard about it from the news.

[ldng]

You've have a point. But then, it's a bench mark and it would not be the first time that a bench is done using different settings than in production. Like I said, that lmdb is used in OpenLDAP doesn't automatically mean it is used with the exact same configuration as in the benchmark ;-) Nor did I say a memory store is bad, it's just you're not comparing the same things. Redis could be added to the bench for instance.

[hyc_symas]

IMO main-memory stores are bad, for multiple reasons. LMDB is not a main memory store, it is a fully ACID-compliant transactional store.