database 何时在数据库上使用 LDAP？

When to use LDAP over a database?

提问by DavidHH

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

什么时候应该使用 LDAP 与数据库/键值存储/面向列的数据库/等？

回答by Preet Sangha

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

LDAP 可以被认为是一个数据库。但我假设您指的是 SQL 数据库。

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).

LDAP 数据存储适用于读取次数多于写入次数的系统。而其他数据库（如 SQL 存储）是为事务数据使用（高读写）而设计的。

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

这就是 LDAP 是目录协议的原因。它非常适合您阅读很多而几乎不写的目录。

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..

LDAP 的特点是“一次写入多次读取”服务。也就是说，通常存储在 LDAP 服务中的数据类型不会在每次访问时发生变化。举例说明：LDAP 不适合维护银行交易记录，因为就其性质而言，它们在每次访问（交易）时都会发生变化。然而，LDAP 非常适合维护银行分行、营业时间、员工等的详细信息。

And this is another good intro here - LDAP vs RDBMS

这是另一个很好的介绍- LDAP vs RDBMS

回答by user207421

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.

除了 Preet Sangha 所说的，您还应该注意 LDAP 是非事务性的。服务器可以任意延迟更新，所以下次读取更新的数据可能不会反映更新。如果您有事务要求，则不能使用 LDAP；如果你不这样做，你可以。

回答by mkind

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!

没有简单的答案，但以下注释可能有用：

1. 写入期间的性能影响在于更新索引。索引越多（读取速度越快），更新目录的频率就越低。对于大量读取优化的 LDAP 目录，读取：写入比率小于 1,000:1 或更高。

2. LDAP 复制为每次更新生成多个事务，因此您需要最低的实际更新负载（1,000:1 或更高）。

3. 如果数据量很大（比如 > 10,000 ），即使是少量索引的更新时间也可能很严重，因此您希望保持尽可能低的更新（10,000:1）。

4. 如果数据量相对较小（例如 < 1,000 条记录）、索引适度且未使用复制，我们看不出您不能以接近基于事务的系统的形式使用 LDAP 的内在原因，即每 5 - 10 次访问涉及一次读取然后是写周期（LDAP 术语中的修改）。

5. 我们怀疑这个问题的真正答案是（对已故的悲叹道格拉斯·诺埃尔·亚当斯的记忆表示歉意）：读取与写入的比率是 42！

回答by Nitin Pawar

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.

这是两者之间的区别：LDAP 对读取进行了高度优化，它可以比您的 MySQL 数据库更快地完成它们，因此从长远来看，它会比您的数据库解决方案更好地扩展，后者为读取和写入优化。

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.

我相信您会发现比 MySQL 更多的应用程序支持 LDAP 作为身份验证方法，并且您将能够将更多应用程序集成到您的目录中。我要提醒的是，在您首先进入 LDAP 之前，您应该先了解一下您的特定 LDAP 实现的管理工具。OpenLDAP 很棒，但是一直手动修改目录很糟糕。

回答by Terry Gardner

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.

在过去，当然，还有来自大学的目录服务器。在密歇根州的代码库中，一次写入多次读取肯定是这种情况，并且源自该代码库的目录服务器的写入性能很差。然而，多年来，LDAP 用户一直要求 LDAP 目录服务器具有更高的写入性能和事务质量，而现代基于 Java 的目录服务器具有出色的读写性能。

回答by user3552519

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.

LDAP 真正的亮点是可扩展性。如果您特别想要一个地方来保存用于身份验证的用户帐户并希望扩展到多个复制服务器 - 并且每秒处理数万个身份验证请求，LDAP 是一个不错的选择。