Автоматизация процессов интеграции данных в высоконагруженных информационных системах с оптимизацией характеристик по рейтингу запросов

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Специальность 05.13.06 - Автоматизация и управление

технологическими процессами и производствами (полиграфические средства информации и информационные системы)

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

Автоматизация процессов интеграции данных в высоконагруженных информационных системах с оптимизацией характеристик по рейтингу запросов

Морозов Юрий Владимирович

Москва - 2011

Работа выполнена на кафедре «Информатика и вычислительная техника»

ФГБОУ ВПО «Московский государственный университет печати».

Научный руководитель: доктор технических наук, доцент

Попов Дмитрий Иванович

Официальные оппоненты: доктор технических наук, профессор

Марков Аркадий Алексеевич

доктор технических наук, профессор

Остроух Андрей Владимирович

Ведущая организация:

Северо-западный институт печати

Санкт-Петербургского государственного университета технологии и дизайна

Защита состоится «15» сентября 2011 г. в 12.00 на заседании диссертационного совета Д 212.147.03 при ФГБОУ ВПО «Московский государственный университет печати им. Ивана Федорова» по адресу 127550, г. Москва, ул. Прянишникова, дом 2А.

С диссертацией можно ознакомиться в библиотеке ФГБОУ ВПО «Московский государственный университет печати».

Автореферат разослан « » июня 2011 г.

Ученый секретарь диссертационного совета Д 212.147.03: д.т.н., профессор Агеев В.Н.

1. Общая характеристика работы

Актуальность проблемы. Любому крупному предприятию, такому как издательско-полиграфический комбинат, производственный концерн, холдинг или проектная организация приходится иметь дело с огромным объемом разнородной информации, поступающей из различных информационных систем, которую необходимо обрабатывать и анализировать с целью ее последующего использования в бизнес-процессах или технологическом цикле производства.

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

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

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

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

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

1.3. Задачи исследования. В соответствии с поставленной целью в работе решены следующие задачи:

анализ существующих архитектур, моделей, методов и алгоритмов интеграции и управления данными на промышленных предприятиях;

исследование проблем оптимизации систем интеграции и управления данными высоконагруженных информационных систем;

разработка основных функций и структуры автоматизированной системы интеграции и управления данными;

разработка архитектуры хранилища данных;

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

разработка методики и алгоритмов определения рейтинга запроса по точности его формулировки.

оценка эффективности предлагаемых методик, моделей и архитектур на основе моделирования и расчетного исследования.

решение практических задач по разработке базы данных, проектированию алгоритмов и программного обеспечения системы интеграции и управления данными промышленного предприятия.

1.4. Методы исследования. Для достижения поставленных целей и решения задач использованы методы математической статистики, теории массового обслуживания. Разработка программ для реализации алгоритмов проведена на языках программирования C#, Transact-SQL.

1.5. Областью исследования является автоматизация процессов интеграции и управления данными в информационных системах, разработка методологии построения комплексных систем интеграции и управления данными, разработка специализированного программного обеспечения для этих систем и его оптимизация.

1.6. Научная новизна полученных в данной работе результатов состоит в следующем:

Предложена структура СИУД, в отличие от существующих архитектур позволяющая в комплексе и в полном объеме решить задачи автоматизации процессов интеграции и управления данными. Программное обеспечение, построенное с использованием данной архитектуры, не нуждается в дополнительной доработке под нужды конкретного предприятия, в отличие от существующих продуктов известных разработчиков.

Разработана архитектура хранилища данных СИУД, отличающаяся от известных архитектур более высокой производительностью при обработке сложных запросов и эффективностью хранения версионной информации.

Разработан метод исследования времени ответа СИУД на основе применения модели теории массового обслуживания для систем с приоритетами.

Разработан метод, позволяющий уменьшить среднее время ответа системы на запрос на основе введения рейтингов запросов, определяемых по степени их информативности (точности), предложен алгоритм вычисления рейтингов.

1.7. Методологической основой исследования являются работы в области интеграции данных промышленных предприятий, основанные на использовании механизмов веб-сервисов, сервисов сообщений, брокера сообщений, хранилищ данных (работы Ф. Миллера, В. Рэйнарди, Д. Уэддингтона, Д.И. Мутина, И.А. Тарханова, В.А. Камакина).

1.8. Достоверность полученных результатов подтверждается использованием математического аппарата теории вероятностей и теории массового обслуживания, выводом основных соотношений для определяющих характеристик модели, результатами полномасштабного тестирования, проведенного с использованием симуляционного моделирования (метод Монте-Карло), успешной апробацией и внедрением разработанного подхода на крупных предприятиях и в организациях различных отраслей промышленности.

1.9. Оценка теоретической значимости результатов работы. Полученные математические, информационные модели и алгоритмы являются теоретической основой для создания автоматизированной системы интеграции и управления данными.

1.10. Практическая ценность работы. На основании предложенных теоретических разработок была разработана универсальная автоматизированная система интеграции и управления данными промышленных предприятий, позволяющая автоматизировать процессы интеграции данных на предприятиях различных отраслей, в том числе и полиграфической.

Применение данного программного обеспечения позволило автоматизировать процессы интеграции и управления проектными данными ОАО «Атомэнергопроект», операционными данными оборудования АЭС ОАО «ВНИИАЭС». Некоторые модули системы применялись на предприятиях полиграфической отрасли и МГУ Печати им. Ивана Федорова.

1.11. На защиту выносятся следующие положения:

Структура информационной системы интеграции и управления данными, обеспечивающая в полном объеме необходимый функционал по автоматизации процессов интеграции, управления, версионного контроля и согласования разнородных данных высоконагруженных ИС;

Архитектура хранилища данных СИУД, позволяющая хранить разнородные данные из различных информационных систем и поддерживающая механизмы согласования данных и контроля версий;

Метод анализа эффективности работы СИУД на основе введения системы рейтингов, позволяющий использовать в информационных системах элементы теории массового обслуживания для повышения эффективности системы;

Алгоритм вычисления рейтингов запросов, основанный на точности формулировки запроса, позволяющий снизить среднее время выполнения заявки.

1.12. Апробация работы. Модели и алгоритмы, полученные автором данной работы, докладывались на конференции МедиаФест 2009, использовались в Институте открытого образования МГУ Печати, предприятиях полиграфической отрасли; программное обеспечение, разработанное на их базе, используется в ОАО «Атомэнергопроект», ОАО «ВНИИАЭС»

1.13. Публикации. Основные работы изложены в 5 научных публикациях, в том числе в ведущих рецензируемых научных изданиях, рекомендуемых ВАК - 1 статья.

1.14. Структура работы. Диссертационная работа состоит из введения, четырех глав, заключений по каждой главе, основных результатов и выводов, библиографического списка и 3 приложений. Основной текст изложен на 147 страницах, содержит 40 рисунков, 3 таблицы и 3 приложения. Библиографический список содержит 102 наименования.

2. Содержание диссертации

Во введении обосновывается актуальность работы. Ставятся цели и задачи исследования. Приводятся основные положения работы.

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

Современные требования к управлению производством предполагают необходимость принятия обоснованных управленческих решений в условиях большого объема поступающей информации и ограниченного времени на ее обработку и анализ. Поэтому для решения проблем систематизации и поиска информации на промышленных предприятиях в настоящее время широко применяются вычислительные средства и разнообразное программное обеспечение.

Данные, используемые каждой информационной системой предприятия, в общем случае, могут сильно розниться: они могут быть как полностью, так и частично структурированными, получаться из различных источников в различных форматах в различных объемах и в разное время. Отдельного упоминания стоит также проблема достоверности данных. Очевидно, что некоторая часть данных, используемая предприятием, не находится в стационарном состоянии в одном программном комплексе, но проходит свой жизненный цикл, на протяжении которого постоянно меняется и переходит из одного программного комплекса в другой.

Все вышеперечисленные факторы подчеркивают необходимость создания и использования специальных информационных систем, автоматизирующих процессы интеграции и управления данными. В настоящее время, на рынке существует несколько классов продуктов, так или иначе связанных с управлением данными, например, такие, как системы документооборота (Documentum), ERP-системы (SAP, Dynamics) или OLAP-системы. Системы документооборота или ERP-системы являются специализированными для управления предприятием и для реализации механизмов интеграции и управления данными требуют серьезной доработки (а порой и переработки). Системы типа OLAP являются интеграционными, но не являются универсальными: они предназначены для быстрого построения отчетов путем преобразования формы хранения данных. Кроме того, опыт и наработки серьезных производителей программного обеспечения зачастую закрыт для исследователей.

Использование промышленных механизмов и методов, предназначенных для интеграции данных, например таких, как веб-сервисы, коннекторы Java, сервисы сообщений, брокеры сообщений (WebSphere) или же хранилища данных, подробно рассмотрено в работах многих исследователей. Среди них: Биберщтейн Н., Боуз С., Ньюкоммер Э. Миллер Ф., Дэвис Дж., Шороу Д., Рей С., Рибер Д., Фленов М., Уэддингтон Д., Шарма Р., Стиарнс Б., Нг Т., Генкин М., Хапнер М., Барридж Р., Литтихузен Р., Имхофф К., Галеммо Н., Рэйнарди В.

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

Работы таких исследователей, как Г. Зауфер, М.Сельваж, Э. Лейн, Б. Мэтьюс, А. Кудинов, Ю.В. Козадой, К.Уайт, П. Лихницкий, К.В. Антипин, А.В. Фомичев, М.Н. Гринев, С.Д. Кузнецов, Л.Г. Новак, П.О. Плешачков, М.П. Рекуц, Д.Р. Ширяев, И.Полотнюк, И. Гордиенко, Д.И. Мутин, И.А. Тарханов, В.А. Камакин, С. Федечкин, А.Н. Ахунов, А.В. Ложечкин, А.А. Ломакин, Р.А. Плющенков относятся к решению проблем автоматизации интеграции и управления данными.

При этом, несмотря на наличие большого количества работ по теме интеграции и управления данными, работы, комплексно решающие практические проблемы, отсутствуют. Тем не менее, некоторые идеи и наработки, описанные в работах вышеперечисленных авторов, например такие, как использование стандарта XML для передачи данных, использование реляционной СУБД для хранения данных были развиты и адаптированы для разработанной системы.

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

Современные информационные системы, начиная от операционных систем, заканчивая корпоративными интеграционными системами или СУБД, в своей работе используют механизм очередей и обслуживающих устройств. Иными словами, любая информационная система может быть представлена в виде взаимодействующих систем массового обслуживания. Система называется высоконагруженной в случае, когда среднее число запросов, находящихся в очереди обслуживающего устройства, превышает единицу. Ввиду того, что система практически постоянно находится в работе, задача по минимизации времени ожидания обслуживания имеет большое практическое значение.

Для исследования факторов, влияющих на эффективность работы информационных систем, строится модель исследования со следующими требованиями:

1. Модель системы должна описывать процессы поступления запросов, их накопления и обслуживания.

2. Модель должна допускать наличие приоритетов у определенных групп запросов. Последнее важно, так как запросы могут иметь существенно различное время обработки, и наличие приоритетов, следовательно, влияет на характеристики работы системы.

3. Модель должна допускать использование различных законов распределения для времени обработки запросов различных групп, поскольку дисперсия времени обработки также может существенно различаться и, тем самым, влиять на показатели эффективности системы.

4. Исследование свойств системы должно проводиться в предположении случайного потока не связанных между собой запросов, не подвергаемых предварительной обработке или просеиванию.

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

Допущение модели, касающееся пуассоновского входящего потока запросов, не ограничивает общность рассуждений: во-первых, предметом анализа является исследование свойств системы в стационарном (установившемся) режиме, что позволяет использовать стационарное значение параметра потока, которое не зависит от наличия последействия, а во-вторых, пуассоновский поток является моделью предельного перехода в случае, когда результирующий поток является суммой многих частных потоков запросов, не связанных между собой и носящих сугубо случайный характер.

Представление модели в виде одноканальной системы допустимо, так как позволяет аналитически исследовать основные параметры и закономерности, влияющие на свойства системы. При этом, переход к большей размерности качественно не меняет указанные свойства, а влияет только на количественные значения показателей эффективности.

Таким образом, описанная выше модель является достаточной для постановки и решения задачи начальной оптимизации системы.

Для исследования свойств системы в отсутствие приоритетов вводятся следующие обозначения. Обозначим - параметр входящего потока заявок, - параметр потока обслуженных заявок, приведенный ко времени работы системы (обратная величина к среднему времени обслуживания заявок Т0). При определении показателей эффективности системы на установившемся периоде работы важное значение имеет параметр , характеризующий степень ее загрузки.

Другими важными характеристиками эффективности системы, которые должны быть определены по соотношению и , являются среднее число заявок в системе N в некоторый произвольный момент времени, среднее число заявок в очереди n и W -среднее время ожидания обслуживания в очереди.

Для экспоненциального времени обслуживания указанные величины могут быть представлены следующими простыми выражениями:

(1)

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

Для этого случая указанные выше характеристики определяются по формулам, известным как формулы Поллачека-Хинчина.

(2)

(3)

. (4)

В указанных формулах есть коэффициент вариации распределения случайного времени обслуживания запроса (отношение среднеквадратичного отклонения к математическому ожиданию). Для решения поставленной задачи исследуется влияние на основные параметры системы введения приоритетов. Постулируется следующая дисциплина очереди:

Заявка, имеющая i-й приоритет, при поступлении в систему становится в очередь впереди заявок с более низшими приоритетом (i+1, i+2, … R).

В соответствии с общим подходом предполагается, что , где лk - параметр потока заявок из группы с приоритетом k; при этом потоки, образованные различными группами заявок, являются пуассоновскими.

Пусть также:

; ; , (5)

В (5) обозначает параметр, характеризующий загрузку системы с учетом запросов до приоритета r включительно. Тогда в результате вывода получим, что

, и (6)

(7)

. (8)

(9)

В формуле (9) есть математическое ожидание времени, оставшегося до окончания обслуживания обрабатываемого запроса после поступления нового требования в систему с учетом всех приоритетов.

Видно, что полученные формулы (6)и (8) полностью совпадают с (2), (3) при R=1, т.е. когда приоритеты запросов не введены.

Цель проводимого исследования состоит в том, чтобы найти параметры запросов, поступающих в систему, используя которые можно минимизировать целевые характеристики, представленные соотношениями (6), (8).

Из (6), (8) следует, что наличие приоритетов оказывает влияние на значение характеристик эффективности через общий член для обеих полученных выше формул:

. (10)

При этом время нахождения и среднее число заявок в очереди, а также общее среднее время обслуживания отличаются на константу .

Из сказанного следует, что поставленная задача может быть решена на основе введения рейтинга запросов, в зависимости от их информативности (точности). Указанные характеристики влияют на среднее время обработки запроса. Следовательно, если в (6) и (8) приоритеты запросов связать с их рейтингами, получим механизм, формализующий влияние внутренних параметров запросов на характеристики эффективности системы.

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

> min, при (11)

, для любого 1?r?R

Доказывается, что задача (12) имеет следующее решение, представленное Теоремой 1:

Пусть в условиях, сформулированных выше, выполняются требования:

м1 ? м2 … ? мR, (12)

тогда набор рейтингов в соответствии с (12) обеспечивает решение поставленной экстремальной задач. Другими словами, наиболее высокие рейтинги должны отвечать наименьшим временам обработки запросов системой.

Доказательство Теоремы 1 осуществляется с использованием доказательства вспомогательной Леммы:

Для того, чтобы

,

приняло минимально возможное значение на множестве подстановок , достаточно выполнения условия:

при всех 1 ? k? R.

Из Леммы следует, что SR достигает минимума, если для любого r.

Поскольку , данное условие эквивалентно условию для любого r. Таким образом, SR будет минимальным, если выполнено , что и доказывает утверждение теоремы.

Из полученного результата следует важный вывод: независимо от значений параметров потоков запросов, поступающих в систему, при введении рейтингов запросов в соответствии со временем их обработки (чем больше указанное время, тем ниже должен быть рейтинг) получается решение искомой оптимизационной задачи.

В соответствии с разработанной теорией далее в работе предлагается подход к определению времени обработки запроса.

Пусть реляционная база данных состоит из совокупности таблиц, причем каждая таблица представляет набор полей, характеризующих свойства объекта. Множество значений каждого поля, очевидно, меньше либо равно числу всех записей в таблице. При этом равенство достигается только в том случае, когда значение поля однозначно определяет объект. Пусть N и ni, соответственно, общее количество записей и количество записей, отвечающих значению i данного поля. Среднее время и второй момент распределения времени обработки запроса можно вычислить по формулам:

(13)

(14)

Где T1- время, необходимое для обращения к уникальной записи, pi = ni / N.

Если запрос включает поиск по нескольким полям таблицы, его целесообразно начинать с наиболее информативных полей, то есть с полей, в которых ni и, соответственно, pi минимальны. В этом случае:

(15)

, (16)

где k пробегает множество полей таблицы, участвующих в запросе, а k* отвечает полю, в котором (16) минимально.

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

Исследования, произведенные во второй главе, позволяют сформулировать следующие основные выводы:

Время обработки запросов в значительной мере влияет на скорость работы всей системы.

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

Рейтинги запросов определяются только временем их обработки.

Предложен подход к оценке среднего времени обработки запросов в зависимости от информативности (точности) их формул.

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

Разработанная структура является многозвенной (рис. 1). Подобный подход увеличивает масштабируемость системы, позволяя переносить различные подсистемы на отдельные физические сервера. Для хранения информации используется реляционная СУБД. С одной стороны, данный тип СУБД предусматривает увеличение сложности системы за счет необходимости добавления ORM (Object-relational mapping, объектно-реляционное отображение) подсистем, в роли которых выступает система исполнения запросов к СУБД. С другой стороны, производительность и надежность объектных СУБД, позволяющих упростить архитектуру системы, до сих пор подробно не исследована в научных трудах, а, следовательно, можно столкнуться с неизвестными проблемами при проектировании сложных и высоконагруженных информационных систем.

Рис. 1. Структура системы интеграции и управления данными

Подсистема извлечения и преобразования данных предназначена для изменения формата данных, поступающих из различных интегрируемых подсистем, в объектную форму, используемую внутри системы интеграции и управления. Данная подсистема является важной частью СИУД, так как обеспечивает интегрируемые системы универсальным набором интерфейсов обмена информацией. Подсистема обеспечивает следующие интерфейсы обмена:

Обмен при помощи загрузки / выгрузки файлов.

Обмен данными через сервис с локальными системами.

Обмен данными через сервис с удаленными системами.

XML веб-сервис предназначен для взаимодействия с удаленными информационными системами и приложениями через интернет. Использование отдельного внешнего XML веб-сервиса обуславливается следующими причинами:

Наличием на отдельном сервере сетевых экранов, дополнительных протоколов аутентификации и шифрования, требующих дополнительных аппаратных ресурсов.

Увеличением отказоустойчивости: если злоумышленникам удастся вывести из строя сервер, это никак не скажется на функциональности других подсистем и модулей системы интеграции и управления информацией.

Так как взаимодействие отдельного XML веб-сервера с системой можно ограничить лишь несколькими портами, то существует возможность создать демилитаризованную зону для этого сервера.

Внешний XML веб-сервис предоставляет в общем случае следующие функции:

Аутентификацию внешних пользователей.

Шифрование запросов и ответов на запросы.

Описание опубликованных типизированных интерфейсов взаимодействия.

Описание нетипизированного интерфейса взаимодействия.

Обеспечивает взаимодействие с единой системой по описанным интерфейсам.

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

Узел исполнения - это программа, расположенная на отдельном или же общем сервере, занимающаяся исполнением объектных запросов, полученных от узла диспетчирования. Каждый узел исполнения зарегистрирован на одном из узлов-диспетчеров, так что узел-диспетчер может направлять запросы на обслуживание на разные узлы исполнения (рис. 2).

В разработанной архитектуре подсистема обслуживания объектных запросов реализует следующие функции:

Получение заявок в объектной форме на получение, изменение и удаление объектов.

Реализация очереди заявок с приоритетом.

Исполнение заявок.

Взаимодействие с объектным кэшем для минимизации количества взаимодействий с СУБД.

Взаимодействие с подсистемой исполнения запросов к БД.

Взаимодействие с подсистемой исполнения бизнес-процессов для передачи информации по объектам, участвующим в этих процессах.

Рис. 2. Структура подсистемы обслуживания объектных запросов

Подсистема исполнения запросов к БД предназначена для получения запросов в объектной форме, перевода их в язык TSQL, исполнения и возврата результирующих данных в объектной форме. Подсистема выполнена в виде отдельной веб-службы и может располагаться физически как на отдельном сервере, так и на общем сервере с подсистемой обработки объектных запросов.

В общем случае подсистема исполнения запросов к БД реализует следующие функции:

Получение заявок в объектной форме на получение, изменение и удаление объектов.

Преобразование объектной формы в форму TSQL с учетом синтаксиса конкретного производителя базы данных.

Помещение запроса в форме TSQL в очередь.

Выполнение запроса к БД.

Получение ответа на запрос и преобразование его в объектную форму.

Подсистема управления бизнес-процессами предназначена для выполнения функций и процедур над бизнес-объектами в соответствии с существующими описаниями. Подсистема получает бизнес-объекты от подсистемы исполнения объектных запросов и производит над ними необходимые операции. Измененные объекты автоматически сохраняются в базе данных, для чего имеются интерфейсы взаимодействия с подсистемой исполнения запросов к БД.

В разработанной модели подсистема управления бизнес-процессами реализует следующие функции:

Получение заявок на вызов бизнес-процесса.

Взаимодействие с системой исполнения для получения необходимых для работы бизнес-объектов.

Обеспечение контекста исполнения бизнес-процесса.

Взаимодействие с подсистемой исполнения запросов к БД для сериализации и десериализации медленных бизнес-процессов.

Взаимодействие с подсистемой исполнения запросов к БД для сохранения изменений объектов.

Передача результата выполнения в подсистему исполнения объектных запросов.

Подсистема распределенного кэша предназначена для временного хранения бизнес-объектов с целью уменьшения числа взаимодействий с базой данных и увеличения скорости работы всей системы.

Среди основных функций подсистемы распределенного кэша:

Предоставление механизмов взаимодействия с подсистемой исполнения объектных запросов.

Временное хранение часто используемых бизнес-объектов.

Обеспечение синхронизации и блокировок объектов при редактировании бизнес-объектов или выполнении бизнес-процессов.

Для синхронизации объектов, находящихся в распределенном кэше, разработан способ синхронизации распределенного кэша с превентивной блокировкой. При разработке данного способа были поставлены следующие цели:

Свести к минимуму вероятность возникновения конкурирующих запросов.

Разработать четкий алгоритм разрешения взаимных блокировок в случае возникновения конкурирующих блокировок.

Разработать полностью потокобезопасный кэш.

В случае синхронизации распределенного кэша с превентивной блокировкой каждый объект может состоять в трех статусах: нормальном, активном и блокированном. Объект, находящийся в нормальном статусе, может быть просто сохранен в кэше или же использоваться в операциях, требующих права только для чтения. Объект находится в активном статусе, если предполагается, что в ближайшее время объект может быть изменен. Объект переводится в этот статус, когда пользователь открывает конкретный объект на просмотр, и у него есть права на изменение. Объект находится в статусе «блокирован», если пользователь находится в режиме редактирования или изменил некоторые данные.

При переводе объекта из статуса «нормальный» в статус «активный» всем группам узлов с распределенным кэшем посылается уведомление о переводе объекта в другой статус. При этом в таблице состояния объектов отмечается, какой узел перевел объект в новый статус. После этого, чтобы другим узлам заблокировать этот объект, необходимо дополнительно «согласовать» блокировку с этой группой узлов.

При переводе объекта из статуса «активный» в статус «блокированный» всем группам узлов с распределенным кэшем посылается соответствующее уведомление. При этом любые попытки других узлов обработки заблокировать этот объект будут отвергнуты.

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

Модель базы данных СИУД должна разрабатываться с учетом специфики всей системы. На основе этих требований в работе формулируются требования к модели БД:

Модель должна позволять хранить неограниченное количество типов объектов.

Модель должна позволять изменять типы объектов «на лету».

Модель должна обеспечивать стабильную скорость извлечения данных вне зависимости от степени наследования объектов.

Модель должна обеспечивать возможность сквозного поиска по свойствам.

Модель должна обеспечивать возможность эффективного хранения версий.

В качестве решения, реализующего все перечисленные требования, была предложена объектная модель БД, разработанная в диссертационной работе. В основе объектной модели лежит идея, что любой информационный объект описывается как набор свойств, связей и методов, а типы объектов отличаются друг от друга лишь набором этих свойств, связей или методов. Соответственно, если в основу заложить именно свойства и связи, то данный подход позволит описать сколь угодно сложный информационный объект. Для модели, изображенной на рис. 3, структуру хранения можно изобразить следующим образом (рис. 4 и 5):

Рис.3. Пример бизнес-модели

Рис. 4. Пример хранения схемы в объектной модели базы данных



Рис. 5. Уровень данных в объектной модели

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

База данных, спроектированная с использованием предложенного подхода, позволяет:

Хранить неограниченное количество классов бизнес-объектов, так как схема БД не зависит от количества и состава классов.

Изменять классы «на лету», поскольку описание классов не связано с физической структурой БД.

Извлекать всю необходимую информацию с одинаковой скоростью вне зависимости от степени наследования, так как каждое значение свойства имеет ссылку на класс объекта и свойство.

Поскольку свойство - это отдельная сущность в БД, то сквозной поиск по свойству не представляет сложности.

Благодаря принципиально иному способу хранения данных, БД с предложенной моделью хранит данные намного эффективнее.

Кроме того, разработанная модель БД реализует все функции управления данными: полноту, целостность, достоверность и контроль версий.

Для обеспечения полноты и целостности информации, хранимой в БД, используется механизм доменов. Домен - сущность СИУД, определяющая область действия элементов схемы и данных. Каждому интегрируемому приложению ставится в соответствие свой домен, который может содержать собственную, отличную от других доменов, схему данных.

Рис. 6. Механизм доменов

Для обеспечения достоверности информации, хранимой в БД, можно воспользоваться механизмом доменов и процедур согласования. Процедура согласования - автоматическая или ручная процедура, позволяющая выбрать правильное значение свойства, если свойство представлено в нескольких интегрируемых приложениях.

Например, некоторый класс объекта является составным и получает информацию о своих свойствах из трех приложений. В базе данных будут созданы четыре домена, при этом интеграционный домен будет содержать только уникальные свойства (рис. 6). Значения свойств, повторяющихся в разных доменах, могут определяться автоматически по предопределенным правилам или же вручную через интерфейс пользователя СИУД. До момента согласования данных значения таких свойств в домене интеграции пустые, а данные носят статус недостоверных. После процедуры согласования все значения свойств в домене интеграции заполняются, а данные получают статус достоверных.

Для реализации функционала контроля версий в системе присутствуют четыре типа версий:

Предыдущие версии - версии информационных объектов на определенный момент времени в прошлом. Предыдущие версии не подлежат изменению.

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

Утвержденная версия - версия информационного объекта, подписанная ответственным лицом. Эта версия используется для получения официальной информации по объекту системы. Статус утвержденной версии объект получает после прохождения процедуры утверждения. Утвержденная версия не подлежит изменению.

Утверждаемая версия - версия информационного объекта, участвующая в процедуре утверждения. После успешного прохождения процедуры, утвержденная версия становится предыдущей, а утверждаемая - текущей. Утверждаемая версия не подлежит изменению.

С учетом рассмотренных требований модель базы данных СИУД уровня схемы, построенная по объектному принципу, выглядит следующим образом:

Рис. 7. Диаграмма состояний версий

Основываясь на подходе к определению рейтинга запроса, описанном в главе 2, был разработан алгоритм определения рейтингов запросов, нашедший свое применение в подсистеме исполнения объектных запросов. Основной алгоритм состоит из двух частей. В первой части алгоритма вычисляются значения N и набор {ni}, являющихся, соответственно, общим количеством объектов и количеством записей, отвечающих значению i свойства объекта.

Далее вычисляется величина (13) при условии, что значением T1 - время, необходимое для обращения к уникальной записи, - можно пренебречь из-за модели базы данных, предполагающей примерно одинаковые значения для любых объектов. Эта величина отражает среднее количество записей, которое может быть возвращено в качестве ответа на запрос. Чем меньше объем возвращаемых записей (объектов), тем меньше потребуется времени на извлечение, пересылку и преобразование, а, следовательно, и на исполнение запроса.

Данные первого момента для всех свойств каждого типа объектов записываются в специальную таблицу, из которой в дальнейшем загружаются в подсистему исполнения объектных запросов. Общий вид первой части алгоритма представлен на рис. 8.

Рис. 8. Алгоритм вычисления первого момента

Вторая часть алгоритма состоит из уточнения данных по первому моменту полученными реальными значениями времени исполнения и ранжирования этой величины с учетом доступного количества рейтингов.

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

При поступлении простого запроса на поиск приоритет назначается по минимальному значению момента для всех полей, по которым осуществляется поиск. При поступлении сложного запроса, приоритет запросу назначается как произведение минимальных значений моментов полей всех классов объектов в запросе (рис 9).

Рис. 9. Принципиальный алгоритм вычисления рейтинга заявки.

Четвертая глава включает исследования эффективности предложенных моделей и обоснование целесообразности их использования в СИУД. Для проведения исследований в главе формулируются критерии эффективности, методика и алгоритмы исследования.

На основе данных, полученных в исследовании, делаются выводы об эффективности предложенной объектной модели БД на больших объемах данных при хранении версионной информации или же при большом количестве одновременных запросов. Согласно результатам моделирования, представленным на рис. 10, предложенная объектная модель становится эффективной на больших объемах данных, что соответствовало примерно 3 млн. объектов на тестовой системе. При этом, увеличение количества одновременно выполняющихся запросов вызывает меньшее падение производительности на объектной модели данных: при 20 одновременно выполняющихся запросах время обработки заявки увеличивается примерно в 3 раза для разработанной объектной модели, примерно в 5,5 раз при проецировании классов к таблицам, и более чем в 10 раз при проецировании классов к объектам с использованием наследования (рис. 11).

Эффективность хранения версионной информации в объектной модели выше при любых количествах хранимых версий, что следует из данных экспериментального анализа, результаты которого представлены в виде графика (рис. 12).

Рис. 10. Зависимость времени обработки заявки от количества хранимых объектов

Рис. 11. Зависимость времени обработки заявки от количества одновременных запросов

Рис. 12. Зависимость размера файла БД от количества версий объектов

В заключении формулируются основные выводы, полученные в работе.

Основные выводы и результаты работы

В процессе выполнения диссертационной работы была решена научная задача по автоматизации процессов интеграции и управления данными высоконагруженных информационных систем промышленного предприятия с оптимизацией рабочих характеристик по рейтингу входящих запросов.

Основные результаты и выводы диссертационной работы:

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

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

Проведено теоретическое исследование разработанной модели, определены параметры системы, непосредственно влияющие на время обработки запросов. Предложено и обоснованно использование метода рейтингов заявок для уменьшения среднего времени ожидания заявки в очереди, что позволяет минимизировать время отклика системы.

Разработана методика и алгоритм определения рейтинга запросов в зависимости от информативности (точности) их формулировки,

Разработана автоматизированная система интеграции и управления данными информационных систем. Предложена структура системы, определены основные функции подсистем.

Разработана методика хранения бизнес-объектов в БД, архитектура хранилища данных, алгоритмы сериализации и десериализации.

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

Доказана эффективность предложенных архитектур и алгоритмов хранилища данных и подсистемы кэширования.

Разработанное программное обеспечение полностью или отдельные его подсистемы внедрены и применяются в МГУ Печати им. Ивана Федорова, на предприятиях полиграфической отрасли, в ОАО «Атомэнергопроект», ОАО «ВНИИАЭС» для автоматизации процессов интеграции и управления данными.

Публикации по теме диссертационной работы

Публикации в ведущих рецензируемых научных изданиях, рекомендуемых ВАК

Морозов Ю.В. Оценка эффективности и оптимизация режима работы информационных систем // Известия высших учебных заведений. Проблемы полиграфии и издательского дела 2'2010, М.: 2010. С. 96 - 104.

Другие публикации

Морозов В.Б., Морозов Ю.В. Экспоненциальные оценки безотказности сложных восстанавливаемых изделий со стареющими элементами // Сборник тезисов международной конференции «Математические методы в теории надежности». Москва 2009. С. 147 - 156.

Морозов Ю.В. Модуль автоматизации задач администрирования процессов компьютерного тестирования материалов // Вестник МГУП №5. М.: 2008. С. 87 - 88.

Морозов Ю.В. Использование стандарта XML для передачи и хранения информации в системах тестирования // Вестник МГУП №6. М. 2008. С. 26 - 31.

Морозов Ю.В. Использование механизма рефлексии для создания расширяемых систем // Сборник тезисов международного студенческого фестиваля информационных технологий «МедиаФест 2009». М. 2009. С. 72 - 73

Размещено на Allbest.ru

...