Emmanuel Lecharny wrote:
Alex Karasulu wrote:
Hi all,
Hi Alex,
The ServerEntry stores the DN of the entry. I think this is good for better
code organization. However, storing the entry together with it's DN into
the master table is a very bad idea. The DN should instead be managed in
the NDN and DN indices.
I think you are wrong. Storing the DN within the entyr is a very good
idea (tm) :)
For what it's worth, in my experience Alex is right. OpenLDAP's back-hdb can
do subtree renames in O(1) time. It's the only LDAP implementation in the
world that can do this, and it's partly because we don't store the DNs with
the rest of the entry data. back-hdb is also the fastest at searches too, and
that's just a matter of balancing cache demands...
Again, this is shortsighted. You are focusing on extreme cases :
- server with 100M entries
- and applying a ModifyDN (a rare operation) which moves 100M entries
Anywya, you have a point here : ModifyDN will be awfully slow, just
because we will have to rewrite the entire master table. If you think
about what would have happened with the previous implementation, then
you would just have to rewrite the entire DN table. I would say it's
simply 2 or 3 times faster. Big deal ! We are not talking of order of
magnitude here.
To sum up the advantages of having the DN within the entry, I would say
that avoiding a lookup for the DN for a search will save a lot of time
(not order of magnitude), say, 20%, for _every_ search operation. I
don't think that people search using the DN often, compared to searches
using another attribute to get the entry.
Let's start a discussion if needed. We can ever add a switch on the
server to tell the server to store the DN within the entry or not,
depending on which kind of operation will be the most frequent one :
searches, or modifyDN with many children moved.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
