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

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

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

СУБД для АСУТП
Очень многие автоматизированные системы управления технологическими процессами переходят сейчас на работу с СУБД. Если раньше данные с различных датчиков писались в плоский файл, то сейчас производительность компьютеров позволяет для сохранения указанных значений в реальном времени использовать СУБД. Преимуществом такого подхода является возможность более быстрого поиска, агрегации и различного анализа информации. Например, для подсчета среднего значения за определенный промежуток времени не нужно обрывать запись в один файл и пересылать его на обработку, а достаточно просто подать SQL-запрос, который будет выполнен параллельно с пополнением БД. Это не только удобно для программиста, но и более оперативно, а главное — надежно.
Но при выборе СУБД для АСУТП необходимо помнить, что системы этого класса предъявляют дополнительные требования к универсальной СУБД.
Во-первых, необходимо учитывать работу в операционной системе реального времени. Сейчас в АСУТП все чаще встречается QNX 6.0.
Во-вторых, СУБД не должна захватывать все доступные вычислительные ресурсы, ей разрешено занимать только отведенную память, иметь минимальный размер ядра, выполнять все функции универсальной СУБД и при этом обладать следующими дополнительными особенностями.
Асинхронные запросы. Благодаря возможности подать SQL-запрос и «забыть» про него приложение может заниматься другими полезными действиями в реальном времени и не дожидаться ответа. Достаточно указать функцию-обработчик, которая выполнит нужные действия, когда от СУБД придет ответ на этот...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.