Postgres Pro 11 у госзаказчика: партиционирование и поддержка на русском как аргументы

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

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

Почему Postgres Pro, а не ванильный PostgreSQL

Это был первый вопрос, который мы обсуждали с заказчиком внутри - и ответ на него не очевидный.

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

Первое - реестр отечественного ПО. Vanilla PostgreSQL там не значится - это американский open source с американским брендом, и формально под критерии не попадает. Postgres Professional - российская компания, Postgres Pro в реестре есть, соответствие критериям импортозамещения подтверждено документально.

Второе - наличие сертификата ФСТЭК. У Postgres Pro Enterprise 11 есть сертификат соответствия требованиям безопасности информации. Для части систем заказчика это не опция, а обязательное условие.

Ещё один аргумент, который мы поначалу не оценили в полной мере: поддержка на русском языке в рабочее время московского пояса и с SLA 24/7. Звучит как маркетинговый буклет, но когда у тебя инцидент в 3 ночи и сбой в продакшн-базе госсистемы - это конкретная и важная вещь. У ванильного PostgreSQL такого нет.

Что пилотировали

Взяли одну из информационных систем заказчика - не самую нагруженную, но с нетривиальной схемой. Таблица с историческими данными за несколько лет, несколько сотен миллионов строк, запросы с аналитическими агрегатами за произвольные периоды. На Oracle эта таблица была партиционирована по диапазону дат, и часть запросов чувствительно зависела от partition pruning.

Первоначальный план был простой: перенести схему, мигрировать данные через pg_dump или ora2pg, проверить что запросы работают адекватно. Реальность оказалась чуть интереснее.

Партиционирование в Postgres Pro 11. В ванильном PostgreSQL 11 декларативное партиционирование уже есть, но Postgres Pro Enterprise добавляет поверх несколько вещей. Одна из них - расширенный partition pruning, включая runtime pruning для параметризованных запросов. Для нашей таблицы это оказалось важным: основной аналитический запрос строится динамически с переменными датами на входе, и без runtime pruning планировщик не отсекал лишние партиции на этапе планирования.

Проверяли EXPLAIN ANALYZE с реальными параметрами. На vanilla PG 11 запрос сканировал почти все партиции. Та же схема на Postgres Pro 11 с runtime pruning - сканирует только нужные. Разница в плане выполнения была существенной.

Миграция данных. ora2pg справился с основным объёмом. Несколько специфичных Oracle-типов пришлось конвертировать вручную - ничего неожиданного. Хранимые процедуры - вот это отдельная история: Oracle PL/SQL и PostgreSQL PL/pgSQL синтаксически похожи, но дьявол в деталях. Несколько процедур переписывали заново, а не конвертировали.

Производительность. Без тюнинга - как обычно - хуже исходного Oracle. После базовой настройки work_mem, shared_buffers, effective_cache_size и нескольких индексов, которые ora2pg не вытянул автоматически - сопоставимо. Для аналитических запросов с партиционированием - местами даже лучше, потому что PostgreSQL-планировщик в ряде случаев строит более чистый план.

Что вызвало вопросы

Не всё прошло гладко, и писать только про победы было бы нечестно.

• Документация на русском. Она есть, и это реальный плюс для команды заказчика. Но часть документации по enterprise-расширениям ощутимо отстаёт от кода. Некоторые параметры партиционирования искали в исходниках и через поддержку.

• Экосистема инструментов. Что-то из привычного Oracle-арсенала на PostgreSQL не переносится напрямую. Заказчик использовал несколько инструментов для мониторинга и администрирования, которые работали с Oracle через JDBC - часть из них поддерживает PostgreSQL-драйвер, часть нет. Пришлось смотреть на замену.

• Привычки разработчиков. Внутренняя команда заказчика писала SQL с Oracle-специфичным синтаксисом - ROWNUM, CONNECT BY, NVL. Это не блокер, но это отдельная работа по рефакторингу запросов, которую нельзя автоматизировать полностью.

Где сейчас

Пилот завершён, данные перенесены, система работает в тестовой среде с реальной нагрузкой. До конца года планируем перевод в продакшн.

Главное, что мы из этого пилота вынесли: Postgres Pro для задач замены Oracle в госсегменте - это рабочий вариант, но «просто поставить и мигрировать» не получится. Партиционирование, хранимые процедуры, инструментарий - всё это требует реального инженерного внимания, а не перекладывания ответственности на «совместимость». Из того, что неожиданно сработало - runtime partition pruning в Postgres Pro 11 закрыл ровно ту проблему, которая у нас была с аналитическими запросами.

SLA-поддержка от Postgres Professional на русском языке тоже оказалась не пустым словом: один инцидент с зависанием autovacuum на большой таблице решили за несколько часов с реальной перепиской и ответами по делу, а не шаблонными письмами.

Сопровождение баз данных в контексте таких миграций - именно это мы сейчас и делаем с несколькими заказчиками параллельно.