E-mail:
Пароль:
Забыли пароль?

Выбор СУБД для АС СН

Выбор СУБД для АС СН

Конференция «Информационные технологии в автоматизированных системах управления специального назначения»

В.Л. Борисов

Введение

Системообразующим фактором при разработке автоматизированной системы специального назначения (АС СН) является цель.

Если ставить целью снижение затрат, то, несомненно, наиболее выгодным будет использование бесплатного программного обеспечения (ПО).

Если же целью является максимально возможная эффективность на текущем уровне развития техники, то необходимо тщательно подбирать каждый компонент АС СН.

Рассмотрим эти утверждения на примере СУБД.

Разработка АС СН, использующей, например, в качестве СУБД PostgreSQL , позволяет не только сэкономить на покупке СУБД, но и удешевляет разработку. Россия обладает огромным количеством специалистов, имеющих опыт работы с PostgreSQL , издано множество книг по работе с этой СУБД, все больше появляется учебных курсов, в том числе, в сети Интернет.

Но если задуматься, как сделать АС СН не только не уступающую аналогам, но и превосходящую их, то обязательно возникнет вопрос: «Какую СУБД выбрать?»

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

Многие аналитики отмечают, что при прочих равных условиях (в первую очередь – требованиях, предъявляемых к СУБД) кардинального увеличения скорости в настоящее время получить невозможно. Производители СУБД сейчас предоставляют все необходимые способы индексации, используют «умные» оптимизаторы запросов и т.д. Получить серьезный выигрыш в скорости можно только за счет проигрыша в чем-либо другом, например, за счет работы только в режиме чтения данных.

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

Создается впечатление, что все СУБД одинаковы, только одни производители дают больше удобств разработчикам, другие заботятся о многоплатформенности, третьи делают акцент на торговой марке и т.д. Более того, если какая-то СУБД и заявляет о своих уникальных возможностях, которые становятся востребованными, эту нишу тут же занимают гиганты: Oracle , DB 2, MS SQL Server [1].

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

Сравнение PostgreSQL и ЛИНТЕР

Для примера сравним архитектуру ЛИНТЕР и PostgreSQL.

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

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

  • чрезмерно высокая требовательность к ресурсам;
  • неэффективное использование ресурсов при большом количестве клиентских подключений;
  • медленное создание новых подключений к серверу;
  • невозможность внутризапросного распараллеливания и т.д.

Практически все производители СУБД отказались от такой модели в силу перечисленных выше недостатков.

ЛИНТЕР изначально имел более прогрессивную, в свое время революционную (для СУБД), архитектуру. Сервер ЛИНТЕР реализует механизм вытесняющей многозадачности. Каждому запросу выделяется определенное количество времени (квант) на его обработку – после чего ядро СУБД переключается на выполнение следующего кванта очередного запроса.

На квантование задач в ЛИНТЕР влияют приоритеты запросов. Также используются и возможности распараллеливания, предоставляемые ОС. Исполняющая подсистема, трансляторы SQL и хранимых процедур, процессоры сортировки (их может быть несколько) – процессы/потоки ОС.

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

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

Из приведенного примера видно, что АС СН, работающая с PostgreSQL не может рассчитывать на мгновенное установление соединения, как это происходит при работе с ЛИНТЕР. Такого типа различия диктуют свои изменения в архитектуре АС СН, которые в ряде случаев могут сильно снижать эффективность АС СН в целом.

Сравнение других СУБД

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

Рассмотрим такой параметр, как универсальность. С одной стороны этой линейки должны находиться такие СУБД, как Oracle , Microsoft SQL Server , DB 2, а с другой – полное отсутствие обобщенной системы управления данными, лишь узкоспециализированный код, обеспечивающий выполнение только необходимых для АС СН функций.

Конечно, разрабатывать свою подсистему хранения данных для каждой АС СН – нецелесообразно. Теоретически это позволяет достичь максимальной эффективности АС СН, но практически это означает колоссальные затраты как на разработку, так и на отладку узко специализированной подсистемы хранения.

Другая крайность – использование универсальной СУБД во всех подряд АС СН также не позволительна.

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

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

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

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

Если перечислить все типы индексов, которые требует для себя аналитическая система, то получится весьма длинный список ( Hash , B - Tree , Bitmap , R - Tree , ..., JOIN , иерархические индексы и т.д.). Если же требуется максимальная скорость модификаций, то из приведенного списка остается практически только один hash -индекс, как наименее ресурсоемкий.

Универсальные СУБД отделены от указанных крайних ситуаций, они относительно бедны индексами – обычно около трех.

Также универсальные СУБД не уделяют большого внимания сжатию данных.

Пример использования различных СУБД в одной АС СН

Допустим, каждая единица военной транспортной техники оборудована системой отслеживания своего перемещения. Эта система каждую секунду сохраняет свои текущие координаты, полученные от спутниковой навигационной системы. Пусть, от АС СН требуется предоставление различных статистик (например, расстояние, пройденное за каждую минуту, каждый час и т.д.), а также возможность OLAP -анализа этих сведений, усредненных по группе транспортных единиц.

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

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

Одна из наиболее приспособленных для этих задач – защищенная СУБД ЛИНТЕР. Она начинала разрабатываться тогда, когда программисты бережно относились к вычислительным ресурсам. В итоге она занимает только отведенную ей память, имеет небольшой размер ядра и обладает всей функциональностью универсальной СУБД, включая специфические для реального времени особенности, перечисленные ниже.

  • Асинхронные запросы

Благодаря возможности подать SQL запрос и «забыть» про него, разрабатываемая система может заниматься полезными действиями в реальном времени и не дожидаться ответа. Достаточно указать функцию-обработчик, которая выполнит нужные действия, когда от СУБД придет ответ.

  • Приоритеты выполнения запросов

При получении запроса с более высоким приоритетом ЛИНТЕР выполнит его раньше других. Разработчик может оптимизировать скорость работы прикладной системы, устанавливая один из 255 доступных приоритетов.

  • События

С помощью событийного механизма можно создавать следящие подсистемы. Как только произойдет ожидаемое событие (insert, update, delete или даже select), будет выполнена указанная процедура.

  • Таблицы в памяти (in-memory tables)

ЛИНТЕР позволяет располагать данные целой таблицы в оперативной памяти. При запуске ядра такая таблица «поднимается» в невытесняемую на диск память и остается там до сохранения на диск. «Сбросить» все данные на диск можно не только при остановке ядра, но и в любой момент из программы. Скорость работы с таблицей в памяти в разы превышает скорость работы с обычными таблицами.

Для OLAP -анализа лучше использовать специальную СУБД, оптимизированную для выполнения аналитических запросов. Разработчики ЛИНТЕР выполнили такую экспериментальную разработку, имеющую рабочее название Сегмент.

База данных Сегмент состоит из отдельных кусочков, называемых инкрементами. Каждый из них имеет ту же самую структуру, что и основная база. Это сжатые по отдельности порции новой информации из материнской базы, например ЛИНТЕР.

Сегмент использует большое количество видов сжатия и типов индексов. Сжатие снижает количество операций обращения к жесткому диску, а значит – повышает скорость работы. Например, 100-гигабайтный диск обычного ноутбука позволит иметь «на борту» до терабайта данных. Специальные методы хранения данных и индексов обеспечивают еще и быстрый поиск, недоступный универсальным СУБД.

При разработке Сегмент ставилась задача обогнать все известные СУБД при выполнении типичных OLAP -запросов и эта задача была успешно выполнена.

Заключение

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

Одним из путей совершенствования АС СН является отказ от применения одной универсальной СУБД во всех подсистемах АС СН.

Применение различных специализированных СУБД (например, ЛИНТЕР и Сегмент) позволяет не только увеличить скорость работы АС СН, но и понизить требования к вычислительной технике.

Литература

1. Вон Ким «Технологии нишевых баз данных: ретроспективный взгляд» // Открытые системы, №4, 2004 г.


Возврат к списку

ѕрокрутить вверх