Digital Q.DataBase: революционный подход к импортозамещению СУБД

Отечественные СУБД: возвращение к истокам

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

На профильных факультетах российских вузов, таких как ВМК МГУ, до сих пор большое внимание уделяют подготовке специалистов, умеющих разрабатывать СУБД. Помимо этого такие эксперты, как Олег Бартунов, Фёдор Сигаев, Александр Коротков внесли огромный вклад в создание и развитие ядра самого популярного open source решения – PostgreSQL.

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

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

Директор департамента «Экономика данных» компании «Диасофт» Николай Макаревич
Источник фото: «Диасофт»

«Интересно, что «ванильный» PostgreSQL, по сути, начал бурно развиваться, сильно прирастать функциональностью именно в связи с российским импортозамещением – когда в 2014-16 годах страну охватили первые волны санкций и возникли инициативы, связанные с реестром российского программного обеспечения. До этого он существовал фактически как полустуденческая разработка – неплохо продуманная, с отлаженными алгоритмами в базовых механизмах, но без какого-то коммерческого подхода, не учитывающая многие вопросы удобства пользователя», – замечает директор департамента «Экономика данных» компании «Диасофт» Николай Макаревич.

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

На подступах к оптимальной и бесшовной миграции

Основная проблема всех разработчиков СУБД состоит в том, что архитектура PostgreSQL кардинально отличается от Oracle Database и MS SQL Server.

Создавая СУБД на основе PostgreSQL разработчик, как правило, ограничивается типовым набором действий: переносит к себе «ванильную» версию системы, добавляет в нее российское шифрование, 64-битный счетчик транзакций, популярные open-source расширения (вроде orafce, citus, oracle_fdw, tds_fdw и др.), а также некоторые утилиты (вроде Ora2Pg) для облегчения миграции данных заказчика с Oracle Database и MS SQL Server. Этого достаточно, чтобы СУБД оказалась включенной в реестр российского программного обеспечения и даже получила сертификат ФСТЭК. А значит, как минимум те компании, на которые распространяются регуляторные требования по переходу на отечественное ПО, обязаны выбрать одно из представленных в реестре решений.

Однако такой вариант таит в себе множество подводных камней, с которыми предстоит столкнуться заказчику. Да, он приобрел отечественную СУБД, но теперь ему еще нужно перенести на нее все свои корпоративные системы. За этот процесс разработчики СУБД, как правило, уже не отвечают, поэтому заказчику приходится выполнять его собственными силами или с привлечением интегратора. При этом доступные утилиты для автоматизированной миграции решают эту задачу только частично. Например, упомянутый выше скрипт Ora2Pg, который разработан сообществом Postgres, позволяет перенести структуру большинства таблиц данных, но не приспособлен для переноса DBMS-пакетов, которых в классическом PostgreSQL попросту нет.

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

«Очень сложно пересказать на языке PostgreSQL что-то, что выходит за его рамки. Oracle Database и MS SQL Server изначально «умеют» больше, у них и в синтаксисе языка, и на уровне ядра больше возможностей. Поэтому вот так «в лоб» поддержать переход достаточно тяжело, всегда остаются какие-то ограничения. Требуется принципиально другой подход», – подтверждает Николай Макаревич.

Ждать от разработчиков корпоративных систем, что они сами добавят в свои приложения поддержку PostgreSQL, тоже не самый оптимальный вариант. Во-первых, для этого нужно переписывать исходный код бизнес-системы, а это тоже очень трудозатратно, если она масштабная. «Например, в АБС компании «Диасофт» в три раза больше кода на T-SQL, чем во всем PostgreSQL (6.5 млн. по сравнению с 2.1 млн. строк). А в программном комплексе «ЦФТ-Банк» кода на PL/SQL – в два раза больше. По нашим подсчетам, для перевода на PostgreSQL всех российских систем, работающих на Oracle Databaseи MS SQL Server, надо переписать программного кода в 14 802 раза больше, чем во всем PostgreSQL», – делится статистикой Николай.

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

Принципиально иной подход к решению этой задачи состоит в том, чтобы производить изменения не на стороне корпоративного софта, а на стороне самой СУБД. Чтобы система могла полноценно заменить Oracle Database и MS SQL Server, она должна, в частности, уметь исполнять хранимые процедуры и функции указанных СУБД без изменения хотя бы строчки в их текстах, поддерживать синтаксис T-SQL и PL/SQL наравне с PL/pgSQL, иметь прямые аналоги всех типов данных из них, а также аналоги для самых востребованных DBMS-пакетов из Oracle и sp-хранимых процедур из MS SQL, поддерживать встроенные функции из этих СУБД.

Для этого тоже требуется грандиозная по трудозатратам работа. Например, чтобы «научить» СУБД на основе PostgreSQL «понимать» PL/SQL и T-SQL в качестве «родных» диалектов наравне с PL/pgSQL, надо написать вручную десятки или даже сотни тысяч строк исходного кода. Но зато это позволит заказчикам бесшовно мигрировать на СУБД на основе PostgreSQL, тратя на это не месяцы и годы, а считаные недели.

Таких СУБД в мире пока немного: это южнокорейская TmaxData (бывшая Tibero), китайская Proxima DB for Oracle от Alibaba, а также Digital Q.DataBase от российской компании «Диасофт».

Новая функциональность: Digital Q.DataBase  – настоящий «полиглот» в мире СУБД

Digital Q.DataBase – СУБД, созданная на основе кода PostgreSQL и полностью совместимая с ним, но имеющая ряд принципиально важных доработок. Система вышла в 2022 году, и тогда же была включена в реестр российского ПО. В 2024 году Digital Q.DataBase получила сертификат ФСТЭК.

Еще задолго до этого, в 2014 году, в продуктовом портфеле «Диасофт» появился инструмент Diasoft Database Adapter, предназначенный для перевода диалектов MS SQL Server и Oracle Database в диалект PostgreSQL. За время своего существования он позволил многим программным продуктам сторонних разработчиков, изначально «заточенным» под западные СУБД, обзавестись поддержкой PostgreSQL. Однако его возможности, как и в упомянутом ранее Ora2Pg, были ограничены из-за различия архитектур этих СУБД.

Поэтому в компании «Диасофт» сделали следующий шаг для поддержки заказчиков в процессе импортозамещения – и в 2025 году в Digital Q.DataBase появилась революционная функциональность. Благодаря ей при переходе на СУБД Digital Q.DataBase не нужно переписывать код, чтобы обеспечить ее базовую совместимость с запросами и логикой MS SQL Server и Oracle Database.

«Главное преимущество нашей СУБД состоит в том, что при переходе с зарубежной СУБД она не пытается «пересказать» функциональность на родном языке PostgreSQL, а сразу это исполняет. Мы полностью поддерживаем весь синтаксис MS SQL и Oracle, поэтому производительность системы в этом случае точно такая же, как при работе с родным языком PostgreSQL. Что касается исполнения – поскольку в PostgreSQL пока меньше возможностей, чем в западных СУБД, сегодня мы можем заместить практически всю функциональность MS SQL Server и более 70% функциональности Oracle Database. Последний показатель мы активно наращиваем, там всё упирается в большое количество DBMS-пакетов, которые нужно аккуратно воспроизвести», – объясняет Николай Макаревич.

Эксперт рассказал, что разработка этой функциональности заняла у специалистов «Диасофт» меньше года: большую роль в этом процессе сыграли уже существующие наработки, реализованные в Diasoft Database Adapter, а также сильная экспертиза компании в разработке и импортозамещении сложных программных продуктов для банковской сферы: «Всё, что относится к пониманию языка, встроенных диалектов MS SQL Server и Oracle Database, мы уже сделали ранее, и по факту сейчас нужно было просто переписать это с Java, на котором работал наш старый продукт, на C++. Это был чисто технический проект. Сложнее было встроить это в ядро системы, фактически заменить стандартный интерпретатор на три интерпретатора, каждый из которых работает с синтаксисом PostgreSQL, Oracle или MS SQL. Причем нужно не что-то куда-то перевести, а непосредственно исполнить тем ядром, который уже есть в PostgreSQL. Но с этим мы тоже успешно справились».

Теперь, установив Digital Q.DataBase, заказчику не придется адаптировать код существующих бизнес-приложений с MS SQL Server или Oracle Database – новая СУБД справится с этим сама, причем без потери производительности.

Кроме того, для удобства переноса существующих баз данных в Digital Q.DataBase создан инструмент «Мастер переноса данных», который может автоматически забрать всё имеющееся содержимое из СУБД Oracle Database, MS SQL Server, PostgreSQL и ряда его российских клонов, превратить его в набор SQL-скриптов и выгрузить их в Digital Q.DataBase. Всё, что для этого нужно, – это выбрать, откуда необходимо перенести данные, куда перенести (в новую или существующую базу), полностью или частично перенести. «Мастер переноса данных» доступен в двух вариантах: с графическим интерфейсом для специалистов, работающих с Windows, и с текстовым интерфейсом для тех, кто привык к Linux.

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

Процесс миграции

Рассмотрим более детально процесс перехода на Digital Q.DataBase. Опытно-промышленная эксплуатация начинается с развертывания СУБД Digital Q.DataBase на тестовом стенде, в этот период заказчик уже может оценить ее функциональные возможности. Запускается «Мастер переноса данных», который перемещает данные в систему. Если база крупная, этот процесс может занять несколько дней.

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

Поскольку во время переноса данных пользователи всё еще работали в исходных базах, необходимо осуществить повторную миграцию: или всей базы целиком, или только дельты (данных, которые были изменены). Как вариант – установить сторонний инструмент класса Continuous Data Distribution, который будет постоянно синхронизировать новую базу со старой.

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

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

Перспективы развития Digital Q.DataBase

По словам разработчиков «Диасофт», дорожная карта развития Digital Q.DataBase расписана более, чем на два года вперед. В первую очередь, речь идет о дальнейшем переносе DBMS-пакетов. Эта скрупулезная работа ведется каждый день.

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

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