Выбор между сервером каталогов (он же база данных LDAP) и РСУБД
В моем проекте, где я являюсь ведущим разработчиком, у нас ранее была конфигурация сети, в которой хранился один файл XML. Конфигурация содержит информацию о компоновке сети - составляющие ее узлы, различные сведения о каждом узле, например, ОС, платформе, настроенных пользователях в каждом из них, несколько атрибутов для каждого пользователя и так далее. В следующей версии продукта мы хотим переместить данные в какую-либо базу данных, поскольку конфигурация будет расширена, чтобы включить больше элементов и деталей, и их обслуживание в файлах XML станет громоздким.
Первым выбором была СУРБД. Однако из-за иерархической природы данных конфигурации и критерия расширяемости сервер каталогов казался лучшим выбором. Мотивация для работы с сервером каталогов
Иерархические данные проще моделировать на сервере каталогов, чем в СУБД.
Также намного проще создавать / определять новые типы сущностей, которые расширяют базовый тип дополнительными атрибутами. Это очень привлекательно с точки зрения решения проблем.
Данные конфигурации будут читаться чаще, чем обновляться. Хотя производительность не имеет значения, сервер каталогов хорошо подходит для этой характеристики.
После примерно недели самонастройки основ LDAP и серверов каталогов я теперь несколько скептически отношусь к выбору сервера каталогов. Я вижу несколько вопросов:
LDAP менее распространен, чем RDBMS. Гораздо больше людей имеют опыт работы с SQL и могут быстрее начать работу с RDBMS, чем с сервером каталогов. Как я упоминал ранее, мне потребовалось чуть больше недели, чтобы изучить только основы LDAP (как создать схему, определить DIT, добавить записи, экспортировать данные в файлы LDIF и т. Д.). Это важно, потому что, когда новый член присоединяется к команде, он / она не сталкивается с кривой обучения.
В будущем у нас может быть больше данных, которые будут поддерживаться и храниться в базе данных. Сервер каталогов не может быть хорошим выбором для таких данных (например, данных, которые могут обновляться так часто, как они читаются). По моему мнению, наличие двух механизмов хранения - это бремя.
На более политическом фронте меня не будут обвинять / увольнять за выбор СУБД, даже если она не совсем подходит для рассматриваемой проблемы. С сервером каталогов, если пункт 2 выше станет реальностью, я не хочу отвечать на вопрос "Почему вы не подумали об этом раньше?".
Я ищу совет о том, как сделать выбор. Кто-нибудь сталкивался с подобной ситуацией раньше?
РЕДАКТИРОВАТЬ-1: У нас было обсуждение этого в рамках проекта, где я выдвинул точные замечания, которые я сделал здесь. Весьма вероятно, что мы выберем СУБД без какой-либо дальнейшей оценки по следующим причинам:
Пункт 2 считался более важным, чем все остальное.
Мышление в моем подразделении, кажется, довольно консервативно с людьми на всех уровнях, желающими избежать опасности. Я действительно не могу винить их за это, хотя.
"Почему не СУРБД?" был первый вопрос. "Можно ли это сделать с помощью RDBMS?" был вторым. Я наконец получил сообщение.
6 ответов
Обычно я бы убегал от LDAP как можно быстрее, однако вы просто вызвали две магические фразы, которые делают LDAP лучшим выбором: "иерархическая природа данных конфигурации" и "данных конфигурации".
LDAP был разработан для этого (и только для этого) типа данных.
Есть и другие более прагматичные причины выбора LDAP.
Все LDAP одинаковы. Это протокол доступа, а не реализация базы данных, поэтому независимо от того, использует ли ваш клиент LDAP с открытым исходным кодом или коммерческий, ваше программное обеспечение менять не нужно.
Все РСУБД разные. Независимо от того, какую СУБД вы выберете, будет хотя бы один клиент, который стандартизировал другую несовместимую СУБД - если ваш продукт достаточно успешен, вы в конечном итоге получите поддержку по крайней мере для MySQL, Postgress, SQLServer, Oracle, DB2 и Sybase.
Если ваш клиент / начальник ворчит, что он не такой надежный / производительный / транзакционный, как ORACLE/DB2, укажите, что у клиента есть возможность использовать реализацию LDAP ORACLE или DB2.
Единственным реальным недостатком является отсутствие опыта работы с LDAP. Большинство разработчиков работают только с LDAP при использовании схемы безопасности пользователя по умолчанию, которая поставляется с J2EE.
Схемы LDAP являются базами данных и требуют базы данных, такой как процедуры администрирования и контроля изменений!
- Элемент списка
Если вы просто ищете базу данных изменения конфигурации, RDBMS - это то, что вам нужно. Это распространенная проблема ИТ, и существуют различные коммерческие решения. Возможно, стоит посмотреть, что там, прежде чем вкладывать значительные средства в индивидуальное решение.
Если вы хотите в конечном итоге включить интегрированную аутентификацию на нескольких платформах (windows / linux / и т. Д.), То LDAP - это путь. Мало того, что большинство серверных и настольных ОС изначально поддерживают аутентификацию LDAP, LDAP можно легко кластеризовать или синхронизировать между несколькими сайтами.
Вполне возможно, что вы получите гибридное решение. Большая часть вашей базы данных управления изменениями (CCDB) может находиться в RDBMS, но аутентификация может обслуживаться с помощью кластера LDAP. Унифицированный интерфейс может управлять информацией в обоих. Избегайте хранения паролей учетных записей в вашей CCDB, из соображений безопасности используйте вместо этого LDAP.
Неважно, используете ли вы RDBMS или LDAP, вы, вероятно, напишите сценарии-оболочки, приложения или веб-интерфейсы для добавления / обновления информации в вашей CCDB. Это помогает сократить кривую обучения для новых сотрудников, а также упрощает и контролирует обновления в базе данных управления изменениями.
Не стоит недооценивать риски, связанные с указанием нового сотрудника в сырой РСУБД и надеждой на лучшее. Схемы для комплексных CCDB могут быть очень сложными, независимо от того, какую технологию вы выбираете для их моделирования.
Я не уверен, что аргумент "никто не был уволен..." применим здесь. В конце концов, вам действительно нужен сервер каталогов, мы не говорим о запросе, который находится в середине воображаемой оси LDAP-Database.
Я бы определенно пошел с LDAP, хотя я не могу поставить себя на место человека, которого могут уволить за выбор решения сервера каталогов для решения проблемы сервера каталогов...
Ответ прост: если вам нужен каталог, используйте LDAP. Если вам нужна база данных, используйте СУБД. Поскольку ваша цель состоит в том, чтобы иметь структуру, похожую на каталог (она очень похожа на "телефонную книгу"), используйте LDAP. СУБД будет слишком много для того, что вам нужно.
Я бы использовал подход RDBMS по следующим причинам:
- Вы можете легко изменять и расширять его структуру.
- Если ваша сеть, которую вы моделируете, похожа на мою, было бы катастрофой попытаться смоделировать ее иерархически. (Это не принципиально.) например, правила брандмауэра, доступ сервера к другим серверам, подсеть и т. д.
- Об этом чрезвычайно легко сообщить.
- Разработчиков, разбирающихся в SQL, легче найти, чем в LDAP.
- Это относительно легко обслуживать в особых случаях, может ли это быть легко сделано в LDAP?
Сказав это, я более знаком с подходом RDBMS, поэтому я предвзят.
Я был бы склонен склоняться к LDAP из-за структуры ваших данных, и, хотя, я считаю, что должно быть больше людей, которые имеют дело с иерархическими базами данных и уходят от "СУБД - единственная менталитет базы данных, я не знаю легко переносимого сервера LDAP, который вы могли бы встроить в более крупное приложение.
Вы можете использовать SQLite, если хотите идти по пути DRBMS, но я бы выбрал третий вариант - базы данных XML. Поскольку вы уже используете XML, надо надеяться, что переход на что-то вроде Berkeley DB XML для хранилища будет простым. Вы также можете проверить Википедию для списка других альтернатив
(и отказ от ответственности - я никогда не использовал базы данных XML; я использовал OpenLDAP, iDS и eDirectory на стороне LDAP, а Oracle, SQL Server, mySQL, PostgreSQL, SQLite и другие на стороне RDBMS)