Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.161.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        b=NPf6ap6SOw961U0TFWG+icMrv93U0GKSRAvhKSsAiII0ATlFikpj/KM/8SeeE7hq+S
         s1l+HzJFlNwRfOkn7str4YnFJEMjiWyKxmmqeD8cth6sYr+na9y9+zHrJWraaycLqj/v
         3oxD5fT+/wSZ7vtp4F/SNLnY6o8xvmQ7YrJu8=
MIME-Version: 1.0
Sender: akarasulu@gmail.com
Date: Sat, 8 May 2010 10:43:23 +0300
Message-ID: <AANLkTinyIgLJ_lflgnlgqFRTMGDt40z4uVUKD11kI_HN@mail.gmail.com>
Subject: [ApacheDS] [XDBM Partition] Using a global UUID instead of partition
	specific Long ID PK
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: multipart/alternative; boundary=001485f95ffa968be5048610543e

--001485f95ffa968be5048610543e
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

Any thoughts about using the globally visible UUID in the XDBM partition
design for the primary key for Entries instead of using a partition specific
 Long ID?

I'm thinking we need one day to implement certain features. Let me list then
and also point out why using the globally unique UUID might be advantageous:

(1) System wide DN and Entry Cache

      Rather than having each partition manage it's own cache a central DN
and Entry cache makes sense. In this case a global identifier for an entry
might come in handy for hashing cached values.

(2) Nested Partitions, Default Root Partition, Hash Partitioning and Range
Partitioning

      At some point we will want to have nestable partitions. This means we
can have one ADS Partition mounted under another ADS Partition with
operation routing taking place properly to the nested partition where
appropriate.

      Nested partitions will also allow us to also have a default root
partition from which we can mount other partitions.  The default root
partition is nice to have since it allows us to add administrative areas and
their administrative points with subentries onto the root empty string DN.
 It also makes it so the RootDSE is now stored in this partition properly
with persistence.  Right now the RootDSE is generated and not mutable.

      Hash partitioning and range partitioning entails distributing entries
across partitions under some container entry based on some value. Hash
partitioning uses the value's hash to distribute entries where as range
partitioning uses ranges of values to distribute the entries.  So it's not
really the DN that determines which partition the entry is pushed into but
this hash or range value. This makes it so we can scale to very large
numbers of entries in the DIT while also distributing the disk access load
across several disk spindles as does Oracle's RDBMS in these kinds of
configurations.

(3) Global Indices

      If we use a globally unique UUID instead of a partition specific Long
ID then we can expose index segments managed by partitions to higher layers
to construct global indices.  These global indices can then be used to
conduct searches outside of the partition one step higher.  This makes it
possible for us to implement certain virtual directory strategies
irregardless of the partition implementations used in a server's
configuration.  The XDBM search algorithm can leverage these global indices
or delegate sub partition search to a partition if a partition uses it's own
search mechanism.  There's a lot to be said here but this is neither the
time or the place to expand on this topic. But global indices is a key
factor for several things including virtualization.

Thoughts?

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

--001485f95ffa968be5048610543e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div><br></div><div>Any thoughts about using the globally visible UU=
ID in the XDBM partition design for the primary key for Entries instead of =
using a partition specific =A0Long ID?</div><div><br></div><div>I&#39;m thi=
nking we need one day to implement certain features. Let me list then and a=
lso point out why using the globally unique UUID might be advantageous:</di=
v>
<div><br></div><div>(1) System wide DN and Entry Cache=A0</div><div><br></d=
iv><div>=A0=A0 =A0 =A0Rather than having each partition manage it&#39;s own=
 cache a central DN and Entry cache makes sense. In this case a global iden=
tifier for an entry might come in handy for hashing cached values.</div>
<div><br></div><div>(2) Nested Partitions, Default Root Partition, Hash Par=
titioning and Range Partitioning=A0</div><div><br></div><div>=A0=A0 =A0 =A0=
At some point we will want to have nestable partitions. This means we can h=
ave one ADS Partition mounted under another ADS Partition with operation ro=
uting taking place properly to the nested partition where appropriate. =A0<=
/div>
<div><br></div><div>=A0=A0 =A0 =A0Nested partitions will also allow us to a=
lso have a default root partition from which we can mount other partitions.=
 =A0The default root partition is nice to have since it allows us to add ad=
ministrative areas and their administrative points with subentries onto the=
 root empty string DN. =A0It also makes it so the RootDSE is now stored in =
this partition properly with persistence. =A0Right now the RootDSE is gener=
ated and not mutable.</div>
<div><br></div><div>=A0=A0 =A0 =A0Hash partitioning and range partitioning =
entails distributing entries across partitions under some container entry b=
ased on some value. Hash partitioning uses the value&#39;s hash to distribu=
te entries where as range partitioning uses ranges of values to distribute =
the entries. =A0So it&#39;s not really the DN that determines which partiti=
on the entry is pushed into but this hash or range value. This makes it so =
we can scale to very large numbers of entries in the DIT while also distrib=
uting the disk access load across several disk spindles as does Oracle&#39;=
s RDBMS in these kinds of configurations.</div>
<div><br></div><div>(3) Global Indices</div><div><br></div><div>=A0=A0 =A0 =
=A0If we use a globally unique UUID instead of a partition specific Long ID=
 then we can expose index segments managed by partitions to higher layers t=
o construct global indices. =A0These global indices can then be used to con=
duct searches outside of the partition one step higher. =A0This makes it po=
ssible for us to implement certain virtual directory strategies irregardles=
s of the partition implementations used in a server&#39;s configuration. =
=A0The XDBM search algorithm can leverage these global indices or delegate =
sub partition search to a partition if a partition uses it&#39;s own search=
 mechanism. =A0There&#39;s a lot to be said here but this is neither the ti=
me or the place to expand on this topic. But global indices is a key factor=
 for several things including virtualization.</div>
<div><br></div><div>Thoughts?</div><div><br>-- <br>Alex Karasulu<br>My Blog=
 :: <a href=3D"http://www.jroller.com/akarasulu/">http://www.jroller.com/ak=
arasulu/</a><br>Apache Directory Server :: <a href=3D"http://directory.apac=
he.org">http://directory.apache.org</a><br>
Apache MINA :: <a href=3D"http://mina.apache.org">http://mina.apache.org</a=
><br>To set up a meeting with me: <a href=3D"http://tungle.me/AlexKarasulu"=
>http://tungle.me/AlexKarasulu</a><br>
</div>

--001485f95ffa968be5048610543e--