Howard,
A few things in your post, I'd like to correct ...
First regarding:
Microsoft Bloatware - Designed by People Who Just Don't Care.
I work for Microsoft, specifically I work on the ESE database (aka JET Blue)
engine which is used under Active Directory, and _I care_. To suggest any
organization of more than like 100 people is homegenous in care-i-ness, is just
silly.
Also let me say, I have strong respect for BDB, they are fast, fast, fast.
They acutally have some similarities to ESE in a couple ways. I wish our perf
testers would do comparisons of ESE vs. BDB because it would be very apples to
apples, in that both expose a fairly low level database model ... not held back
by some QP. ;-) But this is about LDAP, SLAPD and ADAM servers more
specifically ...
Second driving into the first half of your first paragraph in your link...
I noticed something familiar while looking at ldapsearch output from AD and
ADAM. Even
though their ISAM database uses B-trees for its indices, and they use
integers for their
primary keys (they call them DNTs, DN Tags, but they're essentially the
same as our
entryIDs, though theirs are fixed at 32 bits and ours are 64 bits on a 64
bit machine),
Mostly true ... ESE is an ISAM, and we use B+ Trees actually. And true AD /
ADAM do not use 64-bit DNTs, they're 32-bits, but not even quite that, because
they're signed integers and the DNTs start at 0, AD / ADAM only has 31-bits
available, giving a rough upper limit of only 2 B objects. Only 1 person has
hit this: http://blogs.technet.com/efleis/archive/2006/06/08/434255.aspx, and
that was a test. No one has hit this in production.
Third:
they don't preserve the entry input order. In fact, it looks like they're
passing their
4-byte integer keys directly to their B-tree routines in native
little-endian byte order,
which totally screws up the sorting and locality properties of the B-tree.
What is your support to make this claim about the ESE / ADAM database? How did
you conclude this?
First, AD doesn't have access to the ESE B-Tree routines directly, it has a
table with a integer (JET_coltypLong) auto-inc (JET_bitColumnAutoincrement)
column, see:
http://msdn2.microsoft.com/en-us/library/ms684167(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms684178(VS.85).aspx
From JET_coltypLong:
A 4-byte signed integer that can take on values
between -2147483648 and 2147483647. Negative values
sort before positive values.
ESE abstracts the process of normalization of column data into appropriately
sortable key data for B-tree insertion completely away from AD. ESE does
reverse the endianess of the DNT to make a key ... in fact we do even more than
that, since it is an integer we have to add a base value to it as well...
So a integer value of 10 becomes a key of:
7F 80 00 00 0A
And an integer value of 266 becomes a key of:
7F 80 00 01 0A
So ESE and ADAM does not suffer from fundamental design flaw you describe.
What is your support to make this claim about the ESE / ADAM database?
Thanks,
BrettSh [msft]
ESE Developer
-Original Message-
From: Howard Chu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 27, 2008 9:28 PM
To: LDAP list
Subject: [ldap] Re: Active Directory as a general purpose directory service
From: Gavin Henry[EMAIL PROTECTED]
Date: Wed, 27 Feb 2008 21:13:39 +
[EMAIL PROTECTED] wrote:
I have seen several companies using AD (usually AD/AM, but sometimes
AD as a separate domain) as an enterprise directory service.
And here
http://www.openldap.org/lists/openldap-devel/200711/msg2.html
which describes one of the fundamental design flaws in AD's database.
Microsoft Bloatware - Designed by People Who Just Don't Care.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To
unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
