Brett Shirley wrote:
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.
Yes, it was intended to be silly.
http://snltranscripts.jt.org/76/76aphonecompany.phtml
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 ...
That could be interesting to see, but the results would only be relevant to
someone developing for Windows. Unless Microsoft plans to release ESE-based
products for Unix, or decides to open up the ESE source code.
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.
Yes, that post gave me a good laugh. The thought of leaving a little server
chugging away in a closet for a month somehow reminded me of a lost pet. I
decided to try the same thing; it took 6 days to slapadd a database with 5
billion entries on my test machine. (I thought about locking it in a closet
too, but better judgement eventually prevailed...)
Did you really want to quibble over whether it's 31 or 32 bits? Is a given
Win32 app really a 31-bit app just because it uses signed integers? The word
size is what it is. And the fact is, there are OpenLDAP deployments in use
around the world today that are well above the size a 32 bit software
architecture can handle. Microsoft talks a good game about enterprise-ready
server software, but the truth is something else entirely.
Given that it takes 24 hours to load 5 million entries into AD, and assuming
that the load rate is constant at that point (instead of exponentially
decaying, which is a more accurate characterization of its real performance)
it would take 858 days to load 4 billion entries. That's nearly 2 and a half
years. Of *course* nobody has hit your limit in production, their systems
would fall apart long before then.
But we've got servers sustaining 12,000 writes per second on cheap commodity
disks. They go through 4 billion entry IDs in a matter of 4 days, and they
don't stop.
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?
Simply by creating a database with 512 entries, and observing the order in
which they're returned when you read them back out. It's not hard.
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?
Go ahead and try it. I was using Windows Server 2003 x64. use ldifde or
whatever tool of your choice to create an ADAM directory with exactly 512
entries. (I didn't bother trying this with AD, all of the pre-loaded entries
makes it too hard to count.)
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 +0000
[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/msg00002.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
Sun http://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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://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.
