Содержание к диссертации
Введение
Глава 1. Модели анализа процессов доступа к базам данных 12
1.1. Классификация моделей доступа к базам данных 12
1.1.1. Модель файлового сервера доступа к данным пример 12
1.1.2. Модель сервера базы данных доступа к данным 14
1.1.3. Модель сервера приложений доступа к данным 16
1.1.4. Модель доступа к данным в Intranet/Internet по технологии CGI и API 19
1.1.5. Модель доступа к данным в Intranet/Internet из Java-апплетов и ActiveX 21
1.1.6. Модель доступа к данным в системах с архитектурами CORBA и DCOM 23
1.2. Анализ существующих методов оценки показателей качества обработки запросов к базе данных 27
1.2.1. Использование систем массового обслуживания 27
1.2.2. Калибруемые аналитические модели 30
1.2.3. Стоимостные модели 32
1.2.4. Методы анализа процессов доступа к базам данных, основанные на знаниях 36
1.3. Организация оптимизации выполнения запросов к базе данных 38
ВЫВОДЫ 45
Глава 2. Метод оценки времени выполнения запросов с учётом вложенных коррелированных подзапросов и операций агрегирования атрибутов 47
2.1. Преобразование SQL-запроса с вложенными коррелированными подзапросами и операциями агрегирования 47
2.2. Некоторые свойства преобразования Лапласа-Стилтьеса и производящей функции 59
2.3. Оценка времени выполнения исходного запроса с несколькими уровнями вложенности подзапросов при наличии операций агрегирования 61
2.4. Оценка времени выполнения запроса с несколькими уровнями вложенности подзапросов после преобразования дерева операций в альтернативный план 66
2.5. Сравнение времени выполнения запроса для исходного и альтернативного плана 69
ВЫВОДЫ 80
Глава 3. Доработка комплекса инструментальных средств анализа моделей доступа к базам данных распределённых систем обработки данных 82
3.1. Структура КС AM 82
3.2. Схема базы данных КС AM 86
3.3. Организация базы знаний КС AM 90
3.4. Машина вывода 92
3.5. Доработка КСАМ 93 ВЫВОДЫ 97
Глава 4. Моделирование модулей «Контингент» и «Факультет военного обучения» автоматизированной системы МГТУ им. Н.Э. Баумана с учётом запросов к базе данных 99
4.1. Моделирование информационной системы «Контингент» 99
4.1.1. Назначение и структура системы «Контингент» 99
4.1.2. Результаты моделирования системы «Контингент» 107
4.2. Моделирование информационной системы «Факультет военного обучения» 119
4.2.1. Назначение и структура системы «Факультет военного обучения» 120
4.2.2. Результаты моделирования системы «Факультет военного обучения» 132
Выводы 143
Заключение 147
Литература
- Модель файлового сервера доступа к данным пример
- Анализ существующих методов оценки показателей качества обработки запросов к базе данных
- Некоторые свойства преобразования Лапласа-Стилтьеса и производящей функции
- Результаты моделирования системы «Контингент»
Модель файлового сервера доступа к данным пример
Здесь приложения выполняются на рабочих станциях. Рабочая станция - это автоматизированное рабочее место (АРМ) сотрудника организации. Приложение включает модули для организации диалога с пользователем, бизнес-правила (это специальный термин), обеспечивающие требуемую логику вычислений в АС, и ядро СУБД [4,38]. Часто ядро СУБД в модели файлового сервера не является выраженным и представляет собой набор функций, связанных с остальными компонентами приложения (FoxPro и др.). Приложение, включая и ядро СУБД, дублируется на различных рабочих станциях. На файловом сервере хранятся только файлы базы данных (индексы, файлы данных и т. д.) и некоторые технологические файлы (оверлейные файлы, файлы сортировки и др.) [4,38]. Команды обращений к СУБД, закодированные в прикладной программе, обрабатываются ядром СУБД на рабочей станции. СУБД организует доступ к хранящимся на сервере файлам базы данных АС для выполнения каждой такой команды [4,38].
На рис. 1.1 отрезком прямой обозначена локальная вычислительная сеть. По сети передаются запросы на чтение/запись данных, индексы, промежуточные и результирующие данные, блоки технологических файлов.
На основе модели файлового сервера функционируют такие популярные СУБД как Access, FoxPro ( Microsoft), dBase (Borland), Clipper (Nantucket Inc.), Paradox (Borland) и др. [4,38]. СУБД рассматриваемого класса стоят недорого, просты в установке и освоении. Но они обладают и рядом существенных недостатков [4,38]: системы, разработанные на базе этих СУБД, имеют низкую производительность, т. к. все промежуточные данные передаются, как правило, по низкоскоростной шине сети, а прикладные программы и ядро СУБД АС выполняются на маломощных рабочих станциях, эти СУБД не поддерживают распределённую обработку, в FoxPro, dBase, Clipper поддерживается стандарт Xbase, который теперь теряет популярность [43].
Здесь приложения также выполняются, в основном, на рабочих станциях. Приложение включает модули для организации диалога с пользователем и бизнес-правила. Ядро СУБД АС является общим для всех рабочих станций и функционирует на сервере [4,38,43]. На рис. 1.2 и далее отрезком прямой обозначается локальная вычислительная сеть или взаимосвязанные сети передачи данных (локальные, магистральные, глобальные). Операторы обращений к СУБД (SQL-операторы [47,8,48,49]), закодированные в прикладной программе, не выполняются на рабочей станции, а пересылаются по сети на сервер для обработки. Ядро СУБД транслирует запрос и выполняет его, обращаясь для этого к индексам и другим промежуточным данным. Обратно на рабочую станцию передаются только результаты обработки оператора [4,38].
В современных СУБД на сервере могут запускаться так называемые хранимые процедуры и триггеры, которые вместе с ядром СУБД образуют сервер СУБД. К хранимым процедурам можно обращаться из приложений на рабочих станциях. Это позволяет сократить размер кода прикладной программы и уменьшить поток SQL-операторов с рабочей станции, так как группу требуемых SQL-предложений можно закодировать в хранимой процедуре. Триггеры - это программы, которые выполняются ядром СУБД перед или после обновления (UPDATE, INSERT, DELETE) таблицы базы данных. Они позволяют автоматически поддерживать целостность базы данных [4,8,48].
Анализ существующих методов оценки показателей качества обработки запросов к базе данных
В [28] приведено описание инструментально-моделирующего комплекса КОК для оценки качества функционирования информационных систем. По мнению авторов, эта система позволяет получить количественную оценку следующих показателей: своевременности, надёжности предоставления информации, полноты, актуальности, безошибочности используемой информации, безошибочности действий пользователей и обслуживающего персонала, защищённости от вирусов, защищённости информационных и программных ресурсов от несанкционированного доступа, конфиденциальности информации. Использование предлагаемых в [28, 29, 30, 31] математических методов оценки приведённых выше показателей вызывает ряд критических замечаний.
Для оценки своевременности используется СМО M/G/1/oo с различными дисциплинами обслуживания очередей. Здесь входные потоки - это запросы пользователей на ввод исходной информации в БД, получение выходных данных и пересылку сообщений, запросы на выполнение технологических операций. Обслуживание включает следующие работы: запоминание в БД, получение выходных документов, выполнение технологических операций, пересылку сообщений. В предлагаемой модели не учитываются особенности выполнения приложений; для неё непросто получить исходные данные; трудно проверить выполнение предпосылок использования модели. Тем более в этой модели не учитывается механизм декомпозиции запросов к распределенной базе данных на подзапросы и особенности их обработки в узлах автоматизированной системы; не учитываются объемы данных промежуточных и результирующих таблиц базы данных, передаваемых по каналам связи.
В работе [18] представлены и исследованы имитационные модели для нескольких вариантов архитектуры клиент-сервер (с учетом механизмов репликации между БД, распараллеливания дискового ввода-вывода и кэширования на клиентской стороне). Модели исследованы с учётом комплексной нагрузки: множественных входных запросов на чтение и обновление данных.
Клиент
Модель сервера СУБД представлена на рис. 1.8 [22]. В данной модели заявки (запросы) поступают на обслуживание из сети от клиентов. Каждая заявка состоит из запросов к СУБД на чтение (селекция, проекция или соединение) и запись (вставка, удаление или обновление). Обнаружение взаимных блокировок осуществляется через заданные интервалы времени и занимает определенное время поиска. В случае обнаружения взаимной блокировки процессор нагружается дополнительным процессом удаления блокирующей транзакции. Удаленный процесс перезапускается через определенный промежуток времени и поступает вновь на обработку в зависимости от наполнения входной очереди. Общее число выполняемых запросов в системе не превышает установленного предела MPL. Модель сервера СУБД включает подмодель механизма контроля параллельного доступа. Данный модуль позволяет моделировать наложение блокировок на данные (моделируются разделяемые и эксклюзивные блокировки) с проверкой таблицы существующих блокировок. В зависимости от существования эксклюзивной блокировки запрос может быть отправлен на обработку или в очередь блокированных запросов. После обработки запрос поступает в модуль СМ, который снимает блокировки и передает результат запроса клиенту. Репликация между серверами моделируется с помощью специальных запросов на передачу изменений в БД, зафиксированных в журналах транзакций.
Модель сети (см. рис. 1.8) относительно проста и характеризуется параметрами задержки вызова RPC и временем передачи данных, которое вычисляется исходя из скорости передачи. Среди недостатков данной модели следует отметить следующие [22]: 1) модель не позволяет вычислить время обработки запросов в СУБД; 2) модель является имитационной, а, следовательно, позволяет моделировать лишь небольшие системы с невысокой нагрузкой; 3) модель СПД применима только к сети с дуплексным режимом передачи данных; 4) модель не позволяет учитывать параметры запросов.
Некоторые свойства преобразования Лапласа-Стилтьеса и производящей функции
Ниже приведены некоторые известные свойства преобразования Лапласа-Стилтьеса и производящей функции [36], которые используются далее при доказательстве теорем. I. Преобразование Лапласа-Стилтьеса (ПЛС) функции распределения вероятностей случайной величины: 4(s) = \e-"dF(t), (2.1) о где F(t)— функция распределения вероятностей случайной величины й Часто для сокращения говорят о преобразовании Лапласа-Стилтьеса случайной величины.
Свойства преобразования Лапласа-Стилтьеса: 1. 4 (0) = (-1) ( ), (2.2) где 4 (0) - п-я производная Ч при s = 0, M(J;n) - n-й начальный момент случайной величины , М() - математическое ожидание. к
2. Пусть = Х/ - сумма независимых случайных величин, тогда /=i имеет место равенство ( ) = ПЗД, (2.3) /=1 здесь (s) - преобразование Лапласа-Стилтьеса случайной величины , (s) - преобразование Лапласа-Стилтьеса случайной величины , i = l,k.
П. Производящая функция (ПФ) функции распределения вероятностей дискретной случайной величины с целыми неотрицательными значениями: оо оо ГО0=ЕлЛ2 /=1, (2-4) /=о /=о где pi - вероятность, что случайная величина Травна і.
Часто для сокращения говорят о производящей функции дискретной случайной величины. Свойства производящей функции: 1. Имеют место равенства Т \\) = М{%), Г 2)(1) = М(#2)-М(#), (2.5) Г(и)(0) = п\Р( = п), (2.6) где T n\z) -производная Г(г) в точке z, Р(, - п) - вероятность, что случайная величина ё, равна п. к
2. Пусть = Х; - сУмма независимых случайных дискретных ве /=1 личин, тогда имеет место равенство Г(г) = Пад, (2.7) где T{z) - производящая функция случайной величины , ГДг) - производящая функция случайной величины ., / = \,к. В частности из (2.7) следует, что производящая функция числа попаданий для схемы испытаний Бернулли равна T(z) = (l-p + pzf, (2.8) здесь р - вероятность попадания (успешного испытания), N - число испытаний. к
3. Пусть = Х гДе независимые случайные дискретные величины /=1 имеют одинаковые распределения вероятностей с производящей функцией u(z), а к - случайная дискретная величина с производящей функцией y(z). Тогда для производящей функции T{z) случайной величины справедливо равенство T(z) = y(u(z)) (2.9)
4. Если - случайное число заявок с производящей функцией y{z), a fi(s) - преобразование Лапласа-Стилтьеса времени обработки одной за явки, то преобразование Лапласа-Стилтьеса времени обработки В, заявок будет равно W(s) = yWs)) (2.10)
В этом разделе получены оценки характеристик времени выполнения запроса для случая, когда для реализации поиска данных используется дерево разбора, представленное нарис. 2.3. Введем некоторые обозначения. Atj - у -й атрибут таблицы (отношения) R{, i = \,n. Dy = [dijm ) - домен (множество разных значений) атрибута Ay. Ij, = iDjj - мощность домена. j]ijm - вероятность, что атрибут А{,- какого-нибудь кортежа (записи) h таблицы Rt принимает значение dijm, щт =1. Вероятности щт можно /и=1 задать априори или получить из гистограмм, которые могут быть построены утилитой СУБД сбора статистик (например, программой ANALYZE в СУБД Oracle). Для записей из таблиц {/?,}будем считать независимыми в совокупности события K= U (2-И) для тех атрибутов Ау, по которым выполняется поиск в БД (т.е. которые указываются в условии поиска WHERE). Vt - число записей в таблице Rt. Gt (z) = z - производящая функция числа записей в таблице Rt. Hj(z) - производящая функция числа записей, обработанных (прочитанных) на / -ом уровне вложенности и ниже для каждой записи / -1 -го уровня при реализации запроса в соответствии с планом на рис. 2.3. H{z) - производящая функция числа записей, обработанных при выполнении исходного запроса в соответствии с планом нарис. 2.3. 7} (s) - ПЛС времени обработки записей / -ого уровня вложенности и ниже для каждой записи / -1 -го уровня при реализации запроса в соответствии с планом на рис. 2.3.
Результаты моделирования системы «Контингент»
Целью моделирования ИС «Контингент» с помощью КСАМ является определение работоспособности системы при пиковых нагрузках, возмож пости расширения системы с использованием существующих аппаратных средств, выявление «узких мест» системы и поиск способа их устранения с учётом запросов к базе данных. При моделировании не учитывались фоновые потоки в сетях и фоновые процессы, выполняемые на сервере и рабочих станциях.
ИС «Контингент» представлена сервером СУБД, Web-сервером и сервером приложений, а также рабочими станциями (терминалами). Физически сервер СУБД, Web-сервер и сервер приложений расположены на одной станции. Запросы с терминалов передаются по сети на сервер приложений, обрабатываются, и их результаты передаются обратно на терминалы. При необходимости сервер приложений обращается к СУБД.
Для описания параметров ИС «Контингент» в среде КСАМ были выполнены следующие действия:
1. Описана схема базы данных (см. рис. 4.2).
Для этой цели были введены наименования частей предметной области ИС «Контингент» («Приказ», «Структура университета», «Студент»). Для каждой из этих частей введены наименования реквизитов, которые затем были использованы для описания атрибутов таблиц базы данных. Реквизиты части «Приказ»: attributes, date_created, date_activated, html, number, orderjd, order_status_id, paragraphed. Реквизиты части «Структура университета»: current_term_nurnber, department_id, departmentjnum, faculty_id, group_id, group_num, name, short_name. Реквизиты части «Студент»: father_name, first_name, last_name, stu-dent_id, student_state_id.
Введены наименования таблиц базы данных, к которым осуществляется доступ при выполнении наиболее важных запросов, приведённых в пункте 4.1.1. Для каждой таблицы заданы атрибуты на основании описания реквизитов предметной области. Для каждой таблицы задано прогнозируемое количество записей (табл. 3).
Для каждого атрибута указано количество байтов, необходимое для хранения значения атрибута согласно типу данных.
Для каждого атрибута указана мощность. Под мощностью понимается число разных значений атрибута в базе данных, оно определялось преимущественно на основании данных о количестве записей в таблицах.
Для каждой таблицы заданы индексы, как минимум один - первичный ключ. Первичные ключи показаны на схеме базы данных (см. рис. 4.2).
2. Описаны наиболее важные запросы и транзакции (см. пункт 4.1.1).
Для моделирования с помощью КСАМ были выбраны несколько наиболее важных (наиболее часто используемых) функций ИС «Контингент». Каждая функция визуально представляет собой одну форму просмотра и ввода данных.
Для каждой функции ИС «Контингент», моделируемой в КСАМ, создана транзакция. Каждая транзакция в КСАМ может состоять из запросов и других транзакций. В случае ИС «Контингент» использование вложенных транзакций не требуется, каждую функцию можно промоделировать одной транзакцией.
Созданы запросы, используемые для реализации выбранных функций ИС «Контингент». Для каждой транзакции указан набор запросов, входящий в ее состав. В данном случае каждая транзакция состоит только из одноименного запроса (табл. 4).
Для каждого запроса указан набор таблиц, используемых в запросе (Из FROM-части приведенных запросов). Для каждого запроса указан признак курсора (ни в одном запросе курсор не используется). Для каждой таблицы, входящей в состав запроса, указаны тип операции, условие поиска, признаки обработки.
Возможность моделирования информационных систем с учётом запросов к базе данных является одной из важнейших особенностей системы КСАМ.
3. Описана архитектура сети, которой подключен модуль «Контингент».
Воспроизведен вариант архитектуры «Контингент». Создана конфигурация узла «Proliant ML530G2T 2Р», указаны данные для расчета производительности из результатов теста ТРС-С (отчёт от 8 января 2003 г.).
Созданы узлы «Сервер БД», «Сервер приложений» и «Терминал» (так обозначены рабочие станции) , узлу «Сервер БД» назначена конфигурация «Proliant ML530G2T 2Р».
Создан канал сети (Канал 1) между узлами «Сервер приложений» и «Терминал». Тип сетевого канала- порт коммутатора на 100 Мбит/с, к которому подключён сервер модуля «Контингент».
Создана конфигурация канала с пропускной способностью 1000Мбит/с. Создан канал связи (Канал 2) между узлами «Сервер приложений» и «Сервер БД» на 1000Мбит/с. Этот канал моделирует передачу данных между задачами «Сервер приложений» и «Сервер БД» с учётом времени задержки на переключение задач.
Указано количество узлов типа «Сервер БД» (1), «Сервер приложений» (1) и количество узлов типа «Терминал» (1000), а также процент заполнения диска узла типа «Сервер БД» (30).
Целью моделирования ИС «Контингент» с помощью КСАМ является определение работоспособности системы при пиковых нагрузках, возмож пости расширения системы с использованием существующих аппаратных средств, выявление «узких мест» системы и поиск способа их устранения с учётом запросов к базе данных. При моделировании не учитывались фоновые потоки в сетях и фоновые процессы, выполняемые на сервере и рабочих станциях.
ИС «Контингент» представлена сервером СУБД, Web-сервером и сервером приложений, а также рабочими станциями (терминалами). Физически сервер СУБД, Web-сервер и сервер приложений расположены на одной станции. Запросы с терминалов передаются по сети на сервер приложений, обрабатываются, и их результаты передаются обратно на терминалы. При необходимости сервер приложений обращается к СУБД.
Для описания параметров ИС «Контингент» в среде КСАМ были выполнены следующие действия:
1. Описана схема базы данных (см. рис. 4.2).
Для этой цели были введены наименования частей предметной области ИС «Контингент» («Приказ», «Структура университета», «Студент»). Для каждой из этих частей введены наименования реквизитов, которые затем были использованы для описания атрибутов таблиц базы данных. Реквизиты части «Приказ»: attributes, date_created, date_activated, html, number, orderjd, order_status_id, paragraphed. Реквизиты части «Структура университета»: current_term_nurnber, department_id, departmentjnum, faculty_id, group_id, group_num, name, short_name. Реквизиты части «Студент»: father_name, first_name, last_name, stu-dent_id, student_state_id.
Введены наименования таблиц базы данных, к которым осуществляется доступ при выполнении наиболее важных запросов, приведённых в пункте 4.1.1. Для каждой таблицы заданы атрибуты на основании описания реквизитов предметной области. Для каждой таблицы задано прогнозируемое количество записей (табл. 3).
Для каждого атрибута указано количество байтов, необходимое для хранения значения атрибута согласно типу данных.
Для каждого атрибута указана мощность. Под мощностью понимается число разных значений атрибута в базе данных, оно определялось преимущественно на основании данных о количестве записей в таблицах.
Для каждой таблицы заданы индексы, как минимум один - первичный ключ. Первичные ключи показаны на схеме базы данных (см. рис. 4.2).
2. Описаны наиболее важные запросы и транзакции (см. пункт 4.1.1).
Для моделирования с помощью КСАМ были выбраны несколько наиболее важных (наиболее часто используемых) функций ИС «Контингент». Каждая функция визуально представляет собой одну форму просмотра и ввода данных.
Для каждой функции ИС «Контингент», моделируемой в КСАМ, создана транзакция. Каждая транзакция в КСАМ может состоять из запросов и других транзакций. В случае ИС «Контингент» использование вложенных транзакций не требуется, каждую функцию можно промоделировать одной транзакцией.
Созданы запросы, используемые для реализации выбранных функций ИС «Контингент». Для каждой транзакции указан набор запросов, входящий в ее состав. В данном случае каждая транзакция состоит только из одноименного запроса (табл. 4).
Для каждого запроса указан набор таблиц, используемых в запросе (Из FROM-части приведенных запросов). Для каждого запроса указан признак курсора (ни в одном запросе курсор не используется). Для каждой таблицы, входящей в состав запроса, указаны тип операции, условие поиска, признаки обработки.
Возможность моделирования информационных систем с учётом запросов к базе данных является одной из важнейших особенностей системы КСАМ.
3. Описана архитектура сети, которой подключен модуль «Контингент».
Воспроизведен вариант архитектуры «Контингент». Создана конфигурация узла «Proliant ML530G2T 2Р», указаны данные для расчета производительности из результатов теста ТРС-С (отчёт от 8 января 2003 г.).
Созданы узлы «Сервер БД», «Сервер приложений» и «Терминал» (так обозначены рабочие станции) , узлу «Сервер БД» назначена конфигурация «Proliant ML530G2T 2Р».
Создан канал сети (Канал 1) между узлами «Сервер приложений» и «Терминал». Тип сетевого канала- порт коммутатора на 100 Мбит/с, к которому подключён сервер модуля «Контингент».
Создана конфигурация канала с пропускной способностью 1000Мбит/с. Создан канал связи (Канал 2) между узлами «Сервер приложений» и «Сервер БД» на 1000Мбит/с. Этот канал моделирует передачу данных между задачами «Сервер приложений» и «Сервер БД» с учётом времени задержки на переключение задач.
Указано количество узлов типа «Сервер БД» (1), «Сервер приложений» (1) и количество узлов типа «Терминал» (1000), а также процент заполнения диска узла типа «Сервер БД» (30).
