When to use LDAP over a database?

Question

When should I use LDAP vs. database/key-value-store/column-oriented-database/etc?

Answer 1

also nice to read:

There is no simple answer but the following notes may be useful:

1. The performance hit during writes lies in updating the indexes. The more indexes (for faster reading) the less frequently you want to update the directory. Read:write ratios of less than 1,000:1 or higher for heavily read optimised LDAP directories.

2. LDAP Replication generates multiple transactions for every update so you want the lowest practical update load (1,000:1 or higher).

3. If data volumes are large (say > 10,000 ) the time to update even a small number of indexes may be serious so you want to keep updates as low as practical (10,000:1).

4. If data volumes are relatively small (say < 1,000 records), indexes modest and no replication is being used we see no inherent reason why you could not use LDAP in a form which approaches a transaction based system i.e. every 5 - 10 accesses involve a read followed by write cycle (a modify in the LDAP jargon).

5. We suspect that the real answer to this question is (with apologies to the memory of the late, lamented Douglas Noel Adams): the ratio of reads to writes is 42!

Answer 2

Here's the difference between the two: LDAP is highly optomized for reads, it can do them much faster than your MySQL database can, so it will scale much better than your database solution will in the long run which is optomized for reads and writes.

I'm sure that you will find more applications support LDAP for an authentication method than MySQL, and you will be able to integrate more into your directory. I would caution that before you go head first into LDAP that you take a look at the management tools for your particular LDAP implementation. OpenLDAP is great, but modifying the directory by hand all the time sucks.

Answer 3

LDAP really shines is scalability. If you specifically want a place to hold user accounts for authentication and want to scale to multiple replicated servers - and handle tens of thousands of authentication requests a second, LDAP is an great option.

Answer 4

In the past, certainly, and with directory servers that are descended from the Univ. of Mich. code base, write-once read-many was certainly the case, and directory servers descended from that code base suffer from poor write performance. Over the years, though, LDAP users have demanded increased write performance and transactional qualities from LDAP directory servers and modern Java-based directory servers have excellent read and write performance.

Answer 5

In addition to what Preet Sangha has said, you should also note that LDAP is non-transactional. The server can delay updates arbitrarily, so the next read of updated data may not reflect the update. If you have transactional requirements you can't use LDAP; if you don't, you can.

Answer 6

LDAP can be considered a database. But I'm assuming that you mean SQL databases.

LDAP data stores are for systems with high number of reads compared to writes. While other databases such as SQL stores are designed for transactional data usage (high read and writes).

This is why LDAP is a directory protocol. It's well suited to directories where you read lots and write hardly.

From here

LDAP is characterised as a 'write-once-read-many-times' service. That is to say, the type of data that would normally be stored in an LDAP service would not be expected to change on every access. To illustrate: LDAP would NOT be suitable for maintaining banking transaction records since, by their nature, they change on every access (transaction). LDAP would, however, be eminently suitable for maintaining details of the bank branches, hours of opening, employees etc..

And this is another good intro here - LDAP vs RDBMS