Перевод 1С с MS SQL на PostgreSQL — это комплексная задача, включающая преобразование структуры базы данных, адаптацию логики запросов и настройку производительности. Она не решается простым восстановлением из резервной копии. Использование dt-файла или pg_dump обеспечивает только перенос данных, тогда как основная сложность миграции заключается в различиях между MS SQL и PostgreSQL в механизмах блокировок, построении планов запросов и обработке временных таблиц. Ниже приведены данные, основанные на реальных проектах миграции, с описанием ключевых операций и типичных ошибок на каждом этапе.

Аудит и оценка совместимости

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

Ядро аудита — выявление кода, зависящего от платформы. Часть SQL-запросов, генерируемых 1С, хорошо оптимизирована для MS SQL, но в PostgreSQL может порождать неэффективные планы. На практике одна конфигурация ERP сгенерировала более 25 миллионов записей о запросах; после очистки осталось около 10 миллионов, из которых почти 19% содержали ошибки преобразования, более 34 тысяч мест были связаны с проблемой кодировки 0x01, а ещё около 7000 — со сложным синтаксисом TOP. Инструмент аудита должен автоматически анализировать платформозависимые механизмы в коде и разделять используемые и неиспользуемые модули, чтобы сократить объём последующего рефакторинга.

После перехода на PostgreSQL различия в механизмах блокировок становятся главным риском производительности. Реализация MVCC в PostgreSQL и механизм уровней изоляции MS SQL различаются, из-за чего при высокой нагрузке операции с временными таблицами и доступ к общим ресурсам в 1С могут вызывать каскадные блокировки. В ряде проектов миграции конфликты блокировок становились заметными при числе пользователей свыше 300. Заблаговременное изучение этих различий и воспроизведение сценариев с большим числом одновременных пользователей в тестовой среде — обязательное условие предотвращения инцидентов в промышленной эксплуатации.

Адаптация с T-SQL на PostgreSQL

Запросы, генерируемые 1С, требуют преобразования из диалекта MS SQL в совместимую с PostgreSQL форму; именование временных таблиц и управление тайм-аутами — ключевые технические точки преобразования. Преобразование не сводится к простой замене синтаксиса: необходимо решить три задачи — жизненный цикл временных таблиц, тайм-аут выполнения и стабильность планов.

Обработка временных таблиц — наиболее подверженный ошибкам этап миграции. В MS SQL временные таблицы (например, #tt10) управляются автоматически в рамках сессии, тогда как в PostgreSQL номер сессии требуется встраивать в имя таблицы во избежание конфликтов, например преобразуя #tt10 в tt10_87. При разрыве и восстановлении соединения таблица с тем же именем может уже существовать, поэтому перед созданием необходимо выполнять удаление. Одновременно требуется вести кэш временных таблиц, отслеживающий, какие таблицы уже созданы в текущей сессии.

Управление тайм-аутом запросов требует корректной настройки параметра statement_timeout. Начальное значение рекомендуется устанавливать как время выполнения этого запроса в MS SQL, умноженное на эмпирический коэффициент; это не позволяет неоптимальному запросу бесконечно занимать ресурсы. После прерывания запроса по тайм-ауту можно повторно выполнить его с префиксом EXPLAIN, чтобы получить информацию о плане для последующей оптимизации. Следует также учитывать механизм обновления статистики в PostgreSQL: по умолчанию autovacuum запускает анализ при изменении более 20% таблицы, что для больших таблиц означает длительное использование устаревшей статистики и, как следствие, неоптимальные планы запросов.

Планирование ресурсов и конфигурация параметров

PostgreSQL не требует меньше аппаратных ресурсов, чем MS SQL: для эквивалентной нагрузки требуется равноценная конфигурация, а на начальном этапе миграции следует закладывать полуторакратный запас. Сокращение ресурсов в расчёте на «высокую эффективность использования памяти» PostgreSQL — прямая причина неудачи многих проектов миграции.

Настройка параметров памяти — ядро оптимизации. Параметр work_mem управляет объёмом памяти, доступным для сортировки, хеш-соединений и агрегации; слишком малое значение приводит к массовому сбросу на диск, слишком большое — к исчерпанию памяти при конкурентных запросах. В PostgreSQL десятки параметров, связанных с памятью, против обычно настраиваемых четырёх-пяти в MS SQL. Параметры shared_buffers, effective_cache_size, maintenance_work_mem требуют индивидуальной настройки под конфигурацию оборудования и характер нагрузки; универсального «оптимального значения» не существует.

Российские СУБД на базе PostgreSQL предлагают версии, оптимизированные под 1С. Postgres Pro Enterprise для 1С реализует механизм индексов MCHAR/MVARCHAR LIKE, ускоряющий поиск по словам в миллионных записях в 3–7 раз, а поиск подстрок — на порядок быстрее. Эта версия также оптимизирует механизм блокировок временных таблиц, повышая скорость обработки конкурентных операций до 27%, и улучшает работу с временными файлами, ускоряя первые запросы пользователей в 1,5–2 раза. На стандартном оборудовании эта версия по результатам тестирования поддерживает 30 000 одновременных пользователей и базу данных объёмом 150 ТБ.

Ещё один значимый параметр — адаптивный оптимизатор запросов (AQO). Механизм AQO в Postgres Pro Enterprise для 1С позволяет снизить влияние неоптимальных планов выполнения без изменения кода 1С. Для таких операций с неравномерным распределением данных, как закрытие месяца, оптимизированный планировщик сокращает время выполнения с 4 часов до 20 минут.

Выбор российских версий PostgreSQL

Для 1С доступны две основных российских СБУД на PostgreSQL — Postgres Pro Enterprise для 1С и Tantor Certified для 1С. Первый имеет более глубокую проработку по производительности, второй — по охвату сертификации ФСТЭК. Выбор зависит от приоритета требований по производительности и соответствию регуляторным нормам.

Postgres Pro Enterprise для 1С разработан компанией Postgres Professional, включён в единый реестр российского ПО (регистрационный номер 104) и имеет официальную сертификацию от 1С. Стоимость лицензии составляет 156 601 рубль за ядро x86-64 с гарантией на 12 месяцев, годовая техническая поддержка начинается от 38 213 рублей. Технические преимущества сосредоточены на оптимизации запросов: адаптивный оптимизатор AQO, ускорение индексов для типов данных 1С, а также настроенные механизмы блокировок и обработки временных таблиц.

Tantor Certified для 1С разработан компанией Tantor Labs (входит в группу «Астра»), имеет сертификат ФСТЭК, соответствующий 4 уровню доверия и 4 уровню защиты СУБД, и применим до 1 класса защищённости государственных информационных систем, до 1 класса АСУ ТП, до 1 класса информационных систем персональных данных и до 1 категории значимых объектов критической информационной инфраструктуры. Продукт включён в партнёрскую сеть 1С и распространяется через франчайзинговые каналы. Лицензия рассчитывается по ядрам процессора, доступны варианты на 12, 24, 36 месяцев или бессрочная.

Arenadata Prosperity — ещё одна российская СУБД на базе PostgreSQL, имеющая сертификат ФСТЭК по 4 уровню доверия и ориентированная на смешанные нагрузки. Продукт включает управление пулом соединений, инкрементное резервное копирование и автоматическое переключение при отказе, что применимо для развёртываний 1С, требующих смешанной обработки OLTP и умеренной аналитической обработки. Для команд, ещё не определивших конкретные сроки миграции, но нуждающихся в предварительной оценке вариантов, Arenadata предлагает путь плавного перехода с открытой версии PostgreSQL.

Стратегия переключения: как управлять бизнес-рисками

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

Типовая практика поэтапной миграции — постепенное переключение по базам данных или по группам пользователей. Одна из применимых топологий: для каждой базы данных одновременно поддерживаются два синхронизированных экземпляра — на MS SQL и на PostgreSQL, а согласованность данных обеспечивается через мост репликации. Пользователи переводятся с MS на PostgreSQL партиями; после переключения каждой партии контролируются показатели производительности, и при значительном снижении производительности партия возвращается на MS. В одном из проектов таким способом за несколько месяцев были мигрированы 40 распределённых баз данных.

Механизм отката должен быть продуман заранее. При возникновении на стороне PostgreSQL проблем, не решаемых быстро, должна быть возможность вернуть затронутых пользователей на MS SQL без прерывания общего обслуживания. Один из вариантов — сохранение синхронизации экземпляра MS SQL в реальном времени: при сбое PostgreSQL мост обратной репликации отключается, а пользователи временно направляются на экземпляр MS SQL. Другой способ — сохранить для отдельных пользователей независимый канал подключения к MS SQL, позволяющий им в период миграции выполнять ключевые отчёты или операции.

Мониторинг — гарантия стабильной работы после переключения. В стандартном PostgreSQL отсутствует возможность тонкой трассировки запросов, аналогичная MS SQL Extended Events, из-за чего при жалобах пользователей на «замедление работы» трудно локализовать конкретный запрос. Сторонний инструмент PerfExpert обеспечивает трассировку запросов с привязкой к сессии, помогая быстро выявлять узкие места. Мониторинг после миграции должен охватывать показатель APDEX, ключевые параметры загрузки оборудования и журналы ошибок приложений, гарантируя, что производительность системы не ниже, чем до миграции.