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

Сначала о результатах

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

• операции выполняются в 15–20 раз быстрее по сравнению с «ванильной» версией PostgreSQL;
• большая часть операций выполняется быстрее, чем на исходной СУБД западного вендора (MS SQL Server), или аналогично по времени.

Рассказываем, как удалось достичь таких результатов.

Выбор стратегии импортозамещения

Мы начали с попытки пойти по простому пути: взяли одну из самых распространенных на российском рынке СУБД на основе PostgreSQL (коммерческое решение от российского вендора) и протестировали на ней работу программных продуктов класса АБС от «Диасофт». Тестовые испытания показали, что в целом решения могут на ней работать, но при использовании в реальных высоконагруженных системах показатели производительности СУБД в десятки раз меньше необходимых.

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

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

Мы решили пойти другим путем. Компания взяла открытый исходный код PostgreSQL под ответственное владение и создала на его основе форк, проверив его на уязвимости и устранив их. Форк был оптимизирован для корректной и эффективной работы в составе программных продуктов от «Диасофт».

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

Хождение по мукам: проблемы и пути их решения

Исходные СУБД западных вендоров и целевая СУБД Digital Q.DataBase имеют разную функциональность и особенности работы. 

Приведем примеры.

• В отличие от MS SQL Server, в PostgreSQL уникальным является не сочетание имени индекса и имени таблицы, на которой он создан, а только имя индекса. В продуктах класса АБС «Диасофт» есть таблицы, у которых имена индексов совпадают. Переписывание большого объема кода для изменения индексов — это не только трудоемкий, но и регрессионный процесс. Поэтому мы расширили в СУБД Digital Q.DataBase размер имен объектов. Это позволило указывать в имени индекса и таблицу, к которой он относится, чтобы обеспечить уникальность имен.
• Для быстрой выгрузки/загрузки содержимого таблиц между MS SQL Server и PostgreSQL используются утилиты, входящие в состав СУБД — bcp и copy соответственно. В отличие от bcp в MS SQL Server, утилита copy не поддерживала использование сложных разделителей между значениями полей таблиц. В АБС от «Диасофт» есть таблицы, содержащие все допустимые символы соответствующей кодовой страницы, и при их загрузке происходили ошибки. Для решения задачи перегрузки данных мы доработали утилиту copy.
• Для поддержки независимого обновления компонентов системы в случае, если в одном из них состав параметров API расширяется, необходимо было отказаться от обязательности передачи всех параметров, принятой в PostgreSQL. Для этого мы доработали ядро СУБД Digital Q.DataBase.

Проблемы производительности СУБД при среднем уровне нагрузки

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

Приведем примеры.

• При работе многопользовательских процессов, активно применяющих временные объекты, рост утилизации CPU составлял до 100%. Проведенный анализ показал, что это связано с работой механизма инвалидации планов запросов. Проблему решили доработкой указанного механизма в СУБД. После доработки разница в утилизации CPU при тестировании одинаковых операций на СУБД Digital Q.DataBase и на MS SQL Server составила не более 10–15%.
• Архитектура АБС содержит большое количество сессионных таблиц, которые являются постоянными, но содержат временные данные, актуальные для конкретной пользовательской сессии. В течение непродолжительного времени объем данных в них может меняться от нуля до миллионов строк, причем первое поле используемых индексов в большинстве случаев неселективное. В целях более эффективной работы оптимизатора с такими таблицами был доработан функционал для указания статистики, чтобы в СУБД осуществлялся поиск по индексам по максимально возможному числу полей. Итогом оптимизации стала стабилизация времени выполнения сложных запросов с использованием сессионных таблиц.
• В коде АБС на MS SQL Server для стабильной работы приложения мы активно используем механизм хинтов для оптимизатора СУБД, чтобы иметь возможность указывать порядок соединения таблиц в сложных запросах. Функционала, полностью повторяющего такие механизмы, на PostgreSQL не было. Мы доработали имеющееся расширение pg_hint_plan и дополнили его функционал набором хинтов, повторяющих логику работы MS SQL Server. Синхронно добавили использование этих новых хинтов при конвертации кода программных продуктов. 

Результат помог нам пройти нагрузочное тестирование по модели малого и среднего банка с более 85% тестовых операций, работающих на СУБД Digital Q.DataBase быстрее, чем на MS SQL Server, или с незначительным отличием в скорости. 

Проблемы производительности СУБД в условиях высоконагруженных систем

Мы начали проводить нагрузочное тестирование программных продуктов класса АБС для модели крупных банков.

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

Приведем примеры.

• В запросах с большими таблицами происходило существенное снижение производительности. Анализ планов запросов показал, что это связано с особенностями реализации в PostgreSQL сравнения полей таблиц или переменных, имеющих разный тип данных. На MS SQL Server во многих случаях при аналогичных сравнениях СУБД выполняет их более эффективно. На PostgreSQL аналогичный функционал отсутствовал. Это приводило к снижению производительности при росте размера таблиц. Мы добавили в нашу СУБД реализацию сравнений по аналогии с MS SQL Server. Тестирование доработок показало их существенное положительное влияние на производительность.
• Мы отказались от стандартных для PostgreSQL строковых типов данных и перешли на пользовательский строковый тип, работа с которым аналогична работе со строковыми типами на MS SQL Server. Доработали все нативные строковые функции для работы с данным пользовательским строковым типом — нативные функции «из коробки» вообще не поддерживают пользовательские типы. Ряд нативных функций все же имел отличия в поведении относительно MS SQL Server. Доработали сам тип данных для неявного его приведения к другим типам (аналогично MS SQL Server), обеспечили поддержку совместимости с прикладными доменными типами и со стандартными строковыми типами PostgreSQL. Таким образом, по сути, выполнены доработки для полной поддержки работы со строками, как в MS SQL Server.
• Для поддержки переходного периода со стандартного строкового типа на пользовательский, а также для поддержки ряда прикладных кейсов, доработка для которых в СУБД неоптимальна, созданы специальные функции, на которые при конвертации кода АБС подменяются штатные функции PostgreSQL. При этом внесение исправлений в код «вручную» не требуется. Также выполнены десятки модификаций конвертера прикладного кода для принудительного приведения типов в различных кейсах.
• Во время установки обновления системы для очередной итерации нагрузочного тестирования мы получили замедление скорости установки в девять раз. Длительный и итеративный поиск причины выявил влияние патча для одной из сторонних систем, вошедшего в состав Digital Q.DataBase из общедоступного ресурса.
• Неоптимальная работа под нагрузкой прикладной кастомизируемой автонумерации объектов системы потребовала выполнения доработок для оптимизации.
• В некоторых конструкциях update и delete при определении порядка соединения таблиц планировщик выбирал некорректный способ отбора записей, осуществлялось сканирование всего набора вместо позиционирования по индексу. Выполнена доработка конвертера прикладного кода для четкого управления поведением оптимизатора в определенных прикладных кейсах.
• Для производительной работы с системным view, содержащим информацию об объектах СУБД, выполнена доработка порядка обращения с предварительным форматированием наименования объекта к нужному виду.
• При работе в анонимном блоке (длительном запросе, например, в начислении) со значительными объемами данных в сессионных таблицах при циклической обработке (insert — update — delete) мы столкнулись с особенностями отложенного обновления статистики, которое происходило только после завершения указанного блока (запроса), что приводило к существенному замедлению операций. Для решения проблемы СУБД была доработана: реализована настройка частоты отложенного обновления статистики.

В результате доработок мы добились целевых показателей производительности прикладного ПО на СУБД Digital Q.DataBase, соответствующих уровням нагрузки средних и крупных банков. Около 90% общего количества тестовых сценариев работают на СУБД Digital Q.DataBase быстрее, чем на MS SQL Server, или с незначительным отличием в скорости.

Сравнение основных характеристик первого и второго этапов нагрузочного тестирования

Кроме того, в ходе второго этапа тестирования выполнялись следующие операции:

• платежные карты — начисление процентов по 150 тыс. кредитным и 100 тыс. дебетовым картам, погашение задолженности по 30 тыс. кредитным картам, открытие 1 тыс. карт в день;
• кредиты — обработка 200 тыс. кредитов (начисление процентов, ежевечерняя обработка и начисление резервов с пересчетом графика платежей по 28 тыс. кредитов);
• ценные бумаги — загрузка и обработка 100 тыс. дилерских сделок;
• Forex — загрузка и обработка 20 тыс. дилерских сделок;
• межбанковское кредитование (МБК) — загрузка и обработка 1,5 тыс. сделок;
• депозитарий — обработка корпоративного действия с выплатой дохода 20 тыс. владельцам, расчет депозитарной комиссии по 100 тыс. клиентов с формированием 100 тыс. счетов на оплату;
• брокерские операции — загрузка, подтверждение и учет (бухгалтерский и внутренний) 100 тыс. брокерских сделок на фондовом рынке по 100 тыс. брокерским договорам;
• число вкладов, по которым начислялись проценты, — 60 тыс. (как и в первом этапе тестирования).

Результаты второго этапа нагрузочного тестирования

По итогам проведенной оптимизации и тестирования видно, что разница по времени работы тестовых операций на Digital Q.DataBase и PostgreSQL очень значительна: для отдельных операций она составляет до 15–20 раз.

Из 193 тестовых сценариев 173 (89,6% общего количества) работают на СУБД Digital Q.DataBase быстрее, чем на исходной СУБД MS SQL Server, или с незначительным отличием в скорости, в том числе:

• 126 тестовых сценариев показали более высокую скорость работы;
• 24 тестовых сценария показали аналогичное время работы;
• 23 тестовых сценария показали время работы некритично большее.

Для всех массовых длительных операций, продолжительность которых более 10 минут (например, обработка загрузок и начисления по большим объемам данных), время работы на Digital Q.DataBase соответствует или лучше, чем на MS SQL Server. Скорость выполнения некоторых длительных операций в два и более раза выше на Digital Q.DataBase, чем на MS SQL Server.

Сравнение времени выполнения некоторых операций на разных СУБД

Вывод: легко и быстро не получится

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

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