СУБД: проблема выбора

Сегодня в России признана весьма актуальной проблема снижения технологической зависимости в сфере ИТ, особенно при построении информационных систем, используемых в оборонно-промышленном комплексе, федеральных органах исполнительной власти и на предприятиях, вносящих непосредственный вклад в национальную безопасность [1]. Ключевым компонентом таких систем являются системы управления базами данных, от технических характеристик которых напрямую зависят защищенность и функциональные возможности информационных систем [2].

От современных СУБД, используемых в перечисленных областях, требуются:

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

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

На отечественном рынке ИТ доступны, в частности, следующие СУБД, которые потенциально можно использовать в качестве платформы для создания информационных систем специального назначения:

• PostgreSQL 9.3 из состава операционной системы Astra Linux Special Edition 1.4 разработки НПО «РусБИТех»;
• «Заря» [3] от ЦНИИ ЭИСУ, созданная на базе открытой СУБД PostgreSQL 9.0;
• «Линтер Бастион» компании «РЕЛЭКС»;
• «Ред База Данных» компании «Ред Софт», созданная на базе открытой СУБД Firebird;
• HyTech компании «Открытые информационные технологии».

Все эти СУБД продолжительное время применяются различными крупными отечественными пользователями: например, СУБД «Заря» и PostgreSQL из состава Astra Linux используются в Минобороны РФ, а «Линтер Бастион», «Ред База Данных» и HyTech — федеральными и региональными службами и ведомствами (см. табл. 1). Области применения СУБД в первую очередь определяются наличием в них средств защиты информации (СЗИ), сертифицированных по соответствующим требованиям. 

Таблица 1. Сертификаты отечественных СУБД

Следующим критерием выбора СУБД является поддержка определенных аппаратных платформ — в современных условиях замена существующего оборудования в организациях федеральных структур, как правило, не предполагается. Все рассмотренные СУБД функционируют на платформе x86_64, а СУБД PostgreSQL, «Заря» и «Линтер Бастион» также поддерживают серверные платформы IBM Power и System Z. В перспективе, вероятно, важную роль будет играть платформа ARM, которая сейчас поддерживается СУБД PostgreSQL и «Линтер Бастион».

Вполне естественно, что современные информационные системы, особенно специального назначения, оперируют значительными объемами данных, поэтому и к соответствующим СУБД предъявляются достаточно высокие требования. Все перечисленные СУБД позволяют создавать базы практически неограниченного размера, однако имеются ограничения на максимальный размер поля записи, как, например, в «Линтер Бастион», «Ред База Данных» и HyTech, — в одном поле таблицы этих баз может храниться лишь несколько килобайтов, в то время как СУБД, построенные на базе PostgreSQL, позволяют хранить до гигабайта. Кроме того, в HyTech имеется ограничение на длину наименования (максимум 8 символов), что снижает удобство проектирования и разработки программ.

В части базового функционала все названные СУБД достаточно развиты, однако в PostgreSQL и производных от нее лучше поддерживаются стандарты SQL, что позволяет более лаконично записывать и эффективнее обрабатывать сложные запросы. В «Линтер Бастион», «Ред База Данных» и HyTech стандарт SQL:2003 реализован частично, в СУБД «Заря» поддерживается SQL:2008, а в PostgeSQL реализована базовая часть современного стандарта SQL:2011.

При выборе СУБД важно учитывать наличие поддержки транзакций и возможностей управления ими — это определяет надежность хранения и скорость обработки. Все перечисленные СУБД обеспечивают полноценную транзакционную модель, удовлетворяющую требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, согласованность, изоляция, долговечность хранения»). Однако HyTech не позволяет управлять режимами изоляции транзакций, что снижает возможности системы при оптимизации производительности. Также необходимо отметить, что в СУБД «Линтер Бастион» и HyTech отсутствуют механизмы двухфазной фиксации транзакций, это затрудняет построение гетерогенных систем или реализацию транзакционного взаимодействия с внешними системами.

Важнейшая характеристика любой СУБД — это скорость поиска данных, которая напрямую зависит от имеющихся механизмов индексирования (см. табл. 2). Видно, что механизмы индексации данных в СУБД «Линтер Бастион», «Ред База Данных» и HyTech существенно уступают системам, производным от PostgreSQL.

Таблица 2. Механизмы индексирования

Собственные механизмы полнотекстового поиска реализованы во всех перечисленных СУБД, кроме HyTech, для которой предлагается использовать внешние средства поиска, такие как Sphinx (sphinxsearch.com). Однако у такого подхода есть ряд существенных недостатков, связанных с регулярной рассинхронизацией содержимого базы данных и полнотекстового индекса, а также со сложностью организации совместного поиска по полнотекстовым условиям и атрибутам из базы. Кроме этого, надо отметить, что «Ред База Данных» и HyTech не поддерживают пространственный тип данных (геопозиционирование) и потому не имеют соответствующих индексов, а в СУБД «Линтер Бастион» реализован стандарт OpenGIS и есть индекс, оперирующий охватывающими прямоугольниками, но он выполнен с помощью B-дерева, что не позволяет обеспечить высокую производительность.

Так как информационные системы в большинстве случаев должны предусматривать сбор и обработку больших объемов данных в нескольких ЦОД, территориально удаленных друг от друга, особое внимание необходимо уделять построению пространственно распределенных, отказоустойчивых и высокопроизводительных кластеров. К сожалению, все рассмотренные СУБД предоставляют здесь весьма слабые возможности — штатные механизмы асинхронной и синхронной репликации, балансировки нагрузки и организации пулов соединений, необходимые для построения локальных отказоустойчивых высокопроизводительных кластеров, присутствуют лишь в СУБД «Заря». СУБД PostgreSQL, входящая в состав Astra Linux Special Edition, и «Ред База Данных» поддерживают синхронную и асинхронную репликацию, что позволяет организовать горячее резервирование, то есть восстановление работоспособности системы после отказа основного сервера СУБД путем перенаправления клиентских запросов на резервный, который постоянно синхронизировался с основным.

В СУБД «Линтер Бастион» реализована только асинхронная репликация, а в документации к HyTech сказано, что поддержка репликации отсутствует.

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

Таблица 3. Средства кластеризации

Оценка СУБД без анализа имеющейся документации была бы неполной, и тут оказывается, что подробная документация на русском языке имеется только у СУБД «Заря», «Линтер Бастион», «Ред База Данных» и HyTech, а пользователям PostgreSQL придется полагаться только на оригинальную документацию на английском языке. Однако качество документации, поставляемой с отечественными СУБД, оставляет желать лучшего, поэтому особое значение приобретает наличие программ обучения. Но и здесь, к сожалению, ситуация далека от идеальной: имеются лишь декларации о поддержке ряда учебных заведений, которые еще только планируют использовать соответствующие СУБД в своих учебных процессах. На данный момент у разработчиков СУБД нет утвержденных программ и планов обучения администраторов или пользователей рассмотренных СУБД. В таких условиях преимущества имеют пользователи систем, построенных на базе PostgreSQL, — в России проводится ряд оригинальных курсов, программ повышения квалификации и сертификации пользователей именно этой СУБД. Стоит отметить, что в стране сформировалось сообщество пользователей СУБД PostgreSQL, регулярно проводятся встречи, конференции и публикуются статьи. Кроме этого, в России имеется несколько коммерческих организаций, способных оказать поддержку пользователям, выполнить проектирование, развертывание и доработку систем на базе открытой СУБД PostgreSQL.

Сравнение СУБД было бы неполным без анализа совокупной стоимости владения, которая определяется ценой лицензии и поддержки, а также величиной годовой зарплаты администратора СУБД (см. табл. 4).

Таблица 4. Примерная оценочная стоимость владения СУБД (тыс. руб.)

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

Бинарное хранилище слабоструктурированных данных в формате JSON — jsonb в СУБД PostgreSQL превосходит по скорости вставки и поиска данных даже специализированную NoSQL-СУБД MongoDB, причем для jsonb реализуется полноценная модель ACID.

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

***

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

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

Литература

1. Насенков И.Г., Жуков И.Ю., Хакимов Р.Р. Комплексная безопасность радиолокационных информационных систем // Радиоэлектронные технологии. — 2015. — № 1. — С. 12–17.
2. Пирогов В. Ю. Информационные системы и базы данных: организация и проектирование. БХВ-Петербург, 2009.
3. Жуков И.Ю., Ефанов Д.В., Муравьев С.К. Защищенная платформа «Заря» для центров обработки данных // Методы и технические средства обеспечения безопасности информации: материалы 22-й научно-технической конференции (Санкт-Петербург, 08–11 июля, 2013 г.).

Сергей Муравьев (s.muraviev@kret.com) — начальник отдела защищенных радиоэлектронных ИТ, Сергей Дворянкин (s.dvoryankin@kret.com) — начальник департамента, Игорь Насенков (nasenkov@kret.com) — заместитель генерального директора, концерн «Радиоэлектронные технологии» (Москва).