Приложение A — LDAP: Некоторые размышления по структурированию каталогов

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

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

Плоскость приветствуется

Каталоги в целом обычно имеют очень плоскую структуру, состоящую из двух или трёх уровней иерархии — большее количество встречается редко. Хотя, на первый взгляд, это противоречит интуитивному подходу людей, привыкших работать с классическими базами данных. Вспомните, что LDAP гораздо серьёзней оптимизирован на работу с данными, находящимися НА ОДНОМ УРОВНЕ иерархии, нежели на поиск данных ВВЕРХ и ВНИЗ по иерархии. В этом и кроется суть мощных методов индексирования.

Для иллюстрации достаточно простого примера: когда смотришь на компанию и разрабатываешь структуру каталога, довольно очевидным представляется первоначальное деление по подразделениям компании. НО БУДЕТ ЛИ ЭТО ОПТИМАЛЬНЫМ? Посмотрим на два способа структурирования каталога:

В DIT 1 подразделение представляет собой запись ou, в DIT 2 сведения о подразделении содержатся в атрибуте ou в записях, дочерних к ou=people. Разница кажется тривиальной.

Теперь давайте посмотрим на то, что происходит при некоторых типичных поисковых запросах:

1. Найти всех людей в sales:

   1. DIT 1 — поиск с базовым DN ou=sales,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр cn=*

   2. DIT 2 — поиск с базовым DN ou=people,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр ou=sales

   Практически, одно и то же.

2. Найти всех людей в компании:

   1. DIT 1 — поиск с базовым DN dc=mycompany,dc=com, диапазон — sub (все уровни), фильтр cn=*

   2. DIT 2 — поиск с базовым DN ou=people,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр cn=*

   Структура 2 выигрывает в скорости и простоте.

Лень приветствуется

Придерживаясь принятых нами структур, выполним простую задачу: переведём Билла из sales в marketing (разные подразделения корпорации).

1. DIT 1 — экспортируем запись Билла в файл LDIf, удалим её из sales, отредактируем файл LDIF, добавим запись в marketing. И будем надеяться, что он не будет переводиться слишком часто.

2. DIT 2 — изменим атрибут ou записи Билла с sales на marketing.

Интересно, кто выиграл этот раунд?