Alex Karasulu wrote:
Some operations in the default partition based on JDBM would gain a
performance advantage if we could stuff the (partition unique) Long id
associated with the entry into the ServerEntry object.
Are you sure? From the top of my head, I don't see how having such a
value within the ServerEntry object could help. Do you have an exemple ?
(I'm not saying that it's a bad idea, I just can't see where it can
help. Btw, it would be a no brainer to add such a field)
Eventually some schemes we discussed in the past for making this Long
id a server unique rather than partition unique identifier will come
to pass. At that point we can rapidly compare entries based on this
identifier. Besides the id we will probably eventually have the UUID
which is globally unique for the entry across server instances.
However the UUID costs more to compare than a long which can be
compared in just a few JVM operations.
We need this UUID at some point. It's already used for replication, and
can be set in any case, as an operational attribute, with a different
handling : I suggest it's not set as an attribute internally, or at
least that we have a direct access to this value without having to look
into the EntryAttribute list. Something like :
class ServerEntry {
ServerEntryAttribute attributes;
UUID uuid; // May be duplicated with the opattr into attributes
...
}
Until we make it server unique this id parameter can only be leveraged
inside a partition, it cannot be used externally until we devise some
of these schemes discussed in [0] regarding 8 to 16-bit embedded
partition identifiers inside this Long.
Even if we dedicate some few bits to the partition 'name', with a long,
we can still deal with much more potential entries than we can possibly
store on a disk, considering that an entry will be at least 100 bytes long !
For instance, if we split the ID in two 16 bits values, this still leave
4 billions entries that can be added, around 400 Gb of data...
A partition can be set on 8 bits - so we can handle as many as 255
partitions, considering that partition 0 is ou=system -, more than
necessary, I think. This leave more than 18 peta entries which can be
stored... I would dedicate 16 bits to describe the partition (65 555
possible partitions, 2^48 entries)
This has to be discussed...
Any thoughts on exposing this ID and associating it with a ServerEntry
via an 'id' property on this class now rather than waiting for [0] to
be implemented?
---------
[0] -
http://cwiki.apache.org/confluence/display/DIRxSRVx11/Master+Table#MasterTable-partitionid
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
