Как оптимизировать поиск по ldap?

В ldap моей организации есть пользователь с правами только для чтения, который использует реализацию openldap, я не знаю точно структуру дерева, но знаю, что есть много организационных единиц ниже объектов bogota, medellin, palmira (которые, в свою очередь, находятся ниже организации xxx.edu.co). Меня интересует поиск uid людей, использующих другой атрибут с именем employeeNumber, в каждой people организационной единице ниже организаций второго уровня (Богота, Медельин, Пальмира). Я могу добиться этого с помощью:

ldapsearch -h secret.xxx.edu.co -D 'uid=myUser,ou=Institucional,o=bogota,o=xxx.edu.co' -w myPass -x -b 'ou=People,o=bogota,o=xxx.edu.co' '(&(employeeNumber=123485))'

Проблема заключается в эффективности, учитывая, что моя организация насчитывает более 40000 пользователей, поиск идет очень-очень медленно. Если я ищу с использованием uid, поиск будет очень быстрым, я предполагаю, что дерево точно упорядочено по 'uid' или что-то подобное. Дело в том, что именно uid являются моей целью, кроме того, я знаю приблизительную форму uid человека, которого ищу, например, я знаю, что если я ищу uid для Пепито Переса с employeeNumber = 12345, это должно начинаться с буквы «р».

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

Я думаю, что что-то вроде фильтрации дерева с помощью регулярного выражения в индексированном атрибуте uid и после поиска сотрудника в этом подмножестве может иметь хорошую производительность. Мне нужен подход, который не требует прав администратора в ldap.


person jaundavid    schedule 16.12.2014    source источник


Ответы (1)


Похоже, вам нужно добавить индекс equality к атрибуту employeeNumber. Это повысит эффективность поиска, указанного выше, так же, как поиск по идентификатору.

Если вы хотите эффективно выполнять частичное uid сопоставление, вам потребуется индекс substring для атрибута uid.

Кроме того, ваш фильтр (&(employeeNumber=123485)) можно просто выразить как (employeeNumber=123485). В and (&) нет необходимости, так как есть только один пункт.

Если бы у вас были соответствующие индексы, вы могли бы выполнить поиск с помощью такого фильтра ...

(&(employeeNumber=123485)(uid=p*))

и это даст вам именно то, что вы хотите.

person Dave Bennett    schedule 16.12.2014
comment
Фактически, индекс равенства, добавленный к employeeNumber, является идеальным решением моей проблемы, если бы у меня не было пользователя с правами только на чтение. - person jaundavid; 16.12.2014
comment
Итак, вы вообще не контролируете, что индексируется? Поскольку это так, и у вас есть только 40 000 записей, я бы взял ключи для всех из них и создал локальную базу данных, которая просто сопоставляет ключи. Я бы сохранил только employeeNumber и уникальный идентификатор каталогов; это вряд ли изменится. поддерживайте его в актуальном состоянии, периодически просматривая новые записи. Если вам нужно найти пользователя по employeeNumber, сделайте локальный перевод и поиск по уникальному идентификатору. Если не найден, выполните последующий поиск пользователя по employeeNumber, но контролируйте с помощью createtime с момента последней синхронизации. - person Dave Bennett; 16.12.2014