When to use LDAP over a database?

Question

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

Answer 1

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

Answer 2

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 3

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 ie 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 4

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 5

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 6

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 7

So why use LDAP? Here is our list of key characteristics which make the (currently) high level of pain worthwhile.

LDAP provides a remote and local data access method that is standardized. It is thus possible to replace the LDAP implementation completely without affecting the external interface to the data. RDBMS systems mostly implement local access standards, such as SQL, but remote interfaces are always proprietary.

Because LDAP uses standardized data access methods, LDAP Clients and Servers may be sourced (or developed) independently. By extension of this point LDAP may be used to abstract the view of data contained in transaction oriented databases, say for the purpose of running user queries, while allowing the user to transparently (to the LDAP queries) change the transactional database supplier.

LDAP provides a method whereby data may be moved (delegated) to multiple locations without affecting any external access to that data. By using referral methods LDAP data can be moved to alternate LDAP servers by changing operational parameters only. Thus, it is possible to construct distributed systems, perhaps with data coming from separate autonomous organizations, while providing a single, consistent, view of the data to its users.

LDAP systems can be operationally configured to replicate data to one or more LDAP servers or applications without adding either code or changing the external access to that data.