Выбор между сервером каталогов (также известным как база данных LDAP) и РСУБД

В моем проекте, где я являюсь ведущим разработчиком, у нас ранее была сетевая конфигурация, которая хранилась в одном XML-файле. Конфигурация содержит информацию о структуре сети — входящие в ее состав хосты, различные сведения о каждом хосте, такие как ОС, платформа, пользователи, настроенные для каждого из них, несколько атрибутов для каждого пользователя и так далее. В следующей версии продукта мы хотим переместить данные в какую-то базу данных, поскольку конфигурация будет расширена, чтобы включить больше элементов и деталей, а сохранение их в файлах XML станет громоздким.

Первым выбором была РСУБД. Однако из-за иерархической природы данных конфигурации и критерия расширяемости сервер каталогов казался лучшим выбором. Мотивы перехода на сервер каталогов:

  1. Иерархические данные проще моделировать на сервере каталогов, чем в СУБД.

  2. Также гораздо проще создавать/определять новые типы сущностей, расширяющие базовый тип дополнительными атрибутами. Это очень привлекательно с точки зрения решения проблем.

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

Примерно через неделю изучения основ LDAP и серверов каталогов я несколько скептически отношусь к выбору сервера каталогов. Я вижу несколько проблем:

  1. LDAP менее популярен, чем RDBMS. Гораздо больше людей имеют опыт работы с SQL и могут быстрее начать работу с РСУБД, чем с сервером каталогов. Как я упоминал ранее, мне потребовалось чуть больше недели, чтобы изучить только основы LDAP (как создать схему, определить DIT, добавить записи, экспортировать данные в файлы LDIF и т. д.). Это важно, потому что, когда новый член присоединяется к команде, он не сталкивается с кривой обучения.

  2. В будущем у нас может быть больше данных, которые нужно поддерживать и хранить в базе данных. Сервер каталогов может быть не лучшим выбором для таких данных (например, данные, которые могут обновляться так же часто, как они читаются). На мой взгляд, наличие двух механизмов хранения — это бремя.

  3. С политической точки зрения, меня не будут обвинять/увольнять за выбор РСУБД, даже если она не подходит для решения текущей проблемы. С сервером каталогов, если пункт 2 выше станет реальностью, я не хочу отвечать на вопрос «Почему вы не подумали об этом раньше?».

Жду совета как сделать выбор. Кто-нибудь уже сталкивался с подобной ситуацией?

РЕДАКТИРОВАТЬ-1: у нас было обсуждение этого в рамках проекта, где я изложил точные моменты, которые я сделал здесь. Весьма вероятно, что мы выберем РСУБД без дальнейшей оценки по следующим причинам:

  1. Пункт 2 считался более важным, чем все остальное.

  2. Мышление в моем подразделении кажется довольно консервативным, и люди на всех уровнях хотят перестраховаться. Хотя я действительно не могу винить их за это.

  3. «Почему не РСУБД?» был первый вопрос. «Можно ли это сделать с помощью СУБД?» был вторым. Я наконец получил сообщение.


rdbms choice directory-server
person trshiv    schedule 29.09.2009    source источник
comment
Это развернуто таким образом, что LDAP или RDBMS являются полностью внутренними для вашего продукта, и клиент не заметит разницы? Или ожидается, что клиенты будут использовать свою существующую БД или LDAP? Я спрашиваю, потому что некоторые администраторы очень не хотят менять схему своего основного сервера LDAP.   -  person noctonura    schedule 29.09.2009
comment
Да, это будет полностью внутреннее.   -  person trshiv    schedule 30.09.2009

Ответы (6)


arrow_upward
4
arrow_downward

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

LDAP был разработан для этого (и только для этого) типа данных.

Есть и другие, более прагматичные причины выбора LDAP.

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

  2. Все СУБД разные. Какую бы СУБД вы ни выбрали, будет по крайней мере один клиент, который стандартизировал другую несовместимую СУБД — если ваш продукт достаточно успешен, вы в конечном итоге будете поддерживать форк по крайней мере для MySQL, Postgress, SQLServer, Oracle, DB2 и Sybase.

Если ваш клиент/начальник ворчит, что он не такой пуленепробиваемый/производительный/транзакционный, как ORACLE/DB2, укажите, что у клиента есть возможность использовать реализацию LDAP ORACLE или DB2.

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

Схемы LDAP — это базы данных, и для них потребуются базы данных, такие как администрирование и процедуры контроля изменений!

  1. Пункт списка
person James Anderson    schedule 29.09.2009

arrow_upward
1
arrow_downward

Если вы просто ищете базу данных для изменения конфигурации, СУБД — это то, что вам нужно. Это распространенная ИТ-проблема, и существуют различные коммерческие решения. Возможно, стоит посмотреть, что там есть, прежде чем вкладывать значительные средства в индивидуальное решение.

Если вы хотите в конечном итоге внедрить интегрированную аутентификацию на нескольких платформах (Windows / Linux / и т. д.), то LDAP — это то, что вам нужно. Мало того, что большинство серверных и настольных ОС изначально поддерживают аутентификацию LDAP, LDAP можно легко кластеризовать или синхронизировать между несколькими сайтами.

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

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

Не стоит недооценивать риски, связанные с тем, что вы указываете новому сотруднику необработанную СУБД и надеетесь на лучшее. Схемы комплексных CCDB могут быть очень сложными, независимо от того, какую технологию вы выберете для их моделирования.

person ives    schedule 29.09.2009

arrow_upward
0
arrow_downward

Я бы выбрал подход RDBMS по следующим причинам:

  1. Вы можете легко изменять и расширять его структуру.
  2. Если ваша сеть, которую вы моделируете, чем-то похожа на мою, было бы катастрофой пытаться смоделировать ее иерархически. (Это не принципиально.). например правила брандмауэра, доступ сервера к другим серверам, подсети и т. д.
  3. Об этом очень легко сообщить.
  4. Легче найти разработчиков, умеющих работать с SQL, чем с LDAP.
  5. Относительно легко обслуживать особые случаи, легко ли это сделать в LDAP?

Сказав это, я больше знаком с подходом RDBMS, поэтому я предвзят.

person Bravax    schedule 29.09.2009

arrow_upward
0
arrow_downward

Ответ прост: если вам нужен каталог, используйте LDAP. Если вам нужна база данных, используйте СУБД. Поскольку ваша цель состоит в том, чтобы иметь структуру, подобную каталогу (это звучит очень похоже на «телефонную книгу»), используйте LDAP. РСУБД будет слишком накладной для того, что вам нужно.

person Andrew Sledge    schedule 29.09.2009
comment
На самом деле я имею в виду, что не нужно слишком много думать об этом. :) - person Andrew Sledge; 29.09.2009

arrow_upward
0
arrow_downward

Я не уверен, что здесь применим аргумент «никто не был уволен за…». В конце концов, вам действительно нужен сервер каталогов, мы не говорим о запросе, который стоит посреди воображаемой оси LDAP-база данных.

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

person Community    schedule 29.09.2009

arrow_upward
0
arrow_downward

Я был бы склонен склоняться к LDAP из-за структуры ваших данных, и хотя я придерживаюсь мнения, что должно быть больше людей, которые имеют дело с иерархическими базами данных и уходят от «RDBMS — единственная базы данных», я не знаю легко переносимого сервера LDAP, который можно было бы встроить в более крупное приложение.

Вы можете использовать SQLite, если хотите пойти по пути DRBMS, но на самом деле я бы выбрал третий вариант — базы данных XML. Поскольку вы уже используете XML, мы надеемся, что будет легко перейти на что-то вроде Berkeley DB XML для хранилища. Вы также можете найти в Википедии список других альтернатив.

(и отказ от ответственности - я никогда не использовал базы данных XML; я использовал OpenLDAP, iDS и eDirectory на стороне LDAP и Oracle, SQL Server, mySQL, PostgreSQL, SQLite и другие на стороне СУБД)

person Joe    schedule 29.09.2009