[Mavibot] Headsup

[Emmanuel Lécharny <el...@gmail.com>]

Hi guys,

let me give you a quick sumary of mwhat I'm on those days :

1) I have changed the way we handle Values and Keys in Mavibot, in order
to avoid useless deserialisation when loading a Leaf or a Node from
disk. This is critical because loading a leaf with, say, 12 values in
it, means we were deserializing the 12 values, even if we just need to
fecth one.
The same thing has been done for keys, as we may just need to manipulate
log(N) keys.
Those modifications are critical when we have not enough memory to store
lots of pages, and when we frequently discard pages.

This is a done task, and it works pretty well.

2) I have modified teh way we handle multiple values. Now, we store them
either in a array or in a BTree. The rational is that most of the time,
we won't have many duplicate values. The number of values after which we
switch from an array to a BTree is to be configured (not yet done).
Atm, I have not yet implemented the BTree, but as Kiran did it already,
I will just use the code he produced.

3) It's critical to use sub-btrees when we have many values. For
instance, when we store many entries with a InetOrgPerson ObjectClass,
the ObjectClass index will references all the entryUUID of all entries
having this ObjectClass. With 10 000 entries, this is 10 000 UUID we
have to store as values, and every time we add or remove an entry, we
have to copy the pages containing those 10 000 values. Just overkilling
(FTR, we need roughly 500 000 bytes to store those 10 000 UUID, this is
1000 pages of 512 bytes. That means we have to fetch 1000 free pages
from the disk, and to update the recordManager header 1000 times. Using
a sub-btree would just requires 5 new pages pages...)

This is the task I'm on atm

4) I'm not anymore using ByteBuffer : it's also overkilling.

So far, so good, we are making good progress, and I hope to be done this
week.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com