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

1. Введение

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

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

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

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

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

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

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

• работа с большим числом терминалов в одном регионе - до 2000;
• высокая производительность обслуживания входного потока заявок (для ЭВМ типа IBM 4381, COMPAREX 8/**) - до 80 заказов в секунду;
• малое время реакции системы - до 5 секунд;
• высокая надежность функционирования системы;
• недопустимость потери, искажения и необоснованного дублирования циркулирующей информации.

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

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

• специализированные средства доступа к данным с использованием физического метода доступа (EXCP), реализующие многие механизмы современных СУБД с обеспечением высокой производительности;

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

• иерархическую структуру памяти, предусматривающую хранение наиболее часто используемой информации в оперативной памяти;

• специализированные программные средства, обеспечивающие работу двухмашинного комплекса с разделением функций между ЭВМ (для ЕС ЭВМ);

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

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

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

• таблицы;
• файлы.

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

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

• прямые с поиском по номеру записи;
• прямые с поиском по ключу;
• с последовательной записью и прямым чтением;
• прямые с дескриптором.

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

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

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

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

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

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

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

• число станций - 10 000
• число станций на маршруте - 99
• число поездов - 1 000
• число дат - 45
• число вагонов в поезде - 20
• число типов мест - 3 (общие, плацкартные, купейные)
• число вагонов каждого типа в поезде:
• общих - 2
• плацкартных - 9
• купейных - 9
• число пассажиров в вагоне(с учетом сменяемости по маршруту следования поезда) - 70.

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

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

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

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

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

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

• таблицы "Поезд" (1.3) и "Опоздание"(1.4) - в одну таблицу "Поезд" (2.3)
• таблицы "Вагон" (1.5), " Места" (1.7) - в одну таблицу "Вагон" (2.5)

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

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

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

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

• Информационно-справочное обслуживание кассиров и пассажиров (справки о наличии свободных мест).
• Непосредственное резервирование места.
• Вспомогательные действия (ввод новых поездов, возврат билетов, архивирование данных и т.п.).
• Получение аналитических данных о состоянии продаж, населенности и т.п.

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

• Справки о наличии мест (52%)
• Резервирование места (36%)

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

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

• получение информации о возможности резервирования (справка, справка-предложение);
• резервирование мест.

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

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

• выборку 2-х записей из таблицы "Станция" (1.0);
• выборку 200 записей из таблицы "Маршрут" (1.2);
• выборку 10-ти записей из таблицы "Поезд" (1.3);
• выборку 10-ти записей из таблицы "Опоздание" (1.4) (только реляционная модель);
• выборку 150-ти записей из таблицы "Вагон" (1.5);
• выборку 3600 записей из таблицы "Места" (1.7) (только в реляционной модели);
• добавление одной записи в таблицу "Архив" (1.10);

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

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

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

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

• выборку 2-х записей из таблицы "Станция" (1.0);
• выборку 2-х записей из таблицы "Расписание" (1.1);
• выборку 3-х записей из таблицы "Маршрут" (1.2);
• выборку 1-ой записи из таблицы "Поезд" (1.3);
• выборку 1-ой записи из таблицы "Опоздание" (1.4);
• выборку 15-ти записей из таблицы "Вагон" (1.5);
• выборку 360-ти записей из таблицы "Места" (1.7 ) (только в реляционной модели);
• выборку 5-ти записей из таблицы "Тарифы" (1.8);
• добавление 2-х записей в таблицу "Документ" (1.9);
• добавление одной записи в таблицу "Архив" (1.10);
• добавление 1-ой записи в таблицу "Места" (1.7) (реляционная модель);
• обновление 1-ой записи таблицы "Вагон" (2.5) с изменением длины (постреляционная модель);
• обновление 1-ой записи таблицы "Фин-Учет" (1.11);
• обновление 1-ой записи таблицы "Учет резервирования" (1.12).

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

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

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

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

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

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

• Подключение терминалов IBM 3270 через контроллер IBM 3174
• Эмуляция терминала 3270 пакетом IBM Personal Communications на персональной ЭВМ, подключенной к локальной сети (Ethernet 10 Мбит/сек.).

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

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

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

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

• ORACLE
• DB/2
• ADABAS

Каждая из современных СУБД, предназначенных для построения и эксплуатации больших информационных систем, имеет реализацию для аппаратной платформы 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. Наличие развитых средств администрирования баз данных.

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

4.1. СУБД ORACLE

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

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

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

• Пакетных заданий MVS
• Монитора транзакций CICS
• TSO
• ORACLE SQL
• Net и некоторых других.

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

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

Для концентрации всех аспектов управления конкретной базой данных используется компонент "многозадачный монитор" (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. Проблема сопоставимости результатов

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

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

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

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

• (1 и 3) - ADABAS и DB/2
• (2 и 3) - реляционная модель для DB/2 и ADABAS.

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

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

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

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

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

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

• (1 и 2) - ADABAS обе модели данных
• (3 и 4) - реляционная модель для DB/2 и ORACLE.

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

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

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

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

• упрощение процедур поиска и перебора данных,
• построение специализированных индексов для доступа к данным.

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

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

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

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

• специальные структуры данных повышают производительность в 8-10 раз (от DB/2 к ADABAS постреляционной модели)
• тщательное программирование на языке низкого уровня повышает производительность в 2-5 раз (от ADABAS к ORACLE).

7. Выводы

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

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

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

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

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