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

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

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

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

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

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

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. В случае, если это влияние допускается в полной мере, определяющими становятся следующие правила:
   • заданием для тестировщиков являются такие описания БД и транзакций, которые гарантируют их семантическую эквивалентность;
   • допустимы только те дополнительные ограничения (например, решение "использовать только нормализованные структуры данных и язык "С" с вызовами SQL, ограниченного конкретным по мощности вариантом ODBC"), которые вполне оправданы в проекте, строго определены и применимы всеми командами тестировщиков;
   • необходимо подобрать команды тестировщиков, обладающие высшим мастерством во владении средствами каждой СУБД.
2. Если ставится задача получить действительно сравнимые характеристики самих СУБД, то регламент тестирования дополнительно должен включать строгие ограничения или четко определенные и ограниченные допуски на принятие проектных решений в тестовых комплексах, например, в части:
   • определения ограничений на выбор варианта логической схемы БД (способ выбора первичных ключей, тип данных других элементов, применимость повторяющихся групп и множественных полей, и др.);
   • определения параметров физической схемы БД (способ задания начального размещения, использование свободного пространства в динамике, и др.);
   • определения идентичного состава тестовых данных для формирования начального состояния БД (вплоть до создания для всех команд тестировщиков идентичных копий тестовых данных);
   • формирования входных последовательностей (заявок на обслуживание) включая характеристики распределения данных в них;
   • фиксации идентичности или ограничений на различия в использовании аппаратных средств (не только процессор или тип дисков и объем внешней памяти, но и использование областей основной памяти для буферизации/кэширования физических обращений к БД);
   • определения требований к языкам обработки данных или к их типам;
   • определения требований к планированию тестовых экспериментов, гарантирующих как равные оценки достоверности результатов разных замеров, так и гарантию их неискажения смежными процессами (процессы ОС, процессы самих тестовых программ).

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

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

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

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

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

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

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

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

Пожелания

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