Banners System

СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #04/97
<< ПРЕДЫДУЩАЯ СТАТЬЯ ] [ ОГЛАВЛЕНИЕ ] [ СЛЕДУЮЩАЯ СТАТЬЯ >>

Сравнительный анализ и выбор СУБД для автоматизированной системы управления пассажирскими перевозками

М. Березка, Л. Винокуров, А. Гершельман, А. Комиссаров, Б. Морозович, И. Родин

1. Введение
2. Описание модели системы
3. Описание стенда
4. Описание тестируемых СУБД
5.Описание процесса тестирования
6. Анализ результатов тестирования
7. Выводы

1. Введение

Вот уже более пятнадцати лет на сети железных дорог функционирует автоматизированная система бронирования мест и продажи билетов АСУ "Экспресс-2", обеспечивающая все основные потребности по резервированию мест, продаже билетов и управлению пассажирскими перевозками в целом. Функциональные возможности системы значительно шире возможностей большинства аналогичных зарубежных систем. Решение в последнее время ряда важнейших задач - внедрение автоматизированной продажи по ходу следования поезда на всей сети и новой децентрализованной системы ввода НСИ позволяет ближайшие 3-4 года с достаточно высоким качеством обслуживать основные технологические потребности пассажирских перевозок.

В то же время изменившаяся среда функционирования системы (рыночная экономика, образование независимых государств, необходимость расширения взаимосвязей со смежными системами) требует постоянного развития и модернизации функций системы, однако делать это в системе, разработанной средствами, имевшимися в нашем государстве 20 лет назад, становится практически невозможно. Операционная система TKS, в рамках которой функционирует АСУ "Экспресс-2", не может использовать более одного процессора и более 16 МB оперативной памяти, то есть вычислительные мощности современных ЭВМ используются не полностью. Эффективное использование современных сетей передачи данных в рамках операционной системы TKS также невозможно.

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

Рассмотрев значительное количество вариантов дальнейшего развития системы, разработчики пришли к выводу, что единственно приемлемым решением является быстрое (в течение 3-4 лет) создание и внедрение новой системы управления пассажирскими перевозками АСУ "Экспресс-3". Система "Экспресс-3" должна разрабатываться с использованием современных средств проектирования (стандартные СУБД, языки высокого уровня, мониторы транзакций, системы телеобработки с современной сетевой архитектурой, операционная система OS/390). Это позволит существенно снизить трудозатраты на создание и последующее развитие системы, ее стыковку с другими системами и комплексами.

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

1.1 Программное обеспечение и доступ к данным в системе "Экспресс-2"

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

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

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

Математическое обеспечение реализовано в рамках стандартной операционной системы TKS432 (режим SVS архитектуры S/370).

База данных системы "Экспресс-2" представляет собой файловую систему с собственным механизмом доступа. База данных состоит из двух частей:

Таблицы загружаются в оперативную память при инициализации системы и обрабатываются в оперативной памяти. Изменения в них сохраняются на МД специальными механизмами поддержания целостности базы. Таблицы хранятся в библиотечном наборе данных и обновляются "inplace".

Файлы делятся на:

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

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

2. Описание модели системы

2.1. Модель данных

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

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

Приведенные количественные характеристики не уступают соответствующим характеристикам данных, обрабатываемых существующей АСУ "Экспресс-2".

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

Рисунок 2-1.
Логическая схема реляционной базы данных

Общий объем всех таблиц без учета индексного пространства составляет 15275 МБ + 15% для индексного пространства.

Физическая схема этой базы данных для реляционной модели данных представлена на рис. 2-2.

Рисунок 2-2.
Физическая схема реляционной базы данных

2.1.2. Перечень основных таблиц (постреляционная модель)

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

Остальные таблицы остаются такими же, как и у реляционной модели данных.

2.2. Укрупненная модель функционирования

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

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

Среди перечисленных выделяются две массовые функции, составляющие по данным эксплуатации "Экспресс-2" примерно 88% от всех запросов:

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

Соответственно двум указанным функциям рассматриваются и две базовые заявки на обслуживание:

2.2.1. Заявка на получение информации

Алгоритм обработки заявки на получение информации реализуется в виде транзакции типа "Т1" и выполняет:

Схема транзакции "Т1" для реляционной модели данных представлена на рис. 2-4.

Рисунок 2-4.
Транзакция "Т1" - заявка на получение информации (реляционная модель)

Схема транзакции "Т1" для постреляционной модели данных представлена на рис. 2-5.

Рисунок 2-5.
Транзакция "Т1" - заявка на получение информации (постреляционная модель)

2.2.2. Заявка на резервирование мест

Алгоритм обработки заявки на резервирование мест реализуется в виде транзакции типа "Т2" и выполняет:

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

Схема транзакции "Т2" для постреляционной модели данных представлена на рис. 2-7.

Рисунок 2-7.
Транзакция "Т2" - заявка на резервирование мест (постреляционная модель)

3. Описание стенда

Технические характеристики Mainframe IBM 9672 приведены в таблице 3-1.

Таблица 3-1.

Технические характеристики интегрированного дискового массива EMC Symmetrix приведены в таблице 3-2.

Таблица 3-2.

Для организации терминального доступа к Mainframe использовались два варианта:

Все варианты тестирования были выполнены под управлением операционной системы OS/390. Для разработки прикладных программных средств и выполнения тестирования использовались интерактивные средства TSO и пакетные задания.

Тестовые базы данных для всех СУБД размещались на дисковых томах типа IBM 3390-3, предоставляемых интегрированным дисковым массивом Symmetrix. Оптимизация размещения базы данных не предусматривалась.

Рисунок 3-1.
Демонстрационный стенд

4. Описание тестируемых СУБД

В прототипировании схематической модели системы резервирования мест и продажи билетов для двух основных видов заявок использовались средства и возможности трех современных высокопроизводительных СУБД:

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

  1. Интеграция в среду OS/390 выполнена на уровне "подсистема MVS", используются средства прямого взаимодействия с другими подсистемами OS/390, пользовательскими прикладными процессами, системными администратором и оператором.
  2. Возможно одновременное управление данными, физически размещенными в нескольких различных базах данных, и организация согласованного многопользовательского доступа к данным.
  3. Наличие интерфейсов с прикладными процессами, выполняющимися под управлением многопользовательских мониторов OS/390: TSO, CICS, JES2 (пакетные задания) и некоторыми другими.
  4. Поддержка полной классической реляционной модели данных и, наряду с этим, наличие средств поддержки постреляционных данных и специальных структур.
  5. Прямая поддержка средств доступа к данным в базе данных на основе стандартных SQL-запросов.
  6. Прямой доступ к средствам СУБД из программ на языках низкого уровня (Ассемблер, С) - основа построения критических высокопроизводительных приложений
  7. Возможность доступа из классических (3GL) языков программирования (PL/1, COBOL) - поддержка "традиционных" приложений.
  8. Наличие высокоуровневых (4GL) средств разработки с развитым пользовательским интерфейсом - основа построения универсальных гибких приложений.
  9. Наличие, наряду с реализацией для платформы Mainframe, версий СУБД для большинства современных серверных платформ (UNIX, OS/2, Windows NT и др.).
  10. Возможность взаимодействия с другими СУБД и прикладными системами на основе системы стандартных интерфейсов (ODBC и т.п.).
  11. Наличие средств организации распределенной обработки данных (серверы приложений, репликация данных, распределенные транзакции) - основа для построения прикладных систем в архитектуре клиент-сервер.
  12. Наличие развитых средств администрирования баз данных.

Рисунок 4-1.
Работа современной СУБД в операционной среде OS/390

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

4.1. СУБД ORACLE

СУБД ORACLE-7 для платформы MVS (OS/390) - это замкнутый комплекс интегрированных компонент, утилит, сервисных средств обслуживания и администрирования баз данных, а также интерфейсов доступа для прикладных систем.

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

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

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

Для концентрации всех аспектов управления конкретной базой данных используется компонент "многозадачный монитор" (MPM).

Дополнительными возможностями среды ORACLE, не входящими в базовую реализацию СУБД, являются:

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

Ключевым компонентом ORACLE является менеджер доступа (ORACLE Access Manager). Данный компонент управляет доступом прикладных процессов пользователей, выполняющихся под управлением CICS или MS/TM. При этом обеспечивается механизм исполнения распределенной транзакции.

4.2. СУБД DB/2

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.

4.3. СУБД ADABAS

ADABAS - универсальная среда хранения данных и организации доступа к ним. Реализованная на широком спектре технических и операционных платформ - от Windows NT до OS/390 на IBM Mainframe, СУБД ADABAS предоставляет универсальный высокопроизводительный инструмент работы с данными в технологии клиент-сервер.

В операционной среде OS/390 СУБД ADABAS реализована на уровне "подсистемы MVS" как сетевой сервер баз данных.

СУБД ADABAS свойственны некоторые специфические возможности, например:

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

5.Описание процесса тестирования

5.1. Тест СУБД ORACLE

Прикладные программы для тестирования реализации схематической модели средствами СУБД ORACLE разработаны на языке С специалистами фирмы ORACLE. Для моделирования двух типов заявок написаны различные программы.

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

Все отмеченные отступления от схематической модели не позволяют сопоставить результаты, показанные тестами СУБД ORACLE с тестами других СУБД.

5.2. Тест СУБД DB/2

Прикладные программы, разработанные специалистами ТехноСерв А/С для тестирования СУБД DB/2, написаны на языке программирования PL/1 с использованием интерфейса PL/1-SQL. Модель данных в базе данных строго соответствует реляционной модели, описанной в разделе 2 настоящей статьи.

Реализованы принципы моделирования серий независимых заявок (одна заявка - одна транзакция), и случайности данных в каждой заявке.

5.3. Тест СУБД ADABAS

Прикладные программы, разработанные специалистами ТехноСерв А/С для тестирования СУБД ADABAS, написаны на языке программирования NATURAL в архитектуре "программа-подпрограмма". Головная программа осуществляет при этом моделирование серий случайных заявок, для исполнения которых происходит обращение к подпрограммам.

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

6. Анализ результатов тестирования

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

После обработки и усреднения данные о прогоне серий тестов для каждой тестировавшейся СУБД были сведены в таблицу 6-1.

Таблица 6-1.

6.1. Проблема сопоставимости результатов

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

Вместе с тем, результаты ORACLE будут играть важную роль при обсуждении способов увеличения производительности прикладного программного обеспечения проектируемой системы "Экспресс-3".

6.2. Достоинства и недостатки реляционной модели данных

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

Модель данных в системе резервирования мест и продажи билетов принципиально может соответствовать классической реляционной модели. По такой схеме выполнены тестовые примеры DB/2. Успешность реализации и полученные количественные характеристики позволяют сделать следующие выводы:

  1. Реляционные модель данных и СУБД могут быть использованы для реализации системы "Экспресс-3"
  2. При следовании требованиям классической реляционной модели данных неизбежна существенная потеря производительности как по отдельным прикладным задачам, так и по всей системе в целом.
  3. При использовании реляционной модели данных лучшие результаты показывает СУБД (DB/2), специально ориентированная на поддержку SQL и реляционной модели.
  4. Реляционная модель данных приводит к существенному увеличению количества объектов, хранимых в базе данных и обрабатываемых прикладными программами.

Несомненными достоинствами реляционной модели данных как таковой, существенными для проектируемой системы "Экспресс-3", являются:

6.3. Проблема повышения производительности

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

В ходе настоящего тестирования ни по одной из тестировавшихся СУБД не была достигнута "пиковая" производительность, предусмотренная Техническим заданием на разработку системы "Экспресс-3" (250 заказов/сек). Следовательно, проблема повышения производительности является ключевой и поиску путей ее решения необходимо уделить максимальное внимание.

Достижение необходимой производительности системы невозможно без применения специальных решений по структурам данных. К ним относятся:

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

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

Вместе с тем программирование большинства прикладных задач возможно и необходимо вести с применением средств разработки 4GL (NATURAL, VisualGen, Developer 2000 и др.), обеспечивающими необходимую гибкость и универсальность.

Пример результатов, показанных в тестах ORACLE, показывает потенциальные возможности вышеперечисленных способов.

Применение рассмотренных способов повышения производительности дает качественный скачок (10 - 40-кратное ускорение). При этом:

7. Выводы

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

Применение стандартных СУБД в "чистом виде", без специальных технологических и математических приемов организации информации и ее обработки, не позволяет добиться поставленной цели - 250 заказов в секунду. Для заявок типа "Т2" максимальная достигнутая производительность - 40 заказов в секунду.

Возможности для дальнейшего увеличения производительности системы "Экспресс-3" могут быть найдены на следующих направлениях:

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

Указанные выше меры позволят обеспечить производительность системы на уровне 120-150 заказов в секунду. При необходимости обеспечения более высокой производительности потребуется организация использования группы ЭВМ, связанных Escon-каналами и работающих в режиме "Parallel Sysplex".


Березка М.П. НИИЖА, e-mail: berezka@glassnet.ru
Винокуров Л.Л. ТехноСерв А/С, e-mail: vll@tsas.msk.ru
Гершельман А.Ф. Техно Серв А/С, e-mail: gaf@tsas.msk.ru
Комиссаров А.В. ВНИИЖТ, e-mail: marchuk@rricc.tsi.ru
Морозович Б.Р. ВНИИЖТ, e-mail: marchuk@rricc.tsi.ru
Родин И.В. ВНИИЖА


Ваше имя:  E-mail: 
Оценка интересности и/или полезности статьи:
интересно и/или полезно
мало интересно или полезно
вредная статья

Стиль изложения
читается легко
несколько трудна для чтения
очень трудно читать
Ваш комментарий:


 

<< ПРЕДЫДУЩАЯ СТАТЬЯ ] [ ОГЛАВЛЕНИЕ ] [ СЛЕДУЮЩАЯ СТАТЬЯ >>
Banners System