Вот уже более пятнадцати лет на сети железных дорог функционирует автоматизированная система бронирования мест и продажи билетов АСУ "Экспресс-2", обеспечивающая все основные потребности по резервированию мест, продаже билетов и управлению пассажирскими перевозками в целом. Функциональные возможности системы значительно шире возможностей большинства аналогичных зарубежных систем. Решение в последнее время ряда важнейших задач - внедрение автоматизированной продажи по ходу следования поезда на всей сети и новой децентрализованной системы ввода НСИ позволяет ближайшие 3-4 года с достаточно высоким качеством обслуживать основные технологические потребности пассажирских перевозок.
В то же время изменившаяся среда функционирования системы (рыночная экономика, образование независимых государств, необходимость расширения взаимосвязей со смежными системами) требует постоянного развития и модернизации функций системы, однако делать это в системе, разработанной средствами, имевшимися в нашем государстве 20 лет назад, становится практически невозможно. Операционная система TKS, в рамках которой функционирует АСУ "Экспресс-2", не может использовать более одного процессора и более 16 МB оперативной памяти, то есть вычислительные мощности современных ЭВМ используются не полностью. Эффективное использование современных сетей передачи данных в рамках операционной системы TKS также невозможно.
Использование возможностей эволюционного перехода программных комплексов для системы "Экспресс" представляется весьма ограниченным. Основной задачей существующего программного комплекса являлось создание системы массового обслуживания с приемлемыми характеристиками на технической базе, отличающейся низкой производительностью, малыми объемами как внешней, так и оперативной памяти и весьма низкой надежностью. Эта задача была успешно решена, что предопределило крайне высокую сложность системы, невозможность использования стандартных систем управления базами данных (СУБД), значительное вмешательство прикладной системы в операционную среду, программирование функций ввода-вывода на физическом уровне. Все это делает невозможным перенос системы в современную операционную среду без полной замены комплекса программ организации вычислительного процесса и значительной доработки прикладных программ. Опыт эксплуатации системы "Экспресс-2" показывает острую необходимость использования в таких системах программно-аппаратных средств "высокой готовности", обеспечивающих на уровне аппаратуры, микропрограмм, операционной системы и СУБД дублирование информации и обеспечение ее сохранности.
Рассмотрев значительное количество вариантов дальнейшего развития системы, разработчики пришли к выводу, что единственно приемлемым решением является быстрое (в течение 3-4 лет) создание и внедрение новой системы управления пассажирскими перевозками АСУ "Экспресс-3". Система "Экспресс-3" должна разрабатываться с использованием современных средств проектирования (стандартные СУБД, языки высокого уровня, мониторы транзакций, системы телеобработки с современной сетевой архитектурой, операционная система OS/390). Это позволит существенно снизить трудозатраты на создание и последующее развитие системы, ее стыковку с другими системами и комплексами.
Очевидно, что осуществить правильный выбор СУБД, основываясь только на теоретических описаниях и исследованиях невозможно. Задачи проектируемой системы являются достаточно специфическими задачами массового обслуживания. Следовательно, наиболее полное соответствие возможностей выбираемой СУБД потребностям этой системы может быть выявлено только в ходе тестирования на специально спроектированном примере, отражающем специфику задачи.
Программное обеспечение системы "Экспресс" разработано, исходя из требований, предъявляемых к системам массового обслуживания, работающим в режиме реального времени:
В данном случае под термином "заказ" понимается некоторая транзакция, которая начинается с поступлением заявки (запроса) от пассажира и заканчивается с выдачей ответа на поступившую заявку. При этом характеристики этой транзакции можно считать аналогичными характеристикам усредненной транзакции, полученной на смеси всех возможных заявок. Ниже (при описании модели системы) будут рассмотрены две транзакции, соответствующие двум наиболее часто встречающимся в этой смеси заявкам.
В целях повышения производительности и надежности работы в системе реализован специальный комплекс программ организации вычислительного процесса, включающий:
специализированные средства доступа к данным с использованием физического метода доступа (EXCP), реализующие многие механизмы современных СУБД с обеспечением высокой производительности;
специализированный диспетчер, обеспечивающий мультипрограммную организацию обработки заявок без использования ресурсоемких стандартных средств ОС;
иерархическую структуру памяти, предусматривающую хранение наиболее часто используемой информации в оперативной памяти;
специализированные программные средства, обеспечивающие работу двухмашинного комплекса с разделением функций между ЭВМ (для ЕС ЭВМ);
специализированные программные средства защиты и восстановления информации при сбоях и отказах технических средств.
Математическое обеспечение реализовано в рамках стандартной операционной системы TKS432 (режим SVS архитектуры S/370).
База данных системы "Экспресс-2" представляет собой файловую систему с собственным механизмом доступа. База данных состоит из двух частей:
Таблицы загружаются в оперативную память при инициализации системы и обрабатываются в оперативной памяти. Изменения в них сохраняются на МД специальными механизмами поддержания целостности базы. Таблицы хранятся в библиотечном наборе данных и обновляются "inplace".
Файлы делятся на:
Все файлы имеют специальные управляющие таблицы, позволяющие находить нужную запись за одно обращение к МД. В файлах с ключами поиск по ключу применяется только в пределах одной дорожки МД, нужная дорожка определяется по таблицам. Для удобства создания и использования новых файлов был реализован специальный механизм файлов с дескриптором. Такие файлы содержат записи фиксированной или переменной длины, объединенные в блоки. В управляющей таблице файла для каждого блока указан максимальный дескриптор, в который попадает данная запись. Если места в нем недостаточно то блок делится на два. Такая структура позволяет найти и прочесть любую запись за одно обращение к МД, при записи требуется одно, максимум - два обращения. Предусмотрены средства для последовательного чтения такого файла в порядке возрастания дескриптора.
Доступ к файлам базы данных отделен от прикладных программ и осуществляется через специальные интерфейсные модули.
Тестирование проводилось на укрупненной модели системы резервирования, необходимой для сравнительной оценки СУБД и других системных программных средств с точки зрения производительности системы. При этом рассматривались два основных варианта моделей данных:
Объем сформированных тестовых данных определялся исходя из следующих параметров:
Приведенные количественные характеристики не уступают соответствующим характеристикам данных, обрабатываемых существующей АСУ "Экспресс-2".
Ниже представлены перечни таблиц для каждой из этих моделей. Логическая схема тестовой базы данных для реляционной модели данных представлена на рис. 2-1. В ней перечислены основные таблицы базы, участвующие в резервировании мест, указаны ссылочные номера таблиц, используемые индексы, а также оценка размера каждой таблицы.
Рисунок 2-1.
Логическая схема реляционной базы данных
Общий объем всех таблиц без учета индексного пространства составляет 15275 МБ + 15% для индексного пространства.
Физическая схема этой базы данных для реляционной модели данных представлена на рис. 2-2.
Рисунок 2-2.
Физическая схема реляционной базы данных
Использование постреляционной модели позволит существенно уменьшить количество таблиц и избыточность хранения информации. В постреляционной модели объединяются:
Остальные таблицы остаются такими же, как и у реляционной модели данных.
Проектируемая система "Экспресс-3" должна состоять из множества взаимосвязанных компонентов. Некоторые из них, занимая относительно небольшое место в общем объеме проектирования, в силу массовости применения во многом определяют как итоговую производительность всей системы в целом, так и эффективность ее эксплуатации. Среди подобных подсистем безусловно находится система резервирования мест и продажи билетов.
Функционально система резервирования состоит из следующих подсистем.
Среди перечисленных выделяются две массовые функции, составляющие по данным эксплуатации "Экспресс-2" примерно 88% от всех запросов:
Особую важность этим функциям придает то обстоятельство, что с их помощью происходит непосредственное обслуживание клиентов.
Соответственно двум указанным функциям рассматриваются и две базовые заявки на обслуживание:
Алгоритм обработки заявки на получение информации реализуется в виде транзакции типа "Т1" и выполняет:
Схема транзакции "Т1" для реляционной модели данных представлена на рис. 2-4.
Рисунок 2-4.
Транзакция "Т1" - заявка на получение информации (реляционная модель)
Схема транзакции "Т1" для постреляционной модели данных представлена на рис. 2-5.
Рисунок 2-5.
Транзакция "Т1" - заявка на получение информации (постреляционная модель)
Алгоритм обработки заявки на резервирование мест реализуется в виде транзакции типа "Т2" и выполняет:
При обновлении записей поля, по которым построены индексы, не обновляются.
Схема транзакции "Т2" для постреляционной модели данных представлена на рис. 2-7.
Рисунок 2-7.
Транзакция "Т2" - заявка на резервирование мест (постреляционная модель)
Технические характеристики Mainframe IBM 9672 приведены в таблице 3-1.
Таблица 3-1.
Технические характеристики интегрированного дискового массива EMC Symmetrix приведены в таблице 3-2.
Таблица 3-2.
Для организации терминального доступа к Mainframe использовались два варианта:
Все варианты тестирования были выполнены под управлением операционной системы OS/390. Для разработки прикладных программных средств и выполнения тестирования использовались интерактивные средства TSO и пакетные задания.
Тестовые базы данных для всех СУБД размещались на дисковых томах типа IBM 3390-3, предоставляемых интегрированным дисковым массивом Symmetrix. Оптимизация размещения базы данных не предусматривалась.
Рисунок 3-1.
Демонстрационный стенд
В прототипировании схематической модели системы резервирования мест и продажи билетов для двух основных видов заявок использовались средства и возможности трех современных высокопроизводительных СУБД:
Каждая из современных СУБД, предназначенных для построения и эксплуатации больших информационных систем, имеет реализацию для аппаратной платформы IBM Mainframe под управлением операционной среды OS/390 и, в силу этого, обладает целым рядом свойств, общих для всех СУБД. Важнейшими общими свойствами указанных выше СУБД являются:
Рисунок 4-1.
Работа современной СУБД в операционной среде OS/390
Любая из СУБД, участвовавших в тестировании, по функциональным возможностям принципиально пригодна для реализации на ее основе системы "Экспресс-3".
СУБД ORACLE-7 для платформы MVS (OS/390) - это замкнутый комплекс интегрированных компонент, утилит, сервисных средств обслуживания и администрирования баз данных, а также интерфейсов доступа для прикладных систем.
ORACLE поддерживает реляционную модель данных и использует язык описания и манипулирования данными SQL - простое и, вместе с тем, мощное средство доступа к базам данных. Все операции над информацией в ORACLE используют конструкции SQL.
Помимо компонента ORACLE-сервер, обслуживающего базу данных, имеется несколько реализаций компонента ORACLE-клиент для различных клиентских сред:
Важнейшие функции ORACLE-сервера доступны через механизм подсистем MVS. К ним относятся функции администрирования базы данных, управляющие:
Для концентрации всех аспектов управления конкретной базой данных используется компонент "многозадачный монитор" (MPM).
Дополнительными возможностями среды ORACLE, не входящими в базовую реализацию СУБД, являются:
Для выполнения служебных специальных функций предназначен набор обслуживающих программ - утилит.
Ключевым компонентом ORACLE является менеджер доступа (ORACLE Access Manager). Данный компонент управляет доступом прикладных процессов пользователей, выполняющихся под управлением CICS или MS/TM. При этом обеспечивается механизм исполнения распределенной транзакции.
DB/2 - это реляционная СУБД фирмы IBM, работающая под управлением операционной системы OS/390, являющейся развитием MVS. DB/2 Server, так же, как и ORACLE, реализован для широкого спектра технических платформ и операционных сред.
В операционной среде OS/390 DB/2 выступает как подсистема MVS. Как подсистема MVS DB/2 имеет свой префикс (обычно DSN1), который используется для идентификации сервисов DB/2.
Доступ к данным DB/2 возможен одновременно из нескольких прикладных программ пользователей, работающих под TSO, CICS или в пакетном режиме. Для системных целей используются специальные программы - утилиты. Утилиты могут работать одновременно с прикладными программами. В качестве структур хранения DB/2 использует VSAM-наборы данных. Для управления системой DB/2 используются команды. Создание, удаление, изменение характеристик структур DB/2, а также доступ к самим данным производится только с помощью операторов SQL.
Операторы SQL могут выполняться из прикладных программ или используя возможности, предоставляемые интерактивным интерфейсом DB/2. Также имеется специальная программа, выполняющаяся в пакетном режиме, входом для которой служат операторы SQL.
ADABAS - универсальная среда хранения данных и организации доступа к ним. Реализованная на широком спектре технических и операционных платформ - от Windows NT до OS/390 на IBM Mainframe, СУБД ADABAS предоставляет универсальный высокопроизводительный инструмент работы с данными в технологии клиент-сервер.
В операционной среде OS/390 СУБД ADABAS реализована на уровне "подсистемы MVS" как сетевой сервер баз данных.
СУБД ADABAS свойственны некоторые специфические возможности, например:
Прикладные программы для тестирования реализации схематической модели средствами СУБД ORACLE разработаны на языке С специалистами фирмы ORACLE. Для моделирования двух типов заявок написаны различные программы.
При разработке внутренних структур данных, а также при реализации транзакций, специалисты фирмы ORACLE ориентировались на достижение максимальной производительности теста. Для этой цели:
Все отмеченные отступления от схематической модели не позволяют сопоставить результаты, показанные тестами СУБД ORACLE с тестами других СУБД.
Прикладные программы, разработанные специалистами ТехноСерв А/С для тестирования СУБД DB/2, написаны на языке программирования PL/1 с использованием интерфейса PL/1-SQL. Модель данных в базе данных строго соответствует реляционной модели, описанной в разделе 2 настоящей статьи.
Реализованы принципы моделирования серий независимых заявок (одна заявка - одна транзакция), и случайности данных в каждой заявке.
Прикладные программы, разработанные специалистами ТехноСерв А/С для тестирования СУБД ADABAS, написаны на языке программирования NATURAL в архитектуре "программа-подпрограмма". Головная программа осуществляет при этом моделирование серий случайных заявок, для исполнения которых происходит обращение к подпрограммам.
Для каждой из моделей данных, реляционной и постреляционной, предусмотренных схематической моделью задачи, был разработан отдельный комплекс тестовых программ, размещенных в независимых библиотеках системы программирования NATURAL.
В ходе тестирования многократно выполнялись рабочие прогоны прикладных программ, эмулирующих нагрузку системы резервирования мест сериями случайных запросов. Получаемые при этом количественные данные усреднялись с отбрасыванием крайних значений, чтобы исключить влияние случайных факторов.
После обработки и усреднения данные о прогоне серий тестов для каждой тестировавшейся СУБД были сведены в таблицу 6-1.
Таблица 6-1.
Следует отметить, что при написании прикладных программ для тестирования и разработке структур файлов базы данных специалисты фирмы ORACLE существенно отошли от заданной схемы данных, результатом чего явилось получение данных тестирования, принципиально несопоставимых с данными по другим тестировавшимся СУБД. При сравнительном анализе возможностей тестировавшихся СУБД результаты ORACLE не будут приниматься в расчет.
Вместе с тем, результаты ORACLE будут играть важную роль при обсуждении способов увеличения производительности прикладного программного обеспечения проектируемой системы "Экспресс-3".
Выводы данного раздела основаны на сравнении данных в следующих строках сводной таблицы результатов тестирования:
Модель данных в системе резервирования мест и продажи билетов принципиально может соответствовать классической реляционной модели. По такой схеме выполнены тестовые примеры DB/2. Успешность реализации и полученные количественные характеристики позволяют сделать следующие выводы:
Несомненными достоинствами реляционной модели данных как таковой, существенными для проектируемой системы "Экспресс-3", являются:
Выводы данного раздела основаны на сравнении данных в следующих строках сводной таблицы результатов тестирования:
В ходе настоящего тестирования ни по одной из тестировавшихся СУБД не была достигнута "пиковая" производительность, предусмотренная Техническим заданием на разработку системы "Экспресс-3" (250 заказов/сек). Следовательно, проблема повышения производительности является ключевой и поиску путей ее решения необходимо уделить максимальное внимание.
Достижение необходимой производительности системы невозможно без применения специальных решений по структурам данных. К ним относятся:
Кроме того необходимо применение специальных приемов программирования для реализации небольшого числа массовых заявок. К ним относятся:
Существенный выигрыш в производительности дает также использование прямого обращения к средствам СУБД из программ на языках низкого уровня, например на ассемблере.
Вместе с тем программирование большинства прикладных задач возможно и необходимо вести с применением средств разработки 4GL (NATURAL, VisualGen, Developer 2000 и др.), обеспечивающими необходимую гибкость и универсальность.
Пример результатов, показанных в тестах ORACLE, показывает потенциальные возможности вышеперечисленных способов.
Применение рассмотренных способов повышения производительности дает качественный скачок (10 - 40-кратное ускорение). При этом:
Подводя итог анализа способов повышения производительности прикладной системы, использующей базы данных, применительно к проектируемой системе "Экспресс-3" можно сделать следующий основной вывод.
Применение стандартных СУБД в "чистом виде", без специальных технологических и математических приемов организации информации и ее обработки, не позволяет добиться поставленной цели - 250 заказов в секунду. Для заявок типа "Т2" максимальная достигнутая производительность - 40 заказов в секунду.
Возможности для дальнейшего увеличения производительности системы "Экспресс-3" могут быть найдены на следующих направлениях:
Указанные выше меры позволят обеспечить производительность системы на уровне 120-150 заказов в секунду. При необходимости обеспечения более высокой производительности потребуется организация использования группы ЭВМ, связанных Escon-каналами и работающих в режиме "Parallel Sysplex".