Стоит ли переходить с MS SQL на PostgreSQL в среде 1С:Предприятие 8?

Вопрос выбора системы управления базами данных (СУБД) для 1С исторически сопровождался мифами о нестабильности и медлительности PostgreSQL по сравнению с MS SQL Server. Однако с развитием платформы 1С:Предприятие 8.3 и выходом новых версий «Слона» (PostgreSQL) ситуация кардинально изменилась. Проанализируем, в каких случаях переход оправдан, с какими техническими трудностями придется столкнуться и как правильно подготовить инфраструктуру.

Технологическая готовность PostgreSQL для 1С

Рассмотрим текущее состояние дел. Начиная с версии платформы 8.3.13 и PostgreSQL 10, поддержка СУБД вышла на новый уровень. Современный PostgreSQL умеет эффективно распараллеливать запросы, что раньше было главным преимуществом MS SQL. Выясним, почему многие эксперты рекомендуют использовать не «ванильную» сборку, а специализированные решения, такие как Postgres Pro или сборки от самой компании 1С.

Специализированные сборки содержат критически важные патчи для 1С:

1. Global Temporary Tables: Оптимизация работы с временными таблицами, которые 1С создает в огромных количествах.
2. Plantuner: Позволяет платформе 1С более гибко управлять планами выполнения запросов, минимизируя ошибки оптимизатора СУБД.
3. Параллельное сканирование: Улучшенная работа с индексами при тяжелых выборках.

Проблемы сложных запросов и транзакционная модель

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

1. Полные соединения (FULL JOIN): PostgreSQL крайне не любит ПОЛНОЕ СОЕДИНЕНИЕ. Если в MS SQL такие запросы проходят относительно безболезненно, то на Postgres они могут вызвать колоссальную нагрузку. Рекомендуем заменять их на объединение результатов (UNION ALL) левых и правых соединений, если это возможно.

2. Виртуальные таблицы в соединениях: Рассмотрим классическую проблему — соединение с виртуальной таблицей СрезПоследних. В старых версиях это приводило к деградации производительности. В современных версиях (PostgreSQL 12+) и при использовании актуальных релизов платформы 1С проблема во многом нивелирована, но «лучшей практикой» остается предварительная выгрузка данных из виртуальных таблиц во временные таблицы перед соединением.

3. Механизм блокировок: Современная 1С работает в режиме управляемых блокировок. Это означает, что логика блокировок перенесена на уровень сервера приложений 1С. В этом режиме PostgreSQL работает практически идентично MS SQL, так как конфликты на уровне СУБД сводятся к минимуму. Однако, если ваша база все еще использует «Автоматический режим блокировок», PostgreSQL может блокировать таблицы целиком там, где MS SQL заблокировал бы только диапазон строк.

Критический фактор: Выбор операционной системы

Проанализируем ситуацию с выбором ОС. Опыт администраторов однозначно говорит: PostgreSQL нельзя эксплуатировать под Windows для серьезных нагрузок. Рассмотрим причины:

• Модель процессов: PostgreSQL использует архитектуру fork (процессы), которая в Windows эмулируется через потоки, что работает медленнее.
• Работа с памятью: В Linux управление дисковым кэшем и виртуальной памятью реализовано более эффективно для алгоритмов PostgreSQL.
• Баги файловой системы: Существуют подтвержденные проблемы со сбором статистики на NTFS под Windows, что может привести к резкому замедлению запросов из-за неверных планов выполнения.

Если вы планируете переход, закладывайте в бюджет развертывание на Linux (например, Ubuntu, CentOS или Astra Linux).

Ограничение прав на уровне записей (RLS)

Выясним причину, по которой «тяжелые» типовые конфигурации (ERP, Комплексная автоматизация) иногда тормозят на PostgreSQL. Главный виновник — RLS (Row Level Security). При включении ограничений доступа 1С дописывает к каждому запросу огромные куски кода с проверками прав. PostgreSQL сложнее переваривает такие монструозные конструкции, чем MS SQL.

Однако в последних версиях Библиотеки стандартных подсистем (БСП 3.0 и выше) механизм RLS был принципиально переработан. Рассмотрим, как это работает: теперь вместо динамического формирования сложных условий используются заранее рассчитанные таблицы прав (ключи доступа). Это значительно упрощает жизнь оптимизатору PostgreSQL. Если ваша конфигурация современная — проблем с RLS будет на порядок меньше.

Настройка и обслуживание (DBA-задачи)

Переход на PostgreSQL требует изменения подходов к обслуживанию. Посмотрим на основные регламентные операции:

1. Настройка конфига: Стандартный файл postgresql.conf настроен на минимальное потребление ресурсов. Его нужно обязательно тюнить под ваше железо (параметры shared_buffers, work_mem, effective_cache_size и другие).
2. Обслуживание индексов: В PostgreSQL индексы склонны к раздуванию (bloat). Регламентный REINDEX обязателен, в то время как в MS SQL чаще обходятся дефрагментацией.
3. Vacuum и Analyze: PostgreSQL использует механизм MVCC (многоверсионность строк). Старые версии строк нужно вычищать. Автоматический autovacuum должен быть настроен агрессивно, чтобы база не «пухла» при массовых перепроведениях документов.

Пример анализа неоптимального кода

Проанализируем ситуацию, когда запрос написан «под MS SQL» и может вызвать проблемы на PostgreSQL. Рассмотрим фрагмент кода:

// Неоптимально для PostgreSQL: соединение с вложенным запросом
Запрос.Текст = "ВЫБРАТЬ
               |    Товары.Ссылка,
               |    ВложенныйЗапрос.Остаток
               |ИЗ
               |    Справочник.Номенклатура КАК Товары
               |ЛЕВОЕ СОЕДИНЕНИЕ (
               |    ВЫБРАТЬ Номенклатура, СуммаОстаток КАК Остаток
               |    ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки
               |) КАК ВложенныйЗапрос ПО Товары.Ссылка = ВложенныйЗапрос.Номенклатура";

Для оптимизации работы на PostgreSQL рекомендуется сначала поместить данные из виртуальной таблицы во временную таблицу, проиндексировать её, и только потом выполнять соединение. Это гарантирует, что оптимизатор выберет правильный тип соединения (например, Hash Join или Merge Join).

Резюме для принятия решения

Подведем итог. PostgreSQL можно и нужно выбирать вместо MS SQL, если:

• У вас есть компетенции в администрировании Linux или готовность их развивать.
• Вы используете современные версии платформы 1С (8.3.15+).
• Стоимость лицензий MS SQL является критическим фактором для бюджета.
• Ваша конфигурация использует управляемые блокировки.

Переход не будет «1:1» в плане администрирования — PostgreSQL требует более тонкой ручной настройки. Но с точки зрения конечного пользователя, при правильной настройке на Linux-сервере, разница в производительности будет практически незаметна.