Когда использовать LDAP поверх базы данных?

Question

Когда мне следует использовать LDAP по сравнению с базой данных / хранилищем значений ключей / базой данных по столбцам / и т. Д.?

Answer 1

LDAP можно считать базой данных. Но я предполагаю, что вы имеете в виду базы данных SQL.

Хранилища данных LDAP предназначены для систем с большим числом операций чтения по сравнению с операциями записи. В то время как другие базы данных, такие как хранилища SQL, предназначены для использования транзакционных данных (высокая скорость чтения и записи).

Вот почему LDAP является протоколом каталогов. Он хорошо подходит для каталогов, где вы много читаете и плохо пишете.

С здесь

LDAP характеризуется как услуга «однократная запись-многократное чтение». Тот то есть тип данных, которые обычно хранятся в LDAP не ожидается, что сервис будет меняться при каждом доступе. к Проиллюстрируем: LDAP НЕ подходит для ведения банковских операций записи транзакций, так как по своей природе они меняются на каждом доступ (транзакция). LDAP, однако, будет в высшей степени подходящим для ведение реквизитов филиалов банка, часы работы, сотрудники и т.д ..

И это еще одно хорошее введение здесь - LDAP vs RDBMS

Answer 2

В дополнение к тому, что сказал Прит Сангха, вы также должны отметить, что LDAP не транзакционный. Сервер может произвольно задерживать обновления, поэтому следующее чтение обновленных данных может не отражать обновление. Если у вас есть транзакционные требования, вы не можете использовать LDAP; если нет, вы можете.

Answer 3

также приятно читать :

Простого ответа нет, но могут пригодиться следующие примечания:

1. Производительностьпопадание во время записи заключается в обновлении индексов.Чем больше индексов (для более быстрого чтения), тем реже вы хотите обновить каталог.Чтение: коэффициент записи меньше 1000: 1 или выше для сильно оптимизированных для чтения каталогов LDAP.

2. Репликация LDAP генерирует несколько транзакций для каждого обновления, поэтому требуется минимальная практическая загрузка обновлений (1000:1 или выше).

3. Если объемы данных велики (скажем,> 10000), время для обновления даже небольшого числа индексов может быть серьезным, поэтому вы хотите, чтобы обновления были минимальными, насколько это практически возможно(10 000: 1).

4. Если объемы данных относительно малы (скажем, <1000 записей), индексы скромны и не используется репликация, мы не видим внутренней причины, по которой вы не могли использовать LDAPв форме, которая приближается к системе, основанной на транзакциях, т. е. каждые 5-10 обращений включают чтение, а затем цикл записи (изменение в жаргоне LDAP).</p>

5. Мы подозреваем, что реальный ответ на этот вопрос (с извинениями за память о покойном Дугласе Ноэле Адамсе): отношение чтения к записи равно 42!

Answer 4

Вот разница между ними: LDAP сильно оптимизирован для чтения, он может выполнять их намного быстрее, чем ваша база данных MySQL, поэтому он будет масштабироваться намного лучше, чем ваше решение для базы данных в долгосрочной перспективе.который предназначен для чтения и записи.

Я уверен, что вы найдете больше приложений, поддерживающих LDAP для метода аутентификации, чем MySQL, и вы сможете больше интегрировать в свой каталог.Я хотел бы предупредить, что прежде чем идти в первую очередь в LDAP, взгляните на инструменты управления для вашей конкретной реализации LDAP.OpenLDAP великолепен, но изменение каталога вручную все время отстой.

Answer 5

В прошлом, конечно, и с серверами каталогов, которые произошли от Univ.из базы кода Мичигана, конечно, имело место одноразовое чтение-много, и серверы каталогов, происходящие из этой базы кода, страдают от низкой производительности записи.Однако на протяжении многих лет пользователи LDAP требовали повышения производительности записи и качества транзакций от серверов каталогов LDAP, а современные серверы каталогов на основе Java имеют превосходную производительность чтения и записи.

Answer 6

LDAP действительно сияет масштабируемостью.Если вы специально хотите разместить учетные записи пользователей для аутентификации и хотите масштабировать их до нескольких реплицируемых серверов - и обрабатывать десятки тысяч запросов на аутентификацию в секунду, LDAP - отличный вариант.