20080115 ldap vs rdbms - plembo/onemoretech GitHub Wiki

title: LDAP vs. RDBMS link: https://onemoretech.wordpress.com/2008/01/15/ldap-vs-rdbms/ author: lembobro description: post_id: 581 created: 2008/01/15 14:12:29 created_gmt: 2008/01/15 14:12:29 comment_status: open post_name: ldap-vs-rdbms status: publish post_type: post

LDAP vs. RDBMS

Just a friendly reminder:

_Re: sorry, another “LDAP vs RDBMS” question!

  • To: Phillip Rhodes
  • Subject: Re: sorry, another “LDAP vs RDBMS” question!
  • From: “Christopher E. Brown”
  • Date: Thu, 2 Mar 2000 09:35:44 -0900 (AKST)
  • Cc: “‘[email protected]’”
  • In-reply-to:

On Wed, 1 Mar 2000, Phillip Rhodes wrote:

I am building a ecommerce site that will integrate the products of 20+
companies into one single on-line order catalog. (Yeah, one of those
ecommerce pipe dreams for now) Because each individual company has
permission to update its products, view orders for its products, link
products to categories, the application has heavy duty access control
requirements. I want to put the whole system into a ldap directory. This
would include orders, customers, products, categories, etc. BUT, I keep
reading the people make the mistake of putting too much in ldap directory.
But I am enamoured with the beauty of this solution. I am looking for
someone to talk me into/out of it!

Repeat after me. A directory server is not a database
server. A directory server is not a database server. A directory
server is not a database server. A directory server is not a database
server. A directory server is not a database server. A directory
server is not a database server.

It sounds like you want to treate LDAP as a large RDBMS,
somthing it is not.

— As folks might have suspected, not much survives except roaches,
and they don’t carry large enough packets fast enough…
–About the Internet and nuclear war.
_

I may make this a “running post”, where I just jot down ideas as they come to me and then update here.

All kidding aside, there are some serious problems with trying to use an LDAP directory as a substitute for an RDBMS, or horror of horrors, several RDBMS’s. There’s not much lost going the other way around, except for one, possibly critical, factor. LDAP directories are (or can/should be) cheaper to acquire, deploy and manage than RDBMS’s. Well, at least for an enterprise. If you’ve got a small to mid-sized business that can only afford one of the two, I’d go with an RDBMS.

What LDAP excels in are really fast lookups of individual entries (i.e records). It is really in its element when it comes to servicing address books and other “white pages” type applications where you’re doing retrievals of data on a person or thing. It is famously inefficient when it comes to write operations, although real improvements have been made over time by people like the OpenLDAP folks and their supporters.

RDBMS’s, on the other hand, are built to handle bulk queries, and to efficiently do reads and writes, as well as joins of data contained in a multitude of records in separate tables. All modern RDBMS’s also offer rollback and other mechanisms to protect the integrity of the data they store.

LDAP directories, in addition to being inefficient for applications that need to do a high number of write operations, have serious performance problems when it comes to handling queries requiring the retrieval of large data sets, like “give me all the e-mail addresses for everyone in North America — now!”. It has been demonstrated in a lab environment that once the number of entries to be returned on a single query exceeds 5,000 in number, an LDAP directory server hits a big performance wall. For the most part this is not due to a limitation in the backend database (usually a variation on the Berkeley DB), but the LDAP protocol itself and the processing overhead it requires.

A good RDBMS is not going to have that kind of problem. But it does have others. First, the best of them are expensive to purchase. Even MySQL, although free to download, should not be deployed for a business without some level of paid support. Second, putting aside Oracle’s Internet Directory and IBM’s eDirectory (both of which use an RDBMS backend) for the moment, a typical LDAP directory has few dependencies and can be installed very quickly with minimal effort. Maintaining an LDAP directory also usually takes less work, and skill, than maintaining an RDBMS. This is one of the reasons for the “Lightweight” in “Lightweight Directory Access Protocol” (LDAP).

As many others have said many times before, the whole LDAP vs. RDBMS debate really comes down to understanding what each type of repository is best for. To do that you need to get past the slick vendor promotional materials and get advice from people who have had some experience in the trenches with both.

Copyright 2004-2019 Phil Lembo