RE: Unidentified subject! LDAP search times and databases

["Alexis Bor" <alexis.bor@directoryworks.com>]

Out of curiosity, have you tried this with a server that has, let's say
10,000,000 entries in it and trying to add entries with 100 or so
attributes?  How fast can you do that?  Cache management starts to get in
your way, since you won't have enough memory on your system, not to mention
specific operating system overhead that kicks in.

I did a couple of years ago and it left me wondering...And I hope that
people have looked into this since then...

-- Alexis

Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com

-----Original Message-----
From: Colin Robbins [mailto:Colin.Robbins@nexor.com]
Sent: Friday, June 09, 2000 4:26 AM
To: 'kfenley'; 'hahnt'; 'ietf-ldapext'
Subject: RE: Unidentified subject! LDAP search times and databases

>
> I know one only one LDAP Directory that overcomes all these
> issues and runs
> on an industrial strength backend DB which provides
> predictable sub-second
> searches, full rollback, auditing and logging and has 30+
> patents on the use
> of a RDBMS for Directories.

Sorry folks, I really don't like using this lists for vendor messages, but
OpenDirectory is not the only product in the world with an industrial
strength backed DB overcoming these problems.   There are several.

> This is why the other vendors
> who use RDMBS
> technology are unable to compete, as they have to use
> standard SQL calls.
> The Patents cover how you use a standard RDBMS as an OO D/B
> without the SQL
> row and Column problem and this is where the high search
> times from a RDBMS
> come from.

If I understand this correctly, you are saying you have several patents to
implement an OODB on top of a RDBMS.  The implication is you need an OODB to
implement an efficient LDAP Directory.

I certainly agree with the implication.  This is why at NEXOR we decided to
implement our Directory product using an industrial strength OODB from
Versant Technologies (http://www.versant.com).  This approach has all the
benefits you refer to, with the added advantage on not having the overhead
of mapping onto a RDBMS.

As to the original question posted - this approach of using an OODB, enables
us to manage "intense write" scenarios, with very little impact upon search
performance.   You only get a blockage if the attribute being modified, is
the target of a concurrent search and pointed to be the search index - the
DSA needs to wait for a read lock to check the attribute.  In our experience
this occurrence is rare.

Once again, sorry for using this list for a vendor message, but I fell
compelled to respond when I see messages suggesting there is only one good
product in the world.

Colin Robbins
NEXOR

Tel:  +44 115 952 0583
Email:  Colin.Robbins@nexor.com
WWW:  http://www.nexor.com