Russell Haley wrote:
Hello,
I wasn't fully subscribed when I sent this so I'll send it again.
Any input or reference hints would be great. I love reading manuals. :)
Russ
---------- Forwarded message ---------- From: Russell Haley russ.haley@gmail.com Date: Tue, Sep 20, 2016 at 4:52 PM Subject: Using lmdb as a pure in memory store To: openldap-technical@openldap.org
Hi there,
We are currently evaluating in memory key value stores for ~100,000 - 200,000 records in an embedded system. I suggested lmdb but it is being discounted for some reasons I thought I'd validate:
- It is currently thought that a on disk file is REQUIRED for the
system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a pure in-memory database? Could the file not just be mapped to a memdisk?
A file is required. Whether the file is on-disk or not is irrelevant. It can of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it pure in-memory.
MDB_NOSYNC turns off syncing, that's why it is named that.
- Because these values can come very fast, that the use of a lock
file would cause delay and too much wear on the nand based disk (SSD).
No. That's not how the lock file is used.
I see a no locking option ( MDB_NOLOCK) that would stop a lock file being written.
This option should only be used if you're implementing your own lock manager. Hint - no matter what approach you use, any other lock manager you use will be slower than LMDB's.
Again, another option would be mapping the lock file to a memdisk to handle that?
Yes.