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

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

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

СУБД для АСУТП
Очень многие автоматизированные системы управления технологическими процессами переходят сейчас на работу с СУБД. Если раньше данные с различных датчиков писались в плоский файл, то сейчас производительность компьютеров позволяет для сохранения указанных значений в реальном времени использовать СУБД. Преимуществом такого подхода является возможность более быстрого поиска, агрегации и различного анализа информации. Например, для подсчета среднего значения за определенный промежуток времени не нужно обрывать запись в один файл и пересылать его на обработку, а достаточно просто подать SQL-запрос, который будет выполнен параллельно с пополнением БД. Это не только удобно для программиста, но и более оперативно, а главное — надежно.
Но при выборе СУБД для АСУТП необходимо помнить, что системы этого класса предъявляют дополнительные требования к универсальной СУБД.
Во-первых, необходимо учитывать работу в операционной системе реального времени. Сейчас в АСУТП все чаще встречается QNX 6.0.
Во-вторых, СУБД не должна захватывать все доступные вычислительные ресурсы, ей разрешено занимать только отведенную память, иметь минимальный размер ядра, выполнять все функции универсальной СУБД и при этом обладать следующими дополнительными особенностями.
Асинхронные запросы. Благодаря возможности подать SQL-запрос и «забыть» про него приложение может заниматься другими полезными действиями в реальном времени и не дожидаться ответа. Достаточно указать функцию-обработчик, которая выполнит нужные действия, когда от СУБД придет ответ на этот запрос.
Приоритеты выполнения запросов. Иногда необходимо, чтобы приложение выполнило какой-то запрос вне общей очереди. Одним из самых удобных способов создания категории «льготных запросов» является назначение каждому запросу определенного приоритета. При получении запроса с более высоким приоритетом СУБД выполнит его раньше других, имеющих более низкий приоритет. Например, в СУБД ЛИНТЕР можно оптимизировать скорость работы прикладной системы, устанавливая один из 256 доступных приоритетов.
События. С помощью событийного механизма можно создавать следящие утилиты. Как только в системе произойдет некоторое ожидаемое событие (insert, update, delete или даже select), будет выполнена заранее указанная процедура. Все остальное время приложение выполняет основные действия.
Таблицы в памяти. Некоторые приложения требуют очень высокой скорости обработки данных, которую не обеспечивают универсальные СУБД. Решить эту задачу в рамках классической реляционной СУБД позволяет механизм in-memory table. Подобный механизм используется, например, в российском сервере баз данных ЛИНТЕР. Он позволяет располагать данные целой таблицы в оперативной памяти. При запуске ядра такая таблица загружается в не вытесняемую на диск память и остается там до сохранения на диске. «Сбросить» все данные на диск можно не только при остановке ядра, но и из программы в любой момент. Скорость работы с таблицей в памяти в разы превышает скорость работы с обычными таблицами в универсальных СУБД.
Отключение журнала. Отключение системного журнала и отказ от поддержки транзакций увеличивает скорость работы примерно в 2 раза.
Облегченная версия. Отдельные СУБД могут быть собраны специальным образом — без включения ненужной (в каждом конкретном случае) функциональности, что не только увеличит скорость работы, но и уменьшит размер ядра.

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

СУБД военного назначения
Автоматизированные системы военного назначения (АС ВН) предполагают использование только российских и только сертифицированных серверов баз данных. На сегодняшний день этим требованиям отвечают две системы — СУБД ЛИНТЕР и Линтер-ВС (специальная версия, созданная в конце 90-х годов на базе коммерческой СУБД ЛИНТЕР).
АС ВН уже давно используют ЛИНТЕР и Линтер-ВС. Несколько лет назад под маркой Линтер-ВС появилась модифицированная версия СУБД PostgreSQL. С одной стороны, это хорошо — появился выбор, а значит, возможность повысить эффективность АС ВН. С другой стороны, PostgreSQL не является отечественной разработкой — это продукт творчества международного сообщества разработчиков, который развивается отдельно от средств защиты, обязательных для систем данного класса. Следовательно, в этом направлении неизбежно запаздывание — для каждой новой версии PostgreSQL необходимо встраивание мандатных механизмов доступа, трехкратной очистки памяти и т.п.
Все СУБД имеют разное внутреннее устройство и, следовательно, особенности в отдельных сегментах задач.
Для примера сравним архитектуру ЛИНТЕР и PostgreSQL.
PostgreSQL имеет простую архитектуру: каждому клиенту выделяется по «собственному» серверу. При такой архитектуре для каждого из клиентских подключений создается серверный процесс, обслуживающий одного клиента.
Плюсами такого подхода являются простота реализации, относительная легкость распараллеливания и масштабирования. Однако отсюда же следуют и минусы: чрезмерно высокая требовательность к ресурсам; неэффективное использование ресурсов при большом количестве клиентских подключений; медленное создание новых подключений к серверу; невозможность внутризапросного распараллеливания и т.д.
Практически все производители СУБД отказались от такой модели из-за перечисленных выше недостатков.
ЛИНТЕР изначально имела более прогрессивную, в свое время революционную (для СУБД), архитектуру. Сервер ЛИНТЕР реализует механизм вытесняющей многозадачности. Каждому запросу выделяется определенное количество времени (квант) на его обработку, после чего ядро СУБД переключается на выполнение следующего кванта очередного запроса.
Плюсы такого подхода — в низкой требовательности к ресурсам и высокой эффективности их использования, мгновенном подключении к серверу, возможности легкой поддержки большого числа различных ОС и т.д.
Можно продолжать сравнение, рассматривать плюсы и минусы, например, способов обработки транзакций, индексирования, оптимизации запросов, поддержки SQL и т.д., но очевидно, что различия глубоки.
Из приведенного примера видно, что АС ВН, работающая с PostgreSQL, не может рассчитывать на мгновенное установление соединения, как это происходит при работе с ЛИНТЕР. Такого типа различия диктуют свои изменения в архитектуре автоматизированной системы, которые в ряде случаев могут сильно снижать эффективность АС ВН в целом.
В будущем на рынок АС ВН возможен выход и других игроков — время от времени появляются сообщения о планах различных производителей по сертификации СУБД. Если эти планы будут воплощены в жизнь, конкуренция на рынке усилится и конечный потребитель от этого только выиграет. При этом, несмотря на обилие универсальных СУБД, все равно останется потребность в специализированных системах. И та компания, которая сможет предложить возможность модификации своего продукта под нужды конкретных задач, в итоге получит преимущество.
Универсальные СУБД рассчитаны на наиболее часто необходимую в бизнесе интенсивность модификаций и на наиболее часто встречающуюся сложность запросов. Далеко не всегда такие же требования к СУБД предъявляют АС ВН. Возможно, автоматизированная система снабжения подразделения вооруженных сил в целом похожа по требованиям на автоматизированную систему снабжения сети гипермаркетов. Но даже в супермаркетах (не гипермаркетах) информация о покупках с каждой кассы поступает в общую базу магазина только раз в сутки. В условиях современного боя информация (например, о потерях, дислокации подразделений или резервов) должна поступать мгновенно. А это подразумевает пересмотр всей архитектуры автоматизированной системы и предъявляет соответствующие требования к используемому серверу баз данных.
В отдельных АС ВН или их частях данные должны автоматически сниматься с датчиков и заноситься в БД в реальном времени. В других случаях необходима быстрая аналитическая обработка, достигающаяся применением различных типов индексов и сжатием данных. Универсальные СУБД на это не рассчитаны.
Например, если перечислить все типы индексов, которых требует для себя аналитическая система, то получится весьма длинный список (Hash, B-Tree, Bitmap, R-Tree, ..., JOIN, Иерархические и т.д.). Если же требуется максимальная скорость модификаций, то из приведенного списка остается практически только один hash-индекс как наименее ресурсоемкий. Универсальные СУБД отделены от указанных крайних ситуаций, они относительно бедны индексами, которых обычно не более трех. Также в них не уделяется большого внимания сжатию данных.
Таким образом, один из путей совершенствования АС ВН состоит в отказе от применения одной универсальной СУБД во всех подсистемах АС ВН. Применение же различных специализированных СУБД позволяет не только увеличить скорость работы АС ВН, но и понизить требования к вычислительной технике.

СУБД для государственных информационных систем
Согласно статье 5 Федерального закона от 27.07.2006 №149-ФЗ «Об информации, информационных технологиях и о защите информации», такая СУБД в зависимости от категории доступа к ней подразделяется на общедоступную информацию, а также на информацию, доступ к которой ограничен федеральными законами (информация ограниченного доступа).
Как общедоступная, так и информация ограниченного доступа должна быть защищена. Согласно статье 16 под защитой понимаются меры, направленные на «обеспечение защиты информации от неправомерного доступа, уничтожения, модифицирования, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий в отношении такой информации», на соблюдение конфиденциальности информации ограниченного доступа, на реализацию права доступа к информации.
Установление ограничений доступа к информации осуществляется только федеральными законами (статья 3), и соблюдение конфиденциальности информации, доступ к которой ограничен федеральными законами, обязательно (статья 9).
Защита информации, составляющей государственную тайну, осуществляется в соответствии с законодательством Российской Федерации о государственной тайне (статья 9, часть 3).
Отдельно нужно сказать о защите общедоступной информации. В данном законе вводится понятие «Государственные информационные системы» — это федеральные и региональные информационные системы, созданные на основании соответственно федеральных законов, законов субъектов Российской Федерации, на основании правовых актов государственных органов. Государственные информационные системы создаются с учетом требований, предусмотренных Федеральным законом от 21 июля 2005 г. № 94-ФЗ «О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд».
Требования о защите информации, содержащейся в государственных информационных системах, устанавливаются Федеральной службой по техническому и экспортному контролю (ФСТЭК). Удовлетворение этим требованиям подтверждается соответствующим сертификатом.
Таким образом, для государственных информационных систем законодательно закреплено использование специализированных СУБД, обладающих средствами защиты согласно руководящим документам Гостехкомиссии и сертифицированных ФСТЭК. Таких СУБД немного прежде всего из-за отсутствия у большинства из них механизмов мандатной защиты доступа, требующихся при высоком уровне защиты, а также из-за необходимости предоставить для исследования исходные тексты.
В настоящее время единственной СУБД, сертифицированной ФСТЭК на  практически наивысший уровень защиты данных, является ЛИНТЕР. Более того, эта СУБД сертифицирована серийно. Другие СУБД, в том числе широко известные, сертифицированы на более низкие классы защиты и чаще всего только в составе единичного программно-аппаратного комплекса.

Заключение
При решении нестандартной задачи, накладывающей на СУБД специфические требования, использование универсальных СУБД может стать причиной серьезных ограничений возможностей автоматизированной системы. Есть три наиболее очевидных решения этой проблемы: использовать универсальную СУБД, смирившись с неизбежными ограничениями; начать разработку собственной СУБД; доработать одну из существующих СУБД.
В данной статье предлагается для специализированной системы использовать специализированную СУБД и ни в коем случае не сдаваться, если требуемая СУБД не найдена, а попробовать договориться о разработке (доработке) СУБД с необходимыми характеристиками.
За основу нужно взять СУБД, проверенную временем (с большой историей и множеством внедрений), обладающую всеми возможностями универсальной реляционной СУБД (прежде всего SQL) и желательно отечественную (для государственных проектов это обязательное условие). Последнее требование в некоторых случаях продиктовано законодательством, а в других — здравым смыслом: лучше, когда доработку ведет сам разработчик СУБД. Это гарантирует оптимальное встраивание требуемых функций и особенностей, потому что разработчики досконально знают внутреннее устройство своей системы; лучшее тестирование, поскольку у разработчиков уже есть наработанные программы и методики тестирования; лучшую поддержку созданной системы, так как российский разработчик гораздо доступнее, ответственнее и с ним не возникнет языкового барьера.
В статье авторы постарались рассмотреть основные аспекты выбора системы управления базами данных для специализированных информационных систем. Мы надеемся, что эта информация поможет вам при выборе СУБД. В любом случае мы можем только предложить вашему вниманию свою точку зрения на эту проблему, выбор же остается за вами.
Если наша статья не ответила на какие-то вопросы, важные для вас, или поставила новые, пишите нам, мы обязательно ответим.

С авторами можно связаться по электронной почте: Виктор Борисов: vict@relex.ru, Виталий Максимов: vitamax@relex.ru.