Причины хранить данные пользователей в LDAP вместо RDBMS - PullRequest
25 голосов
/ 18 февраля 2010

Часто говорят, что использование LDAP - это хороший способ хранить данные о пользователях.Это потому, что «каталог» пользователей является иерархическим и редко меняется.Но, на мой взгляд, это не исключает использования СУБД.Какие могут быть причины для использования LDAP?Я думаю, что хранение многозначных полей или добавление пользовательских полей в LDAP может быть проще, но это может быть сделано и в базе данных (если у вас нет много записей)

Ответы [ 6 ]

30 голосов
/ 19 февраля 2010

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

Хороший сервис LDAP требует немало знаний о конфигурации, более того, чем создание простой схемы в реляционной базе данных. БД SQL по-прежнему довольно совместимый вариант, и поддержка LDAP не так доминирующая, как это было раньше. Раньше LDAP был единственным вариантом несколько лет назад, но многие приложения (например, Apache) и операционные системы (например, PAM в Linux) могут проходить проверку подлинности на основе SQL DB, такой как MySQL, так же легко, как серверы LDAP, поскольку все они обрабатываются драйверами, которые абстрагируют интерфейс.

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

Дело не в том, что современные СУБД не масштабируются, а в том, что LDAP (как правило) даже лучше в этом из-за способа каскадной репликации через разные уровни; особенно если предположить, что у вас есть типичная база данных аутентификации, в которой она в основном доступна только для чтения с относительно небольшим количеством операций записи, поэтому вам потребуется только один способ репликации со всеми записями, поступающими из одного источника правды.

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

Вопрос, который кто-то уже высказал о наличии внешнего интерфейса LDAP в СУБД, очень хорош. Несколько компаний, в том числе Oracle (которые, конечно, заинтересованы в RDBMS), имеют продукты, специально предназначенные для этого. Если вам не нужны накладные расходы на управление службой LDAP или вы просто хотите управлять всеми своими пользователями в БД, вы можете создавать представления / объединения, но думаете, что может позже понадобиться служба LDAP Чем это хороший вариант. OpenLDAP также поддерживает оболочку, которая может принимать данные из любого источника, включая RDBMS; Я использовал его с MySQL, и он работает хорошо, хотя может быть немного сложнее настроить в первый раз, если вам нужно поддерживать конкретную схему LDAP.

Таким образом, LDAP - это хорошо, но он специфичен для взаимодействия и экстремальной масштабируемости. Если у вас есть ограниченные ресурсы для управления и поддержки, это может не стоить хлопот с поддержкой, но если вы планируете сервисы, такие как POP / IMAP / SMTP, размещенные в UNIX, или другую стороннюю интеграцию программного обеспечения, то это, безусловно, стоит сделать (и может даже быть вашим единственным жизнеспособным вариантом).

И, наконец, будьте осторожны с тем, какой LDAP-сервер вы используете, если решите внедрить его! Не все они созданы равными, и различия между ними (с точки зрения производительности и простоты управления и настройки) могут быть довольно резкими.

OpenLDAP - довольно безопасная ставка, хорошо масштабируется и довольно проста в использовании. Некоторые приложения работают лучше всего / поставляются с определенными файлами конфигурации для конкретного сервера LDAP (например, многие программы в Solaris предполагают, что вы используете сервер каталогов Sun ONE), который вы, возможно, не захотите использовать - либо потому, что он не работает так же или настраивается, плохо поддерживается и т. д.

8 голосов
/ 15 апреля 2016

Корпорация Майкрософт создала статью TechNet, в которой обсуждается продукт ADAM , и в ней есть раздел, в котором сравниваются различия между каталогами и базами данных. Следующее взято прямо с сайта.

Директории

  • Оптимизирован для операций поиска и чтения.
  • Объектно-ориентированный, иерархический дизайн данных. Объекты данных в каталоге представляют такие объекты, как пользователи, компьютеры и общие ресурсы. Эти объекты данных могут быть организованы иерархически в контейнерах.
  • Не использует схемы.
  • Предназначен для репликации и распределенного управления.
  • Точная безопасность, вплоть до уровня объекта и атрибута.
  • Недостаточная согласованность данных между партнерами по репликации.

Базы данных

  • Оптимизировано для операций записи.
  • Дизайн реляционных данных. Данные организованы в таблицы строк и столбцов. Данные из одной таблицы могут быть связаны с данными в другой таблице.
  • Использует стандартизированные, расширяемые схемы.
  • Предназначен для централизованного хранения и администрирования данных.
  • Менее точная защита, только до уровня строк и столбцов.
  • Транзакционный - гарантированная согласованность данных. Ссылочная целостность в реляционных таблицах и управление параллелизмом с блокировкой файлов и записей.
7 голосов
/ 18 февраля 2010

«L» в LDAP обозначает «Легкий вес». Одна из целей LDAP - быть относительно простым в использовании и реализации. Если все, что вам нужно, это хранить информацию о пользователях, вам не нужна полная гибкость (и потенциальная головная боль) доступа к вашим данным через SQL. Ограниченный интерфейс, представленный LDAP, должен быть проще. Это важно, если вы хотите, чтобы LDAP был внедрен и поддержан всеми, включая вашего поставщика ОС и всех ваших поставщиков приложений.

PS: Если вы хотите, вы всегда можете внедрить сервер LDAP, храня всю информацию в СУБД и предоставляя ей интерфейс LDAP:)

PPS: LDAP - это протокол, похожий на HTTP. СУБД - это приложение, обычно рассматриваемое как приложение, которое, помимо прочего, реализует SQL. Поэтому для сравнения яблок с яблоками лучше противопоставить LDAP SQL или HTTP.

3 голосов
/ 22 марта 2010

Это действительно не исключает СУБД в качестве бэкэнда. Смотрите, например, подробности о sql бэкэнде для slapd или посмотрите полный список бэкэндов .

1 голос
/ 19 февраля 2010

Interoperability.

Каталоги LDAP имеют стандартную схему для представления пользователя, поэтому общие поля, такие как имя, фамилия и адрес электронной почты, будут последовательно именоваться в разных реализациях каталогов. Это не относится к РСУБД.

LDAP определяет и протокол связи, и язык запросов. Сравните это с SQL, который является только языком запросов, и каждая СУБД реализует свой собственный протокол связи.

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

0 голосов
/ 18 февраля 2010

Одной из веских причин является предоставление единого входа во многих приложениях (использующих LDAP).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...