2014-12-16 3 views
0

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

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» или чего-то подобного. Дело в том, что именно uids являются моей целью, дополнительная я знаю приблизительную форму uid человека, которого я ищу, например, я знаю, что если я ищу uid для Pepito Pérez с employeeNumber = 12345, это должно начните с «p».

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

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

ответ

0

Похоже, вам нужен индекс equality, добавленный в атрибут employeeNumber. Это сделало бы ваш вышеуказанный поиск, а также поиск uid.

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

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

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

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

и что бы получить вам именно то, что вы хотите.

+0

Фактически индекс равенства, добавленный в employeeNumber, является идеальным решением для моей проблемы, если у меня не было пользователя с только привилегиями чтения. – jaundavid

+1

Итак, у вас нет контроля над тем, что индексируется вообще? Так как это так, и у вас всего 40 000 записей, я бы взял ключи для всех и создал локальную базу данных, которая просто отображает ключи. Я бы сохранил только идентификатор employeeNumber и уникальных идентификаторов каталогов; они вряд ли изменятся. будьте в курсе последних новостей, периодически создавая записи. Когда вам нужно искать пользователя по номеру сотрудника, сделайте свой локальный перевод и выполните поиск по уникальному идентификатору. Если он не найден, выполните последующий поиск пользователя по номеру сотрудника, но используйте его с момента его последней синхронизации. –

Смежные вопросы