LDAP vs DB
Модератор: vadim64
-
- лейтенант
- Сообщения: 751
- Зарегистрирован: 2008-07-15 16:11:11
LDAP vs DB
Наблюдаю тенденцию, что многий софт начинает уметь хранить свои настройки в базах данных - обычно в MySQL (bind, exim, proftpd и т.п.).
В статьях (что на этом сайте, что на других) обычно тоже используется связка именно с MySQL.
Почему? Ведь по логике надо использовать связку с LDAP Неужели LDAP вымирает?
В статьях (что на этом сайте, что на других) обычно тоже используется связка именно с MySQL.
Почему? Ведь по логике надо использовать связку с LDAP Неужели LDAP вымирает?
Услуги хостинговой компании Host-Food.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/
Тарифы на виртуальные сервера (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/
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
чего это он умирает? Как раз наоборот.
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru
-
- лейтенант
- Сообщения: 645
- Зарегистрирован: 2008-03-09 11:32:12
- Откуда: Москва
Re: LDAP vs DB
Хотя LDAP это тоже база данных, но хранить и обрабатывать в ней классические таблицы помоему это не лутьшее решение.
-
- мл. сержант
- Сообщения: 88
- Зарегистрирован: 2008-08-19 15:35:47
Re: LDAP vs DB
если в пределах организации, например настройка почты с LDAP отлично, адресная книга. Правда схему нужно накатать
Я лично от LDAP не отказываюсь
Я лично от LDAP не отказываюсь
-
- ст. лейтенант
- Сообщения: 1325
- Зарегистрирован: 2008-07-27 17:11:30
- Откуда: Москва
Re: LDAP vs DB
LDAP - это протоколХотя LDAP это тоже база данных
и если мне не изменяет память, то в openldap можно выбрать в какой базе хранить информацию (правда выбор там никакой)
там и есть практически классические таблицыно хранить и обрабатывать в ней классические таблицы помоему это не лутьшее решение.
только менее универсальный язык запросов и геморройное создание схем
к этому можно приплюсовать
- меньше документации на русском
- меньше средств визуального администрирования
и часто кроме характерных (для хранения в LDAP) данных хранится еще много всего (статистика, контент и т.п.) - хранить это в LDAP рука не поднимется... вот и кидают все в MySQL оптом
все это наверное и влияет на некоторое уменьшение популярности LDAP
но, стоит заметить, что исправить это вполне возможно (имхо)
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
Как сказал как-то fastman, лучше плохой стандарт, чем свой собственный. LDAP - как раз стандарт для глобального каталога, поэтому в любом более или менее уважающем себя софте есть его поддержка, причем это касается в основном учеток, данные-то никому в голову не придет хранить в LDAP. Соответственно, если нужно расшарить учетные данные для нескольких сервисов, то надо юзать LDAP, т.к. это стандарт как раз под такие нужды. На SQL тоже можно сделать, но, во-первых, затрахаетесь, во-вторых, тот, кто придет после вас - охренеет. Если же у вас всего один сервис, то смысла нету юзать LDAP - SQL в большинстве своем предоставляет, как заметил ev, более простые средства для работы.
Короче, ни хрена его популярность не падает, он не конкурирует с СУБД, потому как для другого предназначен.
Короче, ни хрена его популярность не падает, он не конкурирует с СУБД, потому как для другого предназначен.
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru
-
- ст. лейтенант
- Сообщения: 1325
- Зарегистрирован: 2008-07-27 17:11:30
- Откуда: Москва
Re: LDAP vs DB
зато СУБД с ним конкурирует - ведь СУБД более универсальное средство и поэтому пытается "перетягивать на себя одеяло"он не конкурирует с СУБД, потому как для другого предназначен.
но (имхо) только в простых системах, где не хочется разворачивать LDAP и разбираться с ним
в основном (опять имхо) из-за сложности написания схем и отсутствием документации
-
- полковник
- Сообщения: 5845
- Зарегистрирован: 2007-12-07 13:51:33
- Откуда: Верх-Нейвинск
Re: LDAP vs DB
LDAP это каталог, который логически находится выше чем слой базы данных. Тут нельзя ни сравнивать ни как-то делать выводы, они находятся на разных уровнях.icb писал(а):Почему? Ведь по логике надо использовать связку с LDAP Неужели LDAP вымирает?
-
- мл. сержант
- Сообщения: 79
- Зарегистрирован: 2008-10-06 1:02:58
Re: LDAP vs DB
Ппц как же сложно unix-only админу понять зачем нужен ЛДАП и что это вообще такое >_<
-
- лейтенант
- Сообщения: 751
- Зарегистрирован: 2008-07-15 16:11:11
Re: LDAP vs DB
Это вы про себя? СочувствуюПпц как же сложно unix-only админу понять зачем нужен ЛДАП и что это вообще такое >_<
Из комментариев видно - преимущества LDAP никуда не делись и вроде все их видят.
Но с фактами не поспоришь - решений на MySQL больше и они проще
- Hrafn
- сержант
- Сообщения: 239
- Зарегистрирован: 2007-08-18 15:25:57
- Откуда: Питер
- Контактная информация:
Re: LDAP vs DB
Они вроде как и проще, но тут больше зависит от требований.
Управлять большим количеством пользователей удобней с помощью LDAP. Не зря дистрибутивы уровня предприятия используют различные варианты сервиса каталогов: AD, eDirectory, Redhat Directory Server да и просто LDAP.
В том же SLES практически все завязано на LDAP - пользователи, почта, днс и т.д.
Управлять большим количеством пользователей удобней с помощью LDAP. Не зря дистрибутивы уровня предприятия используют различные варианты сервиса каталогов: AD, eDirectory, Redhat Directory Server да и просто LDAP.
В том же SLES практически все завязано на LDAP - пользователи, почта, днс и т.д.
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
А почему это тебя расстраивает?icb писал(а):Но с фактами не поспоришь - решений на MySQL больше и они проще
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru
-
- лейтенант
- Сообщения: 751
- Зарегистрирован: 2008-07-15 16:11:11
Re: LDAP vs DB
Потому что хочется делать правильноА почему это тебя расстраивает?
Но чтобы экономить время, иногда приходится выбирать решения на базе MySQL.
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
ну так и делай правильно, кто мешает? Если у тебя всего один сервис, например, почта на хостинге - то зачем тебе там лдап?
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru
-
- полковник
- Сообщения: 5845
- Зарегистрирован: 2007-12-07 13:51:33
- Откуда: Верх-Нейвинск
Re: LDAP vs DB
тогда делай на лдапicb писал(а):Потому что хочется делать правильно
-
- проходил мимо
Re: LDAP vs DB
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.
При этом часто не избежать использования обычных реляционных баз - хотя бы для учета того же трафика - счетчики и быстро меняющиеся данные в ЛДАП хранить опять же не рекомендуется. Вот и получается гибрид ежа с ужом - реляционной и иерархической базы.
Иерархия в ЛДАП имеет свою оборотную сторону - вот здесь 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.
-
- полковник
- Сообщения: 5845
- Зарегистрирован: 2007-12-07 13:51:33
- Откуда: Верх-Нейвинск
Re: LDAP vs DB
было бы неудобно, не юзали бы.varav писал(а):Так что для меня выглядит загадкой секрет большого успеха ЛДАП (и ведь не только в MS AD!).
- Alex Keda
- стреляли...
- Сообщения: 35454
- Зарегистрирован: 2004-10-18 14:25:19
- Откуда: Made in USSR
- Контактная информация:
-
- полковник
- Сообщения: 5845
- Зарегистрирован: 2007-12-07 13:51:33
- Откуда: Верх-Нейвинск
Re: LDAP vs DB
lissyara писал(а):очень неудобно.
поюзай - поймёшь.
zg писал(а):было бы неудобно, не юзали бы.
проблема даже не в том, что неудобно, а в том, что разработчики чем-то ведь руководствовались, когда придумывали сей формат. И или как?
-
- ст. лейтенант
- Сообщения: 1325
- Зарегистрирован: 2008-07-27 17:11:30
- Откуда: Москва
Re: LDAP vs DB
аналог обычного селекта, только упрощенныйА уж насколько неудобно выглядит навигация по дереву ЛДАП с помощью бесконечных OU=..DN=..DC=...
имхо чтобы было проще реализовать парсер, а не делать интерпретатор сложного языка запросов (типа SQL)
не надо путать сетевой протокол (LDAP) и хранилище (MySQL)Вероятно нет пока удачного и растиражированного варианта службы каталогов на базе того же MySQL
никто не мешает сделать LDAP поверх MySQL и.п.
не сделано - значит никому не надо (как любят говорить на этом форуме)
-
- проходил мимо
Re: LDAP vs DB
уж куда проще... Надо было долго думать чтобы такую "простоту" создать.аналог обычного селекта, только упрощенный
Приходилось как-то на перле писать примочки для MS AD, так эти OU=..DN=..DC=... по ночам снились.
Select как-то сердцу милей, да и понятней.
Это все знают, что ЛДАП - "облегченный протокол доступа к каталогу". Но и у всякой SQL базы данных типа MySQL, PostgreSQL тоже есть протокол доступа к данным (сетевой между прочим). И есть библиотеки NSS, PAM. Так что в этом отношении они ничем не уступают ЛДАП. Только ЛДАПУ еще нужна база, где хранить свои данные. Кстати, по сути способ хранения данных такой же, как и в реляционной базе, поскольку ЛДАП (OpenLDAP по крайней мере) может работать на любой базе. Отсюда напрашивается вывод, что эта дополнительная прослойка между данными и клиентом уж никак не способствует увеличению быстродействия.не надо путать сетевой протокол (LDAP) и хранилище (MySQL)
Когда начинал экспериментировать с OpenLdap, наивно надеялся, что вот уж тут действительно иерархическая объектная база данных, которая точно отражает реальную сущность вещей - есть объекты - персоны, к ним привязаны сервисы - почта, сетевые ресурсы, ФТП..., а сами персоны распределены в рамках отделов с помощью OU, что отражает реальную архитектуру предприятия. Не тут то было! Как правило сложности, связанные с вопросами переименования узлов дерева, перехода из одного ОУ в другое, приводят к формированию дерева, обусловленного ограничениями системы и далекого от реальной структуры предприятия, где часто начальное разделение веток начинается на уровне сервисов, в эти сервисы впихнуты персоны (многократно дублируя друг друга в каждой ветке). И эта красота призвана облегчить труд админа!
Нет уж, принципы организации данных по типу реляционных БД лично мне кажутся куда более простыми и совершенными.
А то что ЛДАП рулит - так это пожалуй исторически сложилось - в результате битвы гигантов. Это обломки старых технологий, которые сработали в эпоху захвата рынка глобальных сетей. Достаточно вспомнить, что ЛДАП родился из ДАП и кучи других мертворожденных протоколов путем их упрощения - не лучший способ создания нового.
-
- ст. лейтенант
- Сообщения: 1325
- Зарегистрирован: 2008-07-27 17:11:30
- Откуда: Москва
Re: LDAP vs DB
проблема в том, что протокол разный и структуру угадать довольно проблематичноНо и у всякой SQL базы данных типа MySQL, PostgreSQL тоже есть протокол доступа к данным (сетевой между прочим).
быстродействие и жесткая стандартизованность не всегда соседствуютОтсюда напрашивается вывод, что эта дополнительная прослойка между данными и клиентом уж никак не способствует увеличению быстродействия.
да и все как обычно зависит от конкретной реализации
не стоит приписывать минусы конкретно клиента самому протоколуКак правило сложности, связанные с вопросами переименования узлов дерева, перехода из одного ОУ в другое, приводят к формированию дерева, обусловленного ограничениями системы и далекого от реальной структуры предприятия, где часто начальное разделение веток начинается на уровне сервисов, в эти сервисы впихнуты персоны (многократно дублируя друг друга в каждой ветке).
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
Что-то вы ребята путаете божий дар с яичницей. ЛДАп - это стандарт глобального каталога, а не реализация базы данных, так и давайте использовать его по прямому назначению.
Юзаю. Доволен. Ибоlissyara писал(а):очень неудобно.
поюзай - поймёшь.
princeps писал(а):лучше плохой стандарт, чем свой собственный.
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru
- Alex Keda
- стреляли...
- Сообщения: 35454
- Зарегистрирован: 2004-10-18 14:25:19
- Откуда: Made in USSR
- Контактная информация:
-
- майор
- Сообщения: 2684
- Зарегистрирован: 2007-09-25 10:20:59
- Откуда: Сочи, Москва
- Контактная информация:
Re: LDAP vs DB
Бедный твой it-директор Ему с тебя, наверное, пылинки сдувать приходится, если свалишь - кто потом в твоих стандартах разбираться будет?
Deus quos vult perdere dementat prius
http://www.itforum-sochi.ru
http://www.itforum-sochi.ru