[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LMDB internals questions
- To: Valerii Hiora <valerii.hiora@gmail.com>, OpenLDAP Technical <openldap-technical@OpenLDAP.org>
- Subject: Re: LMDB internals questions
- From: Howard Chu <hyc@symas.com>
- Date: Sat, 04 Oct 2014 21:10:03 +0100
- In-reply-to: <542F9BDD.8080806@gmail.com>
- References: <542F9BDD.8080806@gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 SeaMonkey/2.27a1
Valerii Hiora wrote:
Hi Howard,
I have a couple of questions regarding LMDB.
In the future, please send questions to the openldap-technical mailing list.
1. MDB_INTEGERKEY
Setting this option requires all keys to be the same size, typically
sizeof(int) or sizeof(size_t)
It is unclear from this description if size of the key depends on arch
or the only requirement is to have all keys to have same size. Is it
possible use i64 keys independent of arch?
The documentation is precise - if the actual word size mattered, we would say
so. You can use 64 bit integers on any arch. You could use 16 bit or 128 bit
as well, it makes no difference.
2. MDB_DUPSORT - how is it organized internally, i.e. which are
penalties of having big number of items for one key. And how
cheap/expensive is cursor count operation for a key?
This is already documented - the values of a dupsort key are their own
sub-database. Cursor count just returns md_entries of the subDB.
3. Multiple databases
Currently a moderate number of slots are cheap but a huge number
gets expensive: 7-120 words per transaction, and every mdb_dbi_open()
does a linear search of the opened slots.
So if the space isn't a problem and mdb_dbi_open() is called only once
and returned handle is kept - are there any other penalties for multiple
dbs? Can you also specify "moderate number of slots" to have a better
understanding?
You should understand "moderate" as it applies to your own situation. We state
quite clearly it does a linear search - you can see how the cost adds up.
There are no costs other than those we have documented.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/