RuDB и Digital Q.DataBase: российские СУБД для импортозамещения Oracle и Microsoft SQL Server

RuDB и Digital Q.DataBase: как в России развивают СУБД класса Enterprise

RuDB и Digital Q.DataBase: как в России развивают СУБД класса Enterprise

В «Диасофт» решили не ограничиваться формальным импортозамещением и создали СУБД RuDB и Digital Q.DataBase на базе PostgreSQL для более простой миграции с Oracle Database и Microsoft SQL Server.

 

 

 

 

 

 

 

  1. 1. Введение
  2. 2. Создание СУБД Digital Q.DataBase
  3. 3. Импортозамещение СУБД в России
  4. 4. Digital Q.DataBase и универсальный адаптер «Полиглот»
  5. 5. Зарубежные аналоги российских СУБД
  6. 6. Импортозамещение корпоративного ПО класса Enterprise
  7. 7. Импортозамещение Enterprise-платформ с точки зрения ИБ
  8. 8. Процесс импортозамещения изнутри
  9. 9. Безопасность переноса данных при переходе на PostgreSQL
  10. 10. Российская национальная бесплатная СУБД RuDB
  11. 11. Выводы

Введение

На прошедшей в Москве конференции «День СУБД 2026» компания «Диасофт» объявила о выпуске первой национальной бесплатной СУБД класса Enterprise. Она получила название RuDB. Новый продукт может рассматриваться как полноценная замена иностранным СУБД класса Enterprise — Oracle и Microsoft SQL Server.

RuDB можно рассматривать прежде всего для разработки «с нуля» и построения ИТ-инфраструктур с применением хранилища данных. Для заказчиков, которые уже используют западные СУБД и намерены перейти на российскую платформу, «Диасофт» предложил собственную коммерческую СУБД Digital Q.DataBase. Она позволяет перейти с иностранных СУБД без необходимости переделки уже выстроенных конфигураций остального прикладного ПО.

Системы RuDB и Digital Q.DataBase во многом родственны между собой. Их анонс можно рассматривать как важное явление на рынке, потому что теперь можно говорить не просто о кастомизации Open Source СУБД PostgreSQL, лежащей в основе не только этих, но и большинства других отечественных хранилищ данных. Достигнут уровень полноценной экспертизы в разработке СУБД класса Enterprise, позволяющий оценивать эти решения не как импортозамещение, а как достижение технологического суверенитета по данному направлению.

В этой статье мы коснёмся вопросов, как возникло это решение, насколько оно отвечает требованиям ИБ, а также того, как оно должно повлиять на весь процесс импортозамещения в стране.

 

Рисунок 1. Современная СУБД с точки зрения пользователя

Современная СУБД с точки зрения пользователя

 

Создание СУБД Digital Q.DataBase

Базовым продуктом в этом тандеме СУБД является Digital Q.DataBase — собственная разработка «Диасофт». Это middleware-надстройка над движком PostgreSQL, реализующая полный набор операций, встречающийся у западных СУБД Microsoft SQL Server и Oracle. Благодаря этому обеспечены распараллеливание и масштабирование низкоуровневых операций, завершающее исполнение которых возложено на механизм PostgreSQL.

Создание подобной надстройки требует глубокого понимания встроенных механизмов обработки данных как на стороне PostgreSQL, так и Microsoft SQL Server и Oracle. Не будет неожиданностью отметить, что эти механизмы имеют разную архитектуру хранения данных, что касается также и механизмов их безопасности.

Если коротко, то PostgreSQL придерживается более традиционных конструкций и имеет другой синтаксис языка SQL. Кастомизация под конкретные задачи на его основе нередко требует подключения сторонних надстроек, что отражается на командах, отправляемых на обработку в хранилище. В западных СУБД Microsoft SQL Server и Oracle многие из этих функций реализованы внутри СУБД. Поэтому миграция с них на PostgreSQL ведёт не только к замене синтаксиса SQL, но и требует внесения серьёзных изменений в логику работы приложений.

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

Этот штрих наглядно демонстрирует, что создание middleware-надстройки над PostgreSQL для адаптации под Microsoft SQL Server или Oracle — это трудоёмкий и нетривиальный процесс. Большинство разработчиков перекладывают при импортозамещении все неявные сопутствующие задачи на плечи заказчиков. Это позволяет получить результат, и с этого начинают все, в том числе и «Диасофт».

Ещё в 2014 году была начата разработка специального адаптера Diasoft DataBase Adapter для подключения к хранилищам PostgreSQL прикладных программ, разработанных для работы с Oracle. Готовый к работе инструмент появился в 2016 году. Он сыграл важную роль для российского рынка. Например, более 200 российских продуктов благодаря ему «сумели» зарегистрироваться к 2026 году в Реестре российского ПО.

Импортозамещение СУБД в России

Идея применения PostgreSQL как базового механизма для хранения данных уже стала универсальной для большинства российских разработчиков. Этот Open Source-продукт предоставляет «из коробки» очень важное свойство: реализацию для множества проверенных на практике UNIX-подобных платформ, включая различные BSD-системы, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX и даже Microsoft Windows.

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

 

Рисунок 2. Потенциал российских разработчиков СУБД расходуется неэффективно

Потенциал российских разработчиков СУБД расходуется неэффективно

 

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

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

С точки зрения ИБ эти разработки должны удовлетворять следующим требованиям:

  • Обработка персональных данных (ПДн) в соответствии с ФЗ-152.
  • Допустимость применения на значимых объектах критической информационной инфраструктуры (ЗО КИИ).
  • Совместимость с прикладными решениями заказчиков.
  • Наличие сертификата ФСТЭК по 4 уровню доверия.
  • Поддержка хранилищ вплоть до уровня Enterprise.

 

Рисунок 3. Александр Глазков, генеральный директор «Диасофт», выделил приоритеты в развитии СУБД

Александр Глазков, генеральный директор «Диасофт», выделил приоритеты в развитии СУБД

 

Digital Q.DataBase и универсальный адаптер «Полиглот»

Поэтому позднее в «Диасофт» осознали, что использование звена Diasoft DataBase Adapter не покрывает интересы многих заказчиков. Применение адаптера порождает существенную потерю производительности, SQL-запросы в Microsoft SQL Server или Oracle позволяют сразу решать множество сопутствующих задач, которые не покрываются подбором аналогичных команд в PostgreSQL.

Пришло понимание, что полноценный аналог может быть реализован только через middleware-надстройку для PostgreSQL. Её разработка требует высокой ИТ-экспертизы в понимании внутренней архитектуры Microsoft SQL Server или Oracle. Разработка Digital Q.DataBase велась с учётом этих требований. Забегая вперёд, скажем, что у этого направления сейчас формируется отдельная ветвь — бесплатная полностью российская СУБД RuDB.

Но большинство заказчиков нацелено получить не просто новую платформу, а ещё и возможность быстрого и полнофункционального переноса всей своей ИТ-инфраструктуры, связанной с использованием хранилища данных, на отечественную платформу. Это требует создания гибридных средств обработки SQL-команд, которые способны адаптировать синтаксис хранения и обработки данных Oracle (PL/SQL) и Microsoft SQL Server (T-SQL) к схеме PostgreSQL (PL/pgSQL).

В этом состоит назначение дополнительного встроенного механизма, который добавляет к Digital Q.DataBase функции парсера, планировщика, оптимизатора и исполнителя запросов. Он обеспечивает перестройку SQL-кода на этапе между получением запроса от прикладной внешней программы и его обработкой в механизме хранения. Этот инструмент получил название «Полиглот», который исполняет родной код Oracle / Microsoft SQL Server для обработки SQL как нативный, а не интерпретирует его, как сделано в других российских форках. Это — главное и принципиальное отличие подхода «Диасофт».

 

Рисунок 4. Конфигурации Digital Q.DataBase и Microsoft SQL Server для сравнительного нагрузочного тестирования

Конфигурации Digital Q.DataBase и Microsoft SQL Server для сравнительного нагрузочного тестирования

 

Зарубежные аналоги российских СУБД

Импортозамещение в России началось не в 2022 году, а значительно раньше. До того как тема стала политизированной, ее рассматривали прежде всего как способ достижения технологического суверенитета. Однако большинство российских компаний не видели серьёзных рисков с точки зрения безопасности и продолжали использовать существующие западные решения, поэтому переход на отечественные продукты откладывался.

Тема технологической независимости в ИТ — не исключительно российское явление. О ней начали задумываться во всем мире ещё в начале 2010-х гг., поэтому стали появляться аналогичные решения:

  • Proxima DB for Oracle — китайская разработка компании Alibaba на базе PostgreSQL;
  • TmaxData (ранее Tibero) — разработка из Южной Кореи, применяемая в том числе в России, например для поддержки карточных транзакций в банковской сфере;
  • средства эмуляции Microsoft SQL Server в облаке Amazon — реализованы в отдельном форке PostgreSQL и разработаны в Индии.

Разработка аналогичных решений в компании «Диасофт» началась в 2016 году. Digital Q.DataBase и «Полиглот» стали реализацией подхода к достижению технологического суверенитета в области разработки СУБД в России.

 

Рисунок 5. Результаты сравнительного нагрузочного тестирования Digital Q.DataBase и Microsoft SQL Server

Результаты сравнительного нагрузочного тестирования Digital Q.DataBase и Microsoft SQL Server

 

Импортозамещение корпоративного ПО класса Enterprise

Достижимо ли импортозамещение корпоративного ПО класса Enterprise?

Этот вопрос может вызвать недоумение: «А разве может быть иначе?». Указы №166 и №250, принятые в 2022 году, прямо указывают на достижимость этой цели.

Но на практике на пути её реализации возникает множество препятствий. Это проявляется, например, в том, что Минцифры готовит проект постановления правительства с уточнёнными сроками перевода ЗО КИИ на российские ИТ-решения. По оценкам, максимальная отсрочка может составить до 1 января 2036 года, то есть фактически 10 лет.

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

Поэтому даже крупнейшие российские компании продолжают откладывать переход на отечественные продукты, прежде всего из-за неопределённости объёма будущих доработок. Важную роль играет и ИБ: масштаб рисков нередко невозможно оценить в полной мере.

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

 

Рисунок 6. Импортозамещение требует не только контроль над набором функций оригинала

Импортозамещение требует не только контроль над набором функций оригинала

 

Импортозамещение Enterprise-платформ с точки зрения ИБ

«Давайте начнём с самого объекта защиты — корпоративных ИТ-платформ, или платформ цифровизации бизнеса, — говорит Михаил Кадер, архитектор клиентского опыта будущего UserGate. — Это множество информационных систем, включающих подсистемы хранения и обработки данных, управления пользователями, процессами, совместной работы и других компонентов, необходимых современному предприятию. При этом каждая из этих систем может быть распределённой и состоит из множества компонентов — от мультисервисной архитектуры до большого числа внешних API-интеграций».

«Хотелось бы вспомнить известный принцип Secure by Design. Но, к сожалению, пока это скорее слова, — продолжает Михаил Кадер. — ИТ-специалисты нередко продолжают воспринимать требования ИБ как барьер на пути внедрения новых сервисов или просто забывают об их существовании. В результате на практике используются три основных подхода к обеспечению безопасности таких систем».

 

Михаил Кадер, архитектор клиентского опыта будущего UserGate

Михаил Кадер, архитектор клиентского опыта будущего UserGate

 

Первый из них — ИТ-платформа должна предоставлять сообщения системного журнала (syslog) от всех своих сервисов. С учётом уровня развития российского рынка систем мониторинга ИБ-событий даже сбор и анализ логов позволяют выявлять большую часть ИБ-инцидентов.

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

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

Для этого применяются российские средства сетевой безопасности: межсетевые экраны, в том числе прикладного уровня, защищённые прокси-серверы и другие решения. При этом особое внимание необходимо уделять защите API-взаимодействия, а также контролю работы ИИ-агентов и пользователей с внешними ИИ-системами.

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

Процесс импортозамещения изнутри

Но не стоит сразу принимать на веру, что внедрение продукта «Диасофт» Digital Q.DataBase автоматически решает задачу импортозамещения. Остаётся немало других вопросов, на некоторых из которых мы остановимся ниже.

Первый вопрос — процесс миграции. Для многих компаний импортозамещение связано с заменой ИТ-инфраструктуры без остановки её эксплуатации. Поэтому появление «Мастера переноса БД» стало существенной поддержкой со стороны «Диасофт». Решение обеспечивает перенос данных и программных объектов в Digital Q.DataBase с многопоточной выгрузкой и загрузкой данных. Как отметил архитектор «Диасофт» Константин Варов, все инструменты прошли отладку, а вендор предоставляет техническую поддержку.

Вторая преграда — запрет vendor lock-in, который разработчики прикладных систем нередко закладывают в свои продукты. О подобных ограничениях часто вспоминают только на этапе миграции, когда они становятся серьёзным препятствием. По словам Константина Варова, каждое такое ограничение требует профессиональной оценки. В частности, «Диасофт» решил эту проблему для продуктов «1С», согласовав решение с правообладателем. Для других приложений требуется отдельная проверка.

Третья преграда — сохранение прежнего уровня производительности. Именно этот вопрос вызывает у заказчиков наибольшее число сомнений. Как отметил Константин Варов, разработчики «Диасофт» имеют 35-летний опыт работы с Oracle Database и использовали накопленную экспертизу при создании Digital Q.DataBase, включая декомпиляцию кода Oracle Database и анализ архитектуры решений. Полученные характеристики оказались близки к оригиналу, однако окончательные выводы можно будет сделать только после полноценных внедрений у заказчиков.

«Мы регистрируем 400–500 скачиваний системы в месяц. Количество самостоятельных тестовых инсталляций уже исчисляется сотнями. Это видно по числу обращений в службу технической поддержки за консультациями, — продолжил Константин Варов. — Но наиболее показательны совместные проекты, которые “Диасофт” реализует с крупными Enterprise-заказчиками в рамках пилотных внедрений. Сейчас число проектов по переходу с Microsoft SQL Server составляет 16, с Oracle Database — 4. Очевидно, что речь идёт о крупнейших заказчиках, для которых подобные внедрения являются крайне ответственными и значимыми».

 

Рисунок 7. Архитектор «Диасофт» Константин Варов ответил на вопросы партнеров

Архитектор «Диасофт» Константин Варов ответил на вопросы партнеров

 

Безопасность переноса данных при переходе на PostgreSQL

А теперь несколько слов о миграции моделей безопасности, например из Oracle Database в PostgreSQL. Это может оказаться одной из самых сложных частей преобразования базы данных при импортозамещении.

Начнём с Oracle Database. В этой СУБД детально проработаны механизмы безопасности на основе сложного многоуровневого набора инструментов. Классический подход основан на использовании Oracle Label Security (OLS) и Virtual Private Database (VPD), однако в современных реализациях также широко применяется механизм Real Application Security (RAS), интегрирующий безопасность на уровне сеанса приложения.

В экосистеме Oracle Database безопасность часто носит процедурный характер. Администраторы используют пакеты, например DBMS_RLS, для привязки политик безопасности к таблицам. Это проявляется при запросе данных пользователем: функции контроля выполняются в фоновом режиме и динамически переписывают SQL-запрос с добавлением оператора WHERE. Механизм хорошо развит, однако сам процесс может оказаться непрозрачным, что проявляется при импортозамещении.

Отметим также, что Oracle Label Security обеспечивает защиту на уровне строк с использованием установленных меток конфиденциальности. Для защиты на уровне столбцов в Oracle Database обычно применяются Data Redaction — для маскировки данных «на лету» при их выдаче — и Database Vault, обеспечивающий защиту областей, в которых требуется ограничение доступа к конфиденциальным полям, в том числе для привилегированных администраторов баз данных.

В PostgreSQL система безопасности значительно проще. В ней используется стандартный декларативный подход, распространяющийся на уровень строк и столбцов (RLS). В отличие от Oracle Database, где используются отдельные пакеты, механизмы безопасности PostgreSQL реализуются через встроенные конструкции в SQL-командах, которые непосредственно обрабатываются при обращении к таблицам.

 

Рисунок 8. Схема защиты данных при SQL-транзакциях в PostgreSQL

Схема защиты данных при SQL-транзакциях в PostgreSQL

 

Хотя компания «Диасофт» проводила конференцию «День СУБД 2026» для партнёров, там присутствовали прежде всего представители финансовых и кредитных организаций — основных заказчиков компании. Поэтому вопросы, связанные с ИБ, остались вне поля зрения в ответах архитектора «Диасофт» Константина Варова. Поэтому обсуждение всего комплекса «многоуровневой защиты» Digital Q.DataBase ещё требует разъяснений.

Российская национальная бесплатная СУБД RuDB

Важным событием конференции «День СУБД 2026» стал анонс первой национальной бесплатной СУБД уровня Enterprise — RuDB v.1.

В её основе лежит усечённая версия коммерческой СУБД Digital Q.DataBase, которая позволяет начать строить ИТ-инфраструктуру компаний. В основе эталонной сборки RuDB использована PostgreSQL 18.2 с набором средств поддержки ИБ. RuDB отвечает требованиям ФСТЭК, совместима с основными российскими бизнес-приложениями, содержит большинство функций DBMS- и UTL-пакетов.

Для поддержки RuDB было объявлено о создании некоммерческого объединения «Ассоциация разработчиков СУБД». Учредителями выступили компании «Диасофт» и АО «НППКТ». АО «НППКТ» является разработчиком СУБД «Лира-Р» и российской ОС общего назначения «Основа» для рабочих станций и серверов. Ассоциация открыта для приёма новых членов, взаимодействия с заказчиками, государством, администрирования прав на ИС и др.

 

Рисунок 9. Анонс RuDB v.1.0 на конференции «День СУБД 2026» в Москве

Анонс RuDB v.1.0 на конференции «День СУБД 2026» в Москве

 

Выводы

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

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

Полезные ссылки: