CC BY
31
Метод проектирования структуры хранения данных службы каталогов для уменьшения времени отклика при запросе к большим
объемам данных
A.B. Андреев
Санкт-Петербургский государственный университет аэрокосмического приборостроения
Санкт-Петербург, Россия aathexf@gmail.com
Аннотация. Предлагается метод проектирования структуры хранения данных службы каталогов для уменьшения времени отклика при запросе к большим объемам данных. Рассматриваются службы каталогов LDAP и сетевая структура хранения данных, где записи каталога хранятся в соответствующих ветках каталога для каждого заданного сервиса, использующего службу каталогов. Записи группируются условиями приоритетности сервисов. Истинное выполнение нескольких условия для одной записи реализовано механизмом записей-ссылок, соответствующих стандарту LDAP.
Ключевые слова: служба каталогов, LDAP, метод, время отклика, структура каталога.
Введение
Служба каталогов (Directory Service) - база данных, используемая как средство иерархического представления информации о некотором наборе объектов и предоставления услуг доступа к этой информации. В качестве объектов выступают материальные ресурсы, персонал, сетевые ресурсы и т. д.
LDAP (Lightweight Directory Access Protocol) - стандарт построения каталогов общего назначения. Протокол был разработан для предоставления разработчикам возможности четко определять, какие данные должен хранить каталог. Общая архитектура LDAP позволяет управлять большим количеством различных записей каталога. Большинство организаций различных отраслей производства используют одну из реализаций служб каталогов LDAP, например Microsoft Active Directory, OpenLDAP, 389-DS или другие.
Особенность служб каталогов LDAP заключается в стандартизированном способе построения структуры хранения данных службы каталогов в виде иерархической структуры [1]. В большинстве случаев записи таких каталогов структурированы по принципу физической принадлежности объекта некой структуре организации, например отделам организации, где все записи хранятся в рамках одной ветки каталога: так, например, записи пользователей хранятся в общей ветке каталога "Пользователи" или "Сотрудники" с начальной вершиной "ou=People, dc=example, dc=com". Такой же подход построения структуры каталога можно встретить в соответствующих монографиях [2].
Службы каталогов являются основным средством построения современных глобальных информационных систем, позволяющим решать как проблемы интеграции информационных ресурсов, так и вопросы управляемости ресурсами и сервисами сети любого масштаба, вплоть до столь обширной, как Интернет. Служба каталогов является средством построения стабильной и вместе с тем гибкой сетевой инфраструктуры, предназначенной для обеспечения и контроля взаимодействия пользователей или устройств с любыми сетевыми ресурсами и сервисами.
Основная характеристика работы службы каталогов
Различные сервисы сети используют службу каталогов для аутентификации, авторизации или хранения данных. Для доступа в сеть и работы с сетевыми ресурсами служба каталогов используется как единая система идентификации пользователей: при входе в сеть пользователь представляется системе, проходит процедуры аутентификации и авторизации, после чего может использовать любые ее сервисы без повторной аутентификации. Такая система не только облегчает работу пользователя, но и позволяет более эффективно организовывать работу других сервисов сети, например отправку пользователем электронных сообщений, хранение служебной информации пользователя и распределение прав доступа к ней, предоставление пользователю определенных полномочий. Процесс аутентификации и авторизации всех пользователей сети или поиска информации об объекте каталога может занимать длительное время даже с применением всех оптимизационных шагов, что приводит к простоям и задержкам всех последующих сервисов сети, использующих службу каталогов. Скорость получения данных от службы каталогов влияет на время последующей обработки данных следующим сервисом и вывода результатов пользователю, который инициализирует изначальный запрос к службе каталогов. Таким образом, основной характеристикой эффективности работы службы каталогов является временная характеристика, а именно время отклика на запрос (system response time).
Методы оптимизации работы службы каталогов
Для улучшения временной характеристики службы каталогов применяются следующие оптимизационные методы:
• кэширование данных;
• индексирование наиболее важных атрибутов [3].
Однако данные методы имеют ряд ограничений, а эффективность их применения зависит от того, как используются каталог и данные, хранящиеся в каталоге, а также от общего количества записей каталога [4].
Одним из таких ограничений, например для индексирования, является тип фильтра и параметры его использования. Тип фильтра влияет на эффективность индексирования, например индексы присутствия и подстроки. Одним из решений оптимизации такого каталога может быть использование изменения структуры каталога по определенному заранее критерию, где ветка поиска будет заменять основной фильтр поиска и уменьшать общее количество записей для выборки. Данное изменение может быть реализовано использованием сетевой структуры хранения данных [5].
Сетевая структура хранения данных
службы каталогов
Согласно RFC 4512 [6], дуга между вершинами графа, задающего иерархическую структуру каталога, обозначает физическую принадлежность объектов, отраженных в каталоге. Такое построение структуры каталога удобно для хранения записей о сотрудниках организации, где записи группируются по принадлежности к отделам организации. Однако все записи сотрудников при такой структуре все равно хранятся в одной общей ветке каталога, например "ou=People", которая обозначает физическую принадлежность реальным объектам в рамках одной организации. Таким образом, записи группируются по одному признаку (принадлежность к отделу) в рамках одной общей группы всех сотрудников. Службы сети, такие как файловый сервер, вынуждены быть сконфигурированы на использование общей ветки каталога "ou=People" с методом поиска SUP для предоставления сервиса файлового сервера. Такое построение каталога, основанное на физической принадлежности объектов, соответствующих записям каталога, влияет на организации с большим количеством сотрудников, так как все записи хранятся в одной ветке, что, как было исследовано ранее, влияет на время отклика при запросе к данным.
Вместо указанного выше обозначения дугой между вершинами графа предлагается понимать отражение выполнения условия принадлежности:
• с сервисом, использующим службу каталогов (например, файловый сервер Samba);
• фильтром поиска;
• другими условиями, задающими приоритет объектов каталога.
Согласно RFC 4511 [7], позволяется хранить, записывать, осуществлять поиск записи в разных ветках каталога средствами записей-ссылок, а сервисам - работать с ними. Группируя записи по их общим условным параметрам, можно построить более упорядоченную структуру хранения данных на основе сетевой модели данных. Более того, отслеживая изменения в активности сервисов, можно организовать адаптивную службу каталогов, меняющую свою структуру в зависимости от динамики запросов к ней.
Таким образом, изменение структуры каталога по определенным условиям и критериям приоритетности условий следует рассматривать как дополнительный способ улучшения эффективности работы службы каталогов, позволяющий существенно уменьшить общее количество записей для поиска и, соответственно, время отклика на запрос. Данное изменение задает новый способ построения структуры хранения данных службы каталогов, которая организована по условиям приоритетности, задаваемым приложениями, использующими службу каталогов, а не по физическому или организационному признаку принадлежности записей.
На примере службы каталогов, работающей с двумя сервисами (файловый сервер и прокси-сервер), стандартную иерархическую структуру хранения данных, изображенную на рисунке 1, можно представить в виде сетевой структуры хранения данных, изображенной на рисунке 2, где записи каталога сгруппированы по сервисам, использующим их, а сервисы настраиваются на работу с соответствующей веткой каталога.
Рис. 1. Стандартная иерархическая структура каталога
Рис. 2. Предлагаемая сетевая структура каталога
Основным ограничением применения такого способа проектирования и построения структуры хранения данных службы каталогов является то, что условие, по которому группируются записи каталога, не должно быть истиной для большинства записей исходной ветки каталога, так как эффективность применения метода зависит от того, насколько уменьшится исходное количество записей для поиска в заданной ветке.
Метод проектирования структуры хранения данных
службы каталогов для уменьшения времени отклика при запросе к большим объемам данных
Для построения предлагаемой сетевой структуры хранения данных службы каталогов предлагается использовать соответствующий метод проектирования структуры хранения данных службы каталогов для уменьшения времени отклика при запросе к большим объемам данных, который можно сформулировать следующей последовательностью шагов:
1. Определить структуру и типы записей используемого каталога.
Следует определить расположение записей в ветках каталога, к которым следует применять метод. Например, записи пользователей Microsoft Active Directory хранятся в ветке каталога "cn=Users, dc=example, dc=com", а записи службы каталогов OpenLDAP могут быть расположены в ветке каталога "ou=People, dc=example, dc=com", где "dc=example, dc=com" - корневая вершина структуры каталога.
Также следует определить отображение объекта каталога в реальном мире. Например, записи в исходной ветке поиска могут быть отображением пользователей корпоративной сети, или ЭВМ, или принтеров сети. В зависимости от этого можно определять различные условия группирования записей.
2. Определить сервисы сети, работающие со службой каталогов.
Для определения условий группирования записей следует определить набор сервисов, работающих со службой каталогов. Для этого следует определиться с набором ролей серверов или приложений, использующих службу каталогов. Например, для роли файлового сервера используется сервис Samba. Наиболее часто используемые роли сервера: файловый сервер, прокси-сервер, почтовый сервер, сервер аутентификации. Как правило, используют следующее соответствие:
• файловый сервер - сервис Samba;
• прокси-сервер - сервис squid;
• почтовый сервер - сервисы postfix и dovecot;
• сервер аутентификации - PAM.
Данное соответствие позволит далее четко определить атрибуты записей, соответствующие выбранному набору сервисов.
3. Определить частоту использования сервисом службы каталогов.
Следует определить, как часто сервис использует службу каталогов: если сервис редко использует службу каталогов, его не следует выбирать как условие группирования записей. Данный параметр следует определять по журналам работы службы каталогов в режиме отладки.
4. Определить типы запросов сервисов к службе каталогов.
Так как для служб каталогов операции чтения преобладают над операциями записи [8], следует отдавать предпочтение сервисам, где запросы чтения преобладают над запросами добавления или изменения. Данный параметр следует определять по журналам работы службы каталогов в режиме отладки.
5. Определить, эффективно ли работает служба каталогов с сервисом.
Для определения приемлемого значения времени отклика на запрос для человеко-компьютерного взаимодействия (а человек - основной пользователь службы каталогов) предлагается использовать результаты текущих исследований по данной тематике [9-11], на основании которых можно сделать вывод, что для определения эффективности работы службы каталогов следует использовать следующие параметры:
• ожидаемое время поиска записи T в условиях сложности задачи;
• среднеквадратическое отклонение n результатов времени поиска записи каталога ti при одинаковых параметрах поиска [12].
Общие условия эффективности работы службы каталогов могут быть сформулированы как
J^M^-^M2^; (1)
к<т, (2)
где Tv - допустимая величина вариации результатов времени отклика на запрос [13].
При невыполнении условий (1) и (2) можно судить о том, что служба каталогов неэффективно работает с заданным сервисом.
6. Определить условия группирования записей.
Следует сформулировать окончательный набор условий группирования записей для выбранной ветки каталога на основании результатов выполнения шагов 1-5.
7. Определить атрибуты записей, соответствующие выбранному набору условий.
Сервисы или внутренние приложения организации, работающие со службой каталогов, используют определенный набор атрибутов, идентифицирующий запись или набор записей. Некоторые сервисы используют атрибуты, предоставляемые разработчиками реализации служб каталогов, а некоторые, например файловый сервер Samba, используют специальные наборы атрибутов. Перед определением множеств записей сервисов каталога с учетом приоритета их использования следует определить минимально необходимые множества атрибутов для каждого сервиса.
Множества атрибутов записей, запрашиваемые сервисами, определяются одним из двух возможных способов:
• анализом журналов службы каталогов в режиме отладки;
• анализом документации разработчика сервиса.
8. Определить множества записей каталога для переноса с учетом приоритета их использования.
Для построения предлагаемой структуры каталога (сетевой) необходимо учитывать критерии принадлежности записи к определенному сервису. Одна запись может использоваться сразу несколькими сервисами, при этом запись следует располагать в ветке сервиса с наибольшим приоритетом.
Для определения множеств записей каталога для переноса с учетом приоритета их использования предлагается использовать алгоритм разбиения множества параметров
каталога, хранящихся в службе каталогов, на подмножества с учетом приоритета их использования с целью уменьшения времени отклика на запрос [14].
В структуре хранения данных данные влияют на временные характеристики служб каталогов, поэтому записи ка-талога можно рассматривать как параметр каталога наравне с аппаратными параметрами сервера, обслуживающего службу. В данном алгоритме под термином «параметр» понимается запись каталога.
9. Сформировать структуру хранения данных службы каталогов с учетом приоритетов использования параметров службы каталогов.
Определив все параметры каталога, требующие переноса в заданные ветки сервисов, предлагается использовать алгоритм перехода от иерархической структуры хранения данных без учета приоритетов использования параметров к структуре с учетом приоритетов использования параметров [14].
Предложенная последовательность шагов была применена к службе каталогов, использующей стандартную иерархическую структуру хранения данных и работающей с двумя сервисами: файловым сервером и прокси-сервером. Изначальная база данных записей каталога формировалась случайным образом записями трех видов:
• содержащими атрибуты только файлового сервера;
• содержащими атрибуты только прокси-сервера;
• содержащими атрибуты обоих сервисов.
Все записи располагались в одной ветке каталога, общее количество записей составило 150 000. Служба каталогов была сконфигурирована без использования индексирования и кэширования для минимизации вариации результатов времени отклика на запрос поиска. При добавлении 10 000 записей для каждого сервиса создавались запросы поиска соответствующего сервису атрибута записи, где фильтр поиска был сгенерирован случайным образом атрибутом uid и атрибутом объектного класса сервиса.
Количество записей по принадлежности к виду:
• записи, содержащие атрибуты только файлового сервера, - 77 171;
• записи, содержащие атрибуты только прокси-сервера, -37 458;
• записи, содержащие атрибуты обоих сервисов, -37 315.
После применения предложенного метода проектирования структуры хранения данных службы каталогов записи были сгруппированы и перераспределены по двум веткам каталога, соответствующим сервисам, где наибольший приоритет был отдан записям файлового сервера. Для полученной сетевой структуры хранения данных создавались аналогичные запросы поиска, соответствующего сервису атрибута записи, где фильтр поиска был сгенерированным случайным образом атрибутом uid и атрибутом объектного класса сервиса.
Результаты средних значений времени отклика на запрос поиска значения атрибута записи файлового сервера для обеих структур изображены на рисунке 3, результаты средних значений времени отклика на запрос поиска значения атрибута записи прокси-сервера для обеих структур -на рисунке 4.
По полученным результатам видно, что время отклика на запрос поиска значения атрибута записи для обоих сервисов уменьшилось. Время отклика на запрос поиска значения атрибута прокси-сервера меньше, чем соответствующее значение для файлового сервера.
В первую очередь это обусловлено количеством записей файлового сервера и прокси-сервера, так как общее количество записей прокси-сервера меньше, чем общее количество записей файлового сервера: 74 773 и 112 542 соответственно.
— ..... 1срарм]чс Тетсия ст] кал стр>кг гукт^р! ЮГ, :::, катало лога Т1 у
У У у
* У У
У У
У У У ,■■
S у . у у
У , У-'
20000 40000 60000 80000 100000 120000 140000 Каи I чсство тз [1 нее ii, N
Рис. 3. Зависимость времени отклика на запрос поиска значения атрибута записи файлового сервера для обеих структур
— ¡ерар.чпче Гсгевэя сг; ■кал етр^хг r.KT-.р?. ИТ ра катало 1.10Г.. _ а >
у У у
j У *
У у
У / ✓
У У г'
У У у
X
2000Q 400ÖÖ воооо йоооо юоооо 12о'о по мо'ооо
Кслччсство записей, N
Рис. 4. Зависимость времени отклика на запрос поиска значения атрибута записи прокси-сервера для обеих структур
Во-вторых, записи в ветке прокси-сервера, а именно записи прокси-сервера и записи-ссылки, меньше по размеру, чем записи в ветке файлового сервера, что также влияет на время отклика на запрос поиска значения атрибута.
Заключение
Таким образом, применением данного метода достигается уменьшение изначального количества записей каталога для заданного сервиса, использующего службу каталогов, соответственно уменьшается и время поиска записи сервиса. Распределение записей с учетом их приоритета, формируемое в результате применения метода, позволяет задействовать различные дополнительные методы оптимизации службы каталогов для различных сервисов и веток каталога.
Данный метод проектирования структуры хранения данных службы каталогов имеет достоинства и недостатки.
К достоинствам такого способа проектирования и построения структуры хранения данных службы каталогов относятся следующие:
• при одинаковых условиях запроса время отклика при запросе меньше по сравнению со стандартной иерархической структурой;
• возможность применения различных методов оптимизации для разных групп записей.
К недостаткам такого способа проектирования и построения структуры хранения данных службы каталогов относятся следующие:
• увеличение общего количества записей каталога и увеличение дискового пространства, требуемого для хранения данных;
• сложность структуры.
Литература
1. Butcher M. Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services, Packt Publishing, 2007. -484 p.
2. Howes T.A., Smith M.C., Good G.S. Understanding and Deploying LDAP Directory Services, 2nd edition, Addison-Wesley Professional, 2003. - 936 p.
3. OpenLDAP Software 2.4 Administrator s Guide: Tuning. -URL: http://www.openldap.org/doc/admin24/tuning.html (дата обращения 20.05.2019).
4. Андреев A.B. Математическая модель службы каталогов // Информационно-управляющие системы. - 2014. -№ 4 (71). С. 85-87.
5. Гордеев А. В., Андреев А. В. Структура каталога как фильтр поиска записей службы каталогов OpenLDAP // Информационно-управляющие системы. - 2019. - № 2 (99). -С. 52-56.
6. RFC 4512 - Lightweight Directory Access Protocol (LDAP): Directory Information Models. - URL: http://tools.ietf.org/html/rfc4512 (дата обращения 20.05.2019).
7. RFC 4511 - Lightweight Directory Access Protocol (LDAP): The Protocol. - URL: http://tools.ietf.org/html/rfc4511 (дата обращения 20.05.2019).
8. Glenn W., Simpson M.T. MSCE Self-Paced Training Kit (Exam 70-297): Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure, Redmond, Washington, Microsoft Press, 2004. - 459 p.
9. Miller R. B. Response Time in Man-Computer Conversational Transactions, AFIPS Conference Proceedings, 1968, Vol. 33, Pt. 1. - Pp. 267-277.
10. Shneiderman B. Designing the user interface: Strategies for effective human-computer interaction, 1st edition, Reading, MA, Addison-Wesley, 1987. - 448 p.
11. Seow S.C. Designing and Engineering Time: The Psychology of Time Perception in Software, Addison-Wesley Professional, 2008, 224 p.
12. Jain R.K. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, New York, NY, John Wiley & Sons, 1991. - 720 p.
13. Stupak N. Time delays and system response times in human-computer interaction (2009). Thesis. Rochester Institute of Technology, 102 p. - URL: http://scholarworks.rit.edu/theses/1370.
14. Андреев A.B. Сетевая модель данных службы каталогов // Труды МФТИ. - 2014. - Т. 6, № 3 (23). - С. 27-36.
A Method for Designing a Directory Service Data Storage Structure to Reduce Response Time When Querying for Large Amounts of Data
Andreyev A.V. Saint Petersburg State University of Aerospace Instrumentation Saint Petersburg, Russia aathexf@gmail.com
Abstract. A method for designing the directory service data structure to reduce the directory services's response time during requesting a large amount of data is proposed. This article discusses the LDAP directory services and network data structure, where directory entries are stored in the appropriate directory branches for each given service using the directory service. Entries are grouped by service priority conditions. True fulfillment of several conditions for a single record is implemented by the alias entries that conform to the LDAP standard.
Keywords: directory service, LDAP, response time, method, directory structure
References
1. Butcher M. Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services, Packt Publishing, 2007. -484 p.
2. Howes T.A., Smith M.C., Good G.S. Understanding and Deploying LDAP Directory Services, 2nd edition, Addison-Wesley Professional, 2003. - 936 p.
3. OpenLDAP Software 2.4 Administrator's Guide: Tuning. Available at: http://www.openldap.org/doc/admin24/ tuning.html (accessed 20.05.2019).
4. Andreyev A. V. Mathematical Model of a Directory Service [Matematicheskaya model' sluzhby katalogov], Information and Control Systems [Informatsionno-upravliaiushchie sistemy], 2014, No. 4 (71). - Pp. 85-87.
5. Gordeyev A.V., Andreyev A.V. OpenLDAP Directory Service Structure as a Search Filter [Struktura kataloga kak fil'tr poiska zapisey sluzhby katalogov OpenLDAP], Information and Control Systems [Informatsionno-upravliaiushchie sistemy], 2019, No. 2 (99). - Pp. 52-56.
6. RFC 4512 - Lightweight Directory Access Protocol (LDAP): Directory Information Models. Available at: http://tools.ietf.org/html/rfc4512 (accessed 20.05.2019).
7. RFC 4511 - Lightweight Directory Access Protocol (LDAP): The Protocol. Available at: http://tools.ietf.org/html/rfc4511 (accessed 20.05.2019).
8. Glenn W., Simpson M.T. MSCE Self-Paced Training Kit (Exam 70-297): Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure, Redmond, Washington, Microsoft Press, 2004. - 459 p.
9. Miller R. B. Response Time in Man-Computer Conversational Transactions, AFIPS Conference Proceedings, 1968, Vol. 33, Pt. 1, Pp. 267-277.
10. Shneiderman B. Designing the user interface: Strategies for effective human-computer interaction, 1st edition, Reading, MA, Addison-Wesley, 1987, 448 p.
11. Seow S.C. Designing and Engineering Time: The Psychology of Time Perception in Software, Addison-Wesley Professional, 2008. - 224 p.
12. Jain R.K. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, New York, NY, John Wiley & Sons, 1991. - 720 p.
13. Stupak N. Time delays and system response times in human-computer interaction (2009). Thesis. Rochester Institute of Technology. - 102 p. - URL: http://scholarworks.rit.edu/the-ses/1370.
14. Andreyev A.V. Network Data Model of Directory Services [Setevaya model' dannykh sluzhby katalogov], Proceedings of Moscow Institute of Physics and Technology [Trudy MFTI], 2014, Vol. 6, No. 3 (23). - Pp. 27-36.
