Импортозамещение СУБД ГИС ГМП с Oracle RAC на шардированную СУБД

Государственная информационная система о государственных и муниципальных платежах (ГИС ГМП) предназначена для централизованного размещения и получения информации, необходимой для уплаты государственных и муниципальных услуг, пошлин, штрафов и налогов. Система обеспечивает взаимодействие «администраторов начислений» (ведомств, формирующих счета) и финансовых организаций (банков, через которые граждане и юридические лица производят оплату в бюджет).

Ядром ГИС ГМП до недавнего времени являлась СУБД Oracle, размещенная на импортной инфраструктуре. Общий объем базы данных достигал 240 терабайт, из которых 180 терабайт приходилось на пользовательские данные и около 60 терабайт — на индексы. Ключевая задача проекта заключалась в переводе ГИС ГМП на российский технологический стек, включая ПО и инфраструктуру, в рамках программы импортозамещения. При этом требовалось обеспечить работу системы федерального значения без простоев и потери данных.

2025

В результате проекта основной и резервный кластеры Oracle RAC (Real Application Cluster), всего четыре сервера, каждый содержал по 192 двухпоточных ядра и 3 Тб оперативной памяти, были полностью заменены на кластер Postgres Pro Shardman, включающий 40 серверов (19 мастеров, 19 реплик и 2 резервных узла по 56 ядер). Общий объем базы данных удалось сократить на 50 ТБ за счет оптимизации структуры и пересмотра накопленных данных. Производительность системы выросла, количество отказов существенно уменьшилось.

Одновременно были обновлены операционные системы и версии прикладного ПО  в соответствии с требованиями ФСТЭК. Также обеспечена высокая отказоустойчивость и возможность горизонтального масштабирования до уровней, необходимых для работы государственных систем в дальнейшем.

Реализован переход на кластер Postgres Pro Shardman, включающий 40 серверов (19 мастеров, 19 реплик и 2 резервных узла) с СУБД Oracle RAC(2 а мастера, 2 standby).

Программное обеспечение ГИС ГМП реализовано на платформе SmartVista Integration Platform (SVIP) и представляет собой набор бизнес-процессов нотации BPMN 2.0 с расширениями JavaScript для выполнения основных задач по обработке поступающих сообщений в транзакционной части и на ряда нативных приложений java для функционала АРМ. Взаимодействие подсистем прикладного программного обеспечения на базе SVIP выполняется через Apache Kafka.

В проекте не используются решения из каталога Global CIO

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

Немаловажным было требование сохранения работоспособности системы в рамках коэффициента доступности в момент миграции и гарантированное сохранение целостности данных.

Готовые инструменты миграции, такие как Debezium и Oracle GoldenGate не подошли под специфику проекта, поэтому было разработано собственное решение, способное переносить данные с учетом новой схемы и происходящих в Oracle изменений данных. Перенос выполнялся методом, обеспечивающим целостность данных — фрагментами с фиксацией результатов в журнале.

Федеральное казначейство предъявляло жесткие требования к новой СУБД: поддержка критически больших объемов данных, горизонтальное масштабирование, отказоустойчивость, соответствие регуляторным требованиям и перспектива роста до петабайтного уровня. Выбор был сделан в пользу Postgres Pro Shardman — распределенной отечественной СУБД, способной обрабатывать данные объемом до 2 петабайт. Адаптацию прикладного ПО и интеграционной платформы SmartVista Integration Platform выполняла компания «БПС Инновационные программные решения». Адаптация включала в том числе и перенос имеющейся в Oracle части бизнес-логики из СУБД на уровень прикладного ПО. Миграцию баз данных осуществляла компания PTЛабс.

Процесс миграции состоял из несколько этапов:

1. Копирование накопленных данных и параллельный перенос изменений.

2. Параллельная работа систем на Oracle и Shardman: «параллельный импорт» входящих данных и поэтапное переключение запросов на обновленную версию с контролем производительности и корректности возвращаемых данных.

3. Фактический переход на новую СУБД при сохранении возможности возврата на старую версию в случае выявления проблем на завершающих этапах.

4. Вывод Oracle из эксплуатации.

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

В части доработки прикладного ПО было реализовано переписывание сложных SQL-запросов, а в некоторых случаях — разделение сложных операций на несколько последовательных шагов для учета специфики распределенной среды.

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

Территория Российской федерации