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

Ответ 1

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

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

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

От здесь

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

• Если объемы данных относительно малы (скажем, 1 000 записей), индексы скромный и не используется репликация, мы не видим неотъемлемой причины, почему вы не можете использовать LDAP в форме, которая подходит к транзакции на основе система, то есть каждые 5-10 запросов включают чтение, за которым следует запись цикла (изменение в жаргоне LDAP).

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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