LMDB key value backend for ldb_tdb (to be renamed ldb_key_val)

[Howard Chu]

From: William Brown <william at blackhats.net.au>
>> > re-thinking the overall architecture e.g. consolidating the
>> > partitions
>> > into a single file using LMDB sub databases.
> 
> There are some arguments both ways here I think.
> 
> Keeping them seperate means that you can easily identify any component
> that has a size blow out (specific index, changelog etc), and
> potentially resolve it. This is pretty nice for admins to be able to
> deal with. It also makes it easier to export/import large files to
> resize them (lmdb files can't be resized iirc). If you have a combined
> DB and it's say ... 8GB, then you have to have at least 8GB free to
> export and import to a new db. If this was spilt to many files (say
> 0.5GB each) it becomes easier to manage this.

mdb_stat will tell you the sizes of each subDB. You can use "mdb_dump -s" to 
export a specific subDB. And "mdb_drop -s" to delete a specific subDB. Not 
sure what you mean about "LMDB files can't be resized" - sure they can, that's 
what mdb_env_set_mapsize() does.

> However, joining these would be good for simpler transaction
> managament, especially to prevent deadlocking if tables are locked out-
> of-order. 

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/