Klaus Malorny wrote:
LMDB seems to be quite the right database I am looking for in order to speed up
my application. However, I still need to figure some things out. While I could
get many answers to my questions by skimming through the archive, the following
things are still unclear to me, and it would be quite nice if someone could
- in the documentation, I saw two limits: the key is limited to 511 bytes
(by default) and the data is limited to 16777215 bytes. Is this correct?
No, the data size is limited to 4294967295 bytes.
For larger data sizes, is the data still maintained in one
block, so that the application can still access it directly without any
need of copying within LMDB?
Or it is better to split larger data into
multiple key/value pairs?
Depends on your environment. It is a requirement that a single value actually
fits in the system's RAM.
- I discovered the return code "MDB_TXN_FULL". By what means are transactions
limited? I might consider to use few, but quite large transactions dealing
with hundreds of thousands key/value pairs to be created, updated or deleted
in some circumstances.
The limit has mostly been removed, although large transactions will probably
have a performance penalty.
- I saw the discussion about the predefined database size, and that
recommended to use a never-to-be-reached size and to rely on the sparse file
capabilities of the underlying OS. If I would not want to go this way:
Is it correct that if I encounter an "MDB_MAP_FULL" return code, it
would be sufficient to abort the current transaction, resize the database
using mdp_env_set_mapsize and repeat the transaction?
Yes, as long as you follow the other restrictions on changing the size.
Thanks in advance and regards,
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/