LDAP vs DB

[icb]

Наблюдаю тенденцию, что многий софт начинает уметь хранить свои настройки в базах данных - обычно в MySQL (bind, exim, proftpd и т.п.).
В статьях (что на этом сайте, что на других) обычно тоже используется связка именно с MySQL.
Почему? Ведь по логике надо использовать связку с LDAP Неужели LDAP вымирает?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[princeps]

чего это он умирает? Как раз наоборот.

[Gloft]

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

[atrium]

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

Я лично от LDAP не отказываюсь

[ev]

Хотя LDAP это тоже база данных

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

но хранить и обрабатывать в ней классические таблицы помоему это не лутьшее решение.

там и есть практически классические таблицы
только менее универсальный язык запросов и геморройное создание схем

к этому можно приплюсовать
- меньше документации на русском
- меньше средств визуального администрирования

и часто кроме характерных (для хранения в LDAP) данных хранится еще много всего (статистика, контент и т.п.) - хранить это в LDAP рука не поднимется... вот и кидают все в MySQL оптом

все это наверное и влияет на некоторое уменьшение популярности LDAP
но, стоит заметить, что исправить это вполне возможно (имхо)

[princeps]

Как сказал как-то fastman, лучше плохой стандарт, чем свой собственный. LDAP - как раз стандарт для глобального каталога, поэтому в любом более или менее уважающем себя софте есть его поддержка, причем это касается в основном учеток, данные-то никому в голову не придет хранить в LDAP. Соответственно, если нужно расшарить учетные данные для нескольких сервисов, то надо юзать LDAP, т.к. это стандарт как раз под такие нужды. На SQL тоже можно сделать, но, во-первых, затрахаетесь, во-вторых, тот, кто придет после вас - охренеет. Если же у вас всего один сервис, то смысла нету юзать LDAP - SQL в большинстве своем предоставляет, как заметил ev, более простые средства для работы.
Короче, ни хрена его популярность не падает, он не конкурирует с СУБД, потому как для другого предназначен.

[ev]

он не конкурирует с СУБД, потому как для другого предназначен.

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

[zg]

Почему? Ведь по логике надо использовать связку с LDAP Неужели LDAP вымирает?

LDAP это каталог, который логически находится выше чем слой базы данных. Тут нельзя ни сравнивать ни как-то делать выводы, они находятся на разных уровнях.

[fxp]

Ппц как же сложно unix-only админу понять зачем нужен ЛДАП и что это вообще такое >_<

[icb]

Ппц как же сложно unix-only админу понять зачем нужен ЛДАП и что это вообще такое >_<

Это вы про себя? Сочувствую
Из комментариев видно - преимущества LDAP никуда не делись и вроде все их видят.
Но с фактами не поспоришь - решений на MySQL больше и они проще

[Hrafn]

Они вроде как и проще, но тут больше зависит от требований.
Управлять большим количеством пользователей удобней с помощью LDAP. Не зря дистрибутивы уровня предприятия используют различные варианты сервиса каталогов: AD, eDirectory, Redhat Directory Server да и просто LDAP.
В том же SLES практически все завязано на LDAP - пользователи, почта, днс и т.д.

[princeps]

Но с фактами не поспоришь - решений на MySQL больше и они проще

А почему это тебя расстраивает?

[icb]

А почему это тебя расстраивает?

Потому что хочется делать правильно
Но чтобы экономить время, иногда приходится выбирать решения на базе MySQL.

[princeps]

ну так и делай правильно, кто мешает? Если у тебя всего один сервис, например, почта на хостинге - то зачем тебе там лдап?

[zg]

Потому что хочется делать правильно

тогда делай на лдап

[varav]

LDAP конечно изначально создавался как понятный всем стандарт и в этом его преимущество. Но когда смотришь на это чудо вблизи и пытаешься решить свои насущные проблемы с помощью стандартного набора схем, получается жуткий монстр с гигантским количеством избыточных атрибутов и при этом все равно какой-нибудь мелочи не хватает. А создавать собственные схемы (а тем более модифицировать стандартные) настоятельно не рекомендуется - именно из-за того, что теряется смысл стандартизации.
При этом часто не избежать использования обычных реляционных баз - хотя бы для учета того же трафика - счетчики и быстро меняющиеся данные в ЛДАП хранить опять же не рекомендуется. Вот и получается гибрид ежа с ужом - реляционной и иерархической базы.
Иерархия в ЛДАП имеет свою оборотную сторону - вот здесь http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf в разделе 3.3.2 Namespace design - Branching the directory tree приводится аргумент против формирования дерева ЛДАП как отображение структуры организации, например, очень тяжело будет осуществлять переименование департамента: "Note that renaming a department entry, for example, has the effect of requiring a change of the DNs of all entries below its branch point. This has an undesirable impact on the service for several reasons." Так для чего же тогда весь этот огород нужен - всех пользователей хранить в виде плоского списка, но в иерархической базе!
А в реляционной БД переименование отдела - элементарная операция, не затрагивающая общей функциональности. Да и видимую иерархию можно сделать какую угодно с помощью соответствующего запроса.
А уж насколько неудобно выглядит навигация по дереву ЛДАП с помощью бесконечных OU=..DN=..DC=...
Так что для меня выглядит загадкой секрет большого успеха ЛДАП (и ведь не только в MS AD!).
Вероятно нет пока удачного и растиражированного варианта службы каталогов на базе того же MySQL, например, хотя решение вроде лежит на поверхности. Надо ведь еще и GUI сделать хотя бы через веб...
А пока каждый лепит свою поделку с помощью libnss-mysql.

[zg]

Так что для меня выглядит загадкой секрет большого успеха ЛДАП (и ведь не только в MS AD!).

было бы неудобно, не юзали бы.

[Alex Keda]

очень неудобно.
поюзай - поймёшь.

[zg]

очень неудобно.
поюзай - поймёшь.

было бы неудобно, не юзали бы.

проблема даже не в том, что неудобно, а в том, что разработчики чем-то ведь руководствовались, когда придумывали сей формат. И или как?

[ev]

А уж насколько неудобно выглядит навигация по дереву ЛДАП с помощью бесконечных OU=..DN=..DC=...

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

Вероятно нет пока удачного и растиражированного варианта службы каталогов на базе того же MySQL

не надо путать сетевой протокол (LDAP) и хранилище (MySQL)

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

[varav]

аналог обычного селекта, только упрощенный

уж куда проще... Надо было долго думать чтобы такую "простоту" создать.
Приходилось как-то на перле писать примочки для MS AD, так эти OU=..DN=..DC=... по ночам снились.
Select как-то сердцу милей, да и понятней.

не надо путать сетевой протокол (LDAP) и хранилище (MySQL)

Это все знают, что ЛДАП - "облегченный протокол доступа к каталогу". Но и у всякой SQL базы данных типа MySQL, PostgreSQL тоже есть протокол доступа к данным (сетевой между прочим). И есть библиотеки NSS, PAM. Так что в этом отношении они ничем не уступают ЛДАП. Только ЛДАПУ еще нужна база, где хранить свои данные. Кстати, по сути способ хранения данных такой же, как и в реляционной базе, поскольку ЛДАП (OpenLDAP по крайней мере) может работать на любой базе. Отсюда напрашивается вывод, что эта дополнительная прослойка между данными и клиентом уж никак не способствует увеличению быстродействия.
Когда начинал экспериментировать с OpenLdap, наивно надеялся, что вот уж тут действительно иерархическая объектная база данных, которая точно отражает реальную сущность вещей - есть объекты - персоны, к ним привязаны сервисы - почта, сетевые ресурсы, ФТП..., а сами персоны распределены в рамках отделов с помощью OU, что отражает реальную архитектуру предприятия. Не тут то было! Как правило сложности, связанные с вопросами переименования узлов дерева, перехода из одного ОУ в другое, приводят к формированию дерева, обусловленного ограничениями системы и далекого от реальной структуры предприятия, где часто начальное разделение веток начинается на уровне сервисов, в эти сервисы впихнуты персоны (многократно дублируя друг друга в каждой ветке). И эта красота призвана облегчить труд админа!
Нет уж, принципы организации данных по типу реляционных БД лично мне кажутся куда более простыми и совершенными.
А то что ЛДАП рулит - так это пожалуй исторически сложилось - в результате битвы гигантов. Это обломки старых технологий, которые сработали в эпоху захвата рынка глобальных сетей. Достаточно вспомнить, что ЛДАП родился из ДАП и кучи других мертворожденных протоколов путем их упрощения - не лучший способ создания нового.

[ev]

Но и у всякой SQL базы данных типа MySQL, PostgreSQL тоже есть протокол доступа к данным (сетевой между прочим).

проблема в том, что протокол разный и структуру угадать довольно проблематично

Отсюда напрашивается вывод, что эта дополнительная прослойка между данными и клиентом уж никак не способствует увеличению быстродействия.

быстродействие и жесткая стандартизованность не всегда соседствуют
да и все как обычно зависит от конкретной реализации

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

не стоит приписывать минусы конкретно клиента самому протоколу

[princeps]

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

очень неудобно.
поюзай - поймёшь.

Юзаю. Доволен. Ибо

лучше плохой стандарт, чем свой собственный.

[Alex Keda]

по мне так лучше свой

[princeps]

Бедный твой it-директор Ему с тебя, наверное, пылинки сдувать приходится, если свалишь - кто потом в твоих стандартах разбираться будет?