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

СУБД и действительно большие системы

Е. Зиндер
Об истории развития системы "Экспресс"
Проблемы при решении проблемы выбора СУБД
Пожелания

Публикуя статью о тестировании СУБД для разработки системы "Экспресс-3" мы сочли целесообразным сопроводить ее редакционным комментарием по следующим причинам:

В связи с этим комментарий содержит три части:

Об истории развития системы "Экспресс"

  1. Система задумана в середине 60-х, главный конструктор (с тех и до сих пор) - Б.Е. Марчук, главный технолог - Н.Н.Красильникова. Система прошла путь развития от сравнительно простой системы продаж железнодорожных билетов в предварительных кассах Киевского вокзала Москвы до комплексной системы резервирования билетов и управления пассажирскими перевозками МПС, работающей в 14-ти регионах России с выходом на железные дороги Европы и Азии, имеющей выходы на другие виды транспорта.
  2. В 1971-1972 годах система "Экспресс" была развернута на трех ЭВМ "Маршрут-1", разработанных специально для данного проекта на основе универсальных машин "Раздан". Требования временной эффективности всегда были в фокусе внимания, может быть поэтому в систему команд "Маршрутов" была включена, например, достаточно экзотическая команда: "Поиск места в купе". Требования надежности решались самыми разными способами, так палладиевые контакты машины пришлось дополнительно золотить купив специально для этого золотое колечко.
  3. Начальный период эксплуатации системы "Экспресс-1" отличался тем, что автоматизированный и ручной режимы продажи билетов соседствовали, число автоматизированных касс было весьма ограниченным, появлялись досадные для потребителей - пассажиров поездов дальнего следования - ошибки (порождались т.н. "двойники" и даже "тройники"), периодические отказы системы приводили к длинным очередям в кассах.
  4. Проблемы, тем не менее, преодолевались. В 1974 г. "Экспресс-1" была введена в масштабах Московского ж.д. узла. Однако старые машины не могли "тянуть" нужное число касс, да и сопровождать физически устаревшую технику становилось невозможно. Был запущен проект разработки второй версии - "Экспресс-2", которая базировалась на ЭВМ Единой Серии и должна была обслуживать все кассы Москвы.
  5. Напряженность режима реального времени, сложность запросов и технические ограничения вступали в конфликт. Моделирование "Экспресс-2" проводили разные группы математиков, ее динамическое моделирование как системы массового обслуживания проводили мои коллеги по НИЛ СМО и ТВМ МИИТа. Не все предложения математиков оказалось возможным принять, в том числе - из-за специфики технологических требований1. В любом случае систему пришлось базировать на специальном комплексе программ "Организация Вычислительного Процесса" - ОВП, заменяющем и расширяющем многие функции операционной системы. Были разработаны специализированные: методы доступа к данным, диспетчер эффективной мультипрограммной обработки заявок, средства иерархической организации памяти, поддержка работы двухмашинного комплекса с ассимметричным распределением функций, средства защиты и восстановления информации. Определяющий вклад в разработку ОВП "Экспресс-2" внес Леонид Нейштадт, начинавший входить в эту работу еще во время подготовки дипломного проекта в нашей лаборатории. Приятно, что огромный вклад Леонида помнят до сих пор несмотря на то, что он больше пяти лет развивает информационные системы других стран. Долгое время вместе с ним работал М.П.Березка (один из авторов публикуемой статьи), который поддержал и развил дальше эту сторону деятельности.
  6. Во время проектирования "Экспресс-2" было принято несколько решений, определивших ее успехи пятнадцать и десять лет назад, и в то же время, проблемы последних лет. Я выделю только две из них (высказывая, естественно, свою точку зрения). Выбор ОС TKS и ее специализация за счет своих доработок породил проблемы сопровождения и развития системы. Организация баз данных (оперативных и для аналитических расчетов) на основе программ методов доступа (стандартных и нестандартных) привела к проблемам в развитии программного и информационного обеспечения. Проблемы усугублялись тем, что большая часть разработчиков "Экспресс-2" по разным причинам покинула коллектив.
  7. Через несколько лет после начала функционирования "Экспресс-2" обслуживала более тысячи касс в Москве, начали работать "филиалы" системы в Ленинграде, Киеве, других городах. Если свердловский "Экспресс" использует ЕС-1046, то московский масштабировался до ЭВМ COMPAREX. Телеобработка "Экспресса" стала объединять разные регионы и железные дороги. В 1992 году подсистема оформления поездок в международном сообщении получила оперативный выход в другие системы резервирования Западной Европы. Использование стандартных проездных документов позволило реализовать двусторонние функциональные связи различных систем включая транзитные. Система стала в значительной степени неоднородной и волей-неволей стала приобретать черты открытой - в функциональном отношении - системы. Набор функций системы существенно расширился. Теперь в него входят не только возможности заказа билета с пересадками и резервирование обратных билетов по Европе и части Азии (не считая России), но и расчет экономической эффективности вагонов раных типов в конкретных поездах, обработка первичной маркетинговой информации, получаемой из любого региона, экономическое планирование составов поездов, управление пассажирским вагонным парком и др. Началось подключение к системе других видов транспорта - междугородных автобусов, речного и даже воздушного (выход в систему "Сирена" в г. Самара).
  8. Жизнь заставляет систему развиваться как в сторону предоставления все большего числа услуг при резервировании билетов, так и в направлении развития функций маркетингового управления услугами пассажирских перевозок. Во многом по этой причине после нескольких лет обсуждений планируется революционный шаг: переход к использованию промышленных СУБД. Переход этот осторожен: сначала для организации "аналитических" (исторических) данных, затем в "Экспресс-3" для операционных данных.

Проблемы при решении проблемы выбора СУБД

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

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

Авторы статьи достаточно подробно описали те требования, которые были сформулированы как исходные для тестирования. В их число вошли:

Указано также, что оптимизация физического размещения БД не предусматривалась.

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

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

  1. В случае, если это влияние допускается в полной мере, определяющими становятся следующие правила:
  2. Если ставится задача получить действительно сравнимые характеристики самих СУБД, то регламент тестирования дополнительно должен включать строгие ограничения или четко определенные и ограниченные допуски на принятие проектных решений в тестовых комплексах, например, в части:

Приведенный перечень - не исчерпывающий.

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

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

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

Во-вторых, может использоваться несколько совокупностей ограничений, например, применение языка "С" для одного теста и произвольных (или определенных) 4GL - для другого.

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

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

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

Пожелания

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

Евгений Захарович Зиндер
Редакционный совет СУБД

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

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

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