LDAP vs relational database

Typically, when I ask enterprise developers where they'll store application data the response is immediate, a relational database. The directory server isn't even an afterthought. There's a long laundry list of reasons why: no one gets fired for choosing Oracle, its already there, familiarity with SQL, plethora of RDBMS tools, LDAP writes are slow, JNDI interface - are you kidding?!... While all of these are legitimate retorts, LDAP, and in particular OpenDS, bring with it clear advantages for certain classes of applications.

A short list of OpenDS differentiators include:

It's a database! LDAP isn't just a dumping ground for user profile data, it's a full-fledged hierarchical database. If your data is modeled in a parent-child fashion, not unusual in a XML world, then LDAP might be a better fit. LDAP data modeling is very different than relational modeling though at a simplistic level you might map tables to entries and columns to attributes.

Change schema over protocol: Schema is modifiable over the standard LDAP protocol - no vendor specific tools or syntax required. Building an application that requires frequent and/or unpredictable schema changes is difficult with relational databases and, I've found, often handled by creating generic trees (parent child relationships). Highly, dynamic “Web 2.0'ish” applications come to mind; e.g., generic Atom server where arbitrary schema changes are expected.

Out-of-the-box synchronization: Synchronizing directory databases is a standard feature and requires minimal administration. It just works...at least that's the idea. A very cool feature for H/A and solving data adjacency issues.

Read/write performance parity: At the moment I'm unable to release specifics on OpenDS performance, but those of you with memories of slow write performance are in for a pleasant surprise

Embedded mode: OpenDS need not run in a separate process, rather it can be directly embedded in your application. This is especially useful for cases where one may need the benefits of a LDAP (the other bullets) database with zero external administration.

Scalability: OpenDS, stripped down, runs on PDA's and scales to telcos.

Extensibility: Aside from standard plugin extensions there are numerous hooks within OpenDS that are easily modified by a Java developer. OpenDS is 100% Java after-all. A deployer is free to customize protocol handlers, client connection handlers, configuration, monitors, loggers, and even the backend (we use Berkley DB).

Internationalization over protocol: Fetching language specific directory attributes is easily done over protocol using LDAP attribute options. For example, you may search for the English specific “description” attribute by searching “description;lang-en: software products” or the German version “description;lang-de: Softwareprodukte”

Matching rules: Directory servers provide a flexible facility for determining attribute value equality. Typical equality matching is supported out-of-the-box; e.g., case ignore, greater/less than, etc. The differentiating feature is the ability to write your own matching rules for specific attributes. An interesting application of this is fuzzy matching rules; instead of implementing approximate matches in your application logic this can be done within the data repository. For example, if I search for all Atom entries with the an attribute named “category” and the value “foo” I may have a matching rule that finds and return all entries that contain category values with “bar” and “baz” as well.

More to follow...


The DS has to make it very easy to write extensions, including ASN.1 BER encoding/decoding, because one thing that LDAP lacks is triggers.

Posted by Nico on February 07, 2007 at 09:14 AM CST #

And of course, client code for extensions is needed as well. This is where LDAP founders, IMO, compared to an RDBMS. Which isn't to say that there aren't many applications where LDAP isn't a great fit.

Posted by Nico on February 07, 2007 at 09:15 AM CST #

The biggest problem with adopting an LDAP storage solutions (over RDBMs) is the lack of transactional semantics and ACID properties. If implemented, I bet LDAP performance will be decreased to that of an RDBMS.

Posted by Hristo on February 11, 2007 at 05:34 PM CST #

We use OpenDS in JBoss Portal testsuite. It's very easy to deploy OpenDS as an MBean in AS so it's extreamelly usefull for testing. What makes it great is just 2 jars needed while ApacheDS has insane number of jars that often break with other libs... We simply love this project!

Posted by Bolesław Dawidowicz on February 11, 2007 at 09:24 PM CST #

Some of the problems I see switching from a RDBMS besides ACID properties mentioned above are: 1) Reporting seems difficult and not user or tool friendly 2) Having data in two different storage types/places also seems problematic especially when you need transactions that involve both and again reporting. 3) In larger applications that have to scale there is no such thing as zero maintenance. So this is yet another piece that has to be backed up and maintained. With larger applications it also seems like it would add to hardware requirments where as everything in the RDBMS you already have the memory for cache etc.. 4) General lack of knowledge of LDAP is also a problem :) I already know SQL and RDBMS.

Posted by James on February 12, 2007 at 02:53 AM CST #

its not even a ldap vs oracle question. its the fact that: 1. many systems require an antiquated ldap schema be present, which is pretty unworkable one to boot. 2. the tools are just awful. 3. the api is overly complicated. 4. theres no good administation knowledge of ldap in the world. 5. its slow. really slow. we'd all love to not have to use oracle, but the final icing on the cake is that most ldap installations are fed from oracle. so ldap becomes this weird view of existing oracle data. ldap is a failure. if you want acceptance of it it needs to be alot easier to code to, or lightning fast, preferably both.

Posted by anonymous burrito on February 12, 2007 at 07:43 AM CST #

Nice post, if OpenDS centered. Most of the advantages would apply to other Directory Services packages. OpenLDAP has introduced ACID for updates and is extremely fast for both updates and retrievals. I suspect the performance comment above is based on older slower implementations. Meanwhile, keep up the good work evangelizing for LDAP!

Posted by Marty Heyman on February 13, 2007 at 05:55 AM CST #

Are you planning any integration with Grizzly 1.5 ? It looks like Grizzly is evolving towards a modular architecture enabling to plug customized protocol handlers like the ones you listed into "Extensibility" section.

Posted by Dominique De Vito on April 03, 2007 at 02:53 AM CDT #

Not at this time. However, if you'd like to join the OpenDS project and implement a Grizzly based protocol handler we'd appreciate the contribution!

Posted by Trey Drake on April 03, 2007 at 08:39 AM CDT #

Good topic, the big issue in telco industry, when NgHLR introduce the market, could anybody can share information with me ?? which one the best solution for telco industry, which is the characteristic of the box is we never touch the equipment for 5 years :p

Posted by jamop on March 13, 2008 at 02:20 PM CDT #

bump to anon burrito...don't see much reason for using ldap unless you are stuck with it by architects trying to cta since they convinced company to buy it

Posted by tony on November 16, 2008 at 10:46 PM CST #

can you please comment on the performance part in comparison with comparison to the RDBMS ?

Posted by harsh on July 21, 2010 at 03:42 PM CDT #

How well does LDAP work with relational database? If an enterprise already has the relational database setup, it's impossible to overhaul everything. But for new data storage, LDAP could be used if it were able to work well with rd.

Posted by April from Bakersfield on January 15, 2011 at 11:08 AM CST #

Is there any test results on performance comparing LDAP and RDBMS?

Posted by Eric Los Angeles on February 28, 2011 at 08:51 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed



« June 2016