ldb speed

[Luke Howard]

A couple of other things you could do (if you don't already):

(a) just store the RDN (relative distinguished name). This makes searches
potentially more expensive but makes subtree renames very cheap. As Ed
Reed once said (probably not in these words), who would use a filesystem
in which the complete path was stored with every file?

(b) if you are going to store the DN, store a normalized DN (for matching)
as well as the preserved DN (for reading).

In OpenLDAP, back-hdb does (a), back-bdb (b). (Actually, back-hdb would do
(b) for the RDN too I expect.)

Another thing is that at some point the data store layer needs to have some
degree of schema-awareness. I'm not sure how much you have today (please
tell me to shut up if I should just go and look at the code!).

For example, a common myth is that DNs are case-insensitive; in fact, it
depends on the matching rules associated with the naming attributes in each
RDN. So to accurately compare a DN you need schema-awareness. Also, whilst
in LDAP everything is a (octet) string, it doesn't always make sense to use
strings as the underlying representation, although the desire to keep ldb
databases hand-editable might influence this.

Also, how do you deal with attributes that contain references? The classic
case is an attribute with syntax distinguishedName (like a group member),
but AD also has several syntaxes that can contain embedded DNs, such as
dnWithString, dnWithOctetString, and orName. You need to ensure that when
an entry is renamed that the references are updated. A common approach is
to store the reference as an entry ID or GUID (this buys you referential
integrity at a small performance cost, but is easily optimized). But then
in a distributed system it gets more complex, because you can't generally
afford a network query at dereference time, nor would you want that sort
of code inside the database layer. This is one of the more interesting
problems in building a distributed directory.

Hope this helps. I'm no database guru by any means but I have seen a lot
of directory servers over the years :-)

cheers,

-- Luke

--
www.padl.com | www.lukehoward.com