При развертывании нового сервера для работы систем «1С:Предприятие» перед ИТ-специалистами и администраторами часто встает вопрос выбора системы управления базами данных (СУБД). Традиционный, проверенный временем Microsoft SQL Server является коммерческим и дорогостоящим продуктом. В качестве альтернативы все чаще рассматривается свободно распространяемая СУБД PostgreSQL (или ее коммерческая отечественная сборка Postgres Pro). Рассмотрим подробно, насколько жизнеспособна связка 1С и PostgreSQL, с какими трудностями можно столкнуться при ее внедрении и как правильно настроить систему для достижения максимальной производительности.
Прежде всего выясним важный нюанс: использовать стандартную («ванильную») версию PostgreSQL, скачанную с официального сайта сообщества, для работы с 1С крайне не рекомендуется. Платформа «1С:Предприятие» накладывает специфические требования к механизмам блокировок, работе с временными таблицами и генерации планов запросов.
Для корректной и быстрой работы систем 1С необходимо использовать специализированные сборки. Разберем по шагам, какие варианты дистрибутивов существуют:
В современных дистрибутивах Postgres Pro процесс установки максимально упрощен. Инсталлятор для операционной системы Windows содержит удобный графический мастер, который в процессе установки предлагает применить рекомендуемые настройки оптимизации под конфигурации 1С. Это существенно облегчает жизнь начинающим администраторам.
Проанализируем одну из самых известных проблем оптимизации СУБД PostgreSQL при работе с запросами 1С — использование алгоритма вложенных циклов (Nested Loops). В старых версиях платформы 1С и СУБД Postgres (примерно до 2011–2012 годов) планировщик СУБД часто ошибался при анализе сложных запросов с подзапросами (характерных для закрытия месяца, распределения затрат и расчета себестоимости). Он выбирал алгоритм Nested Loop там, где гораздо эффективнее отработали бы алгоритмы Hash Join или Merge Join. Это приводило к колоссальным зависаниям процессов.
Для решения этой проблемы администраторы принудительно отключали вложенные циклы в конфигурационном файле postgresql.conf:
# Принудительное отключение алгоритма Nested Loop
enable_nestloop = off
Рассмотрим, как обстоит ситуация в современных реалиях. Начиная с версии платформы 1С 8.3.11 и СУБД PostgreSQL 9.6 и выше, ситуация кардинально изменилась. Фирма 1С оптимизировала механизмы работы платформы, практически полностью отказавшись от сложных подзапросов в пользу использования временных таблиц с их обязательным индексированием. Современные типовые конфигурации (такие как «1С:ERP Управление предприятием», «1С:Комплексная автоматизация» или «1С:Бухгалтерия 3.0») изначально проектируются с учетом требований версионных СУБД.
Поэтому в современных высоконагруженных системах полное отключение параметра enable_nestloop может снизить производительность простых запросов, где вложенные циклы действительно эффективны. Рекомендуется оставлять данный параметр включенным (on), но при возникновении точечных проблем с производительностью конкретных тяжелых отчетов анализировать технологический журнал 1С и планы запросов СУБД.
Платформа 1С в процессе своей работы создает огромное количество временных таблиц. В СУБД PostgreSQL создание и удаление временных таблиц сопряжено с высокой нагрузкой на системный каталог (системные таблицы метаданных СУБД). При высокой параллельной работе пользователей это может вызывать блокировки системного каталога.
Разберем, как современные сборки решают эту проблему. В актуальных версиях Postgres Pro Enterprise реализованы специализированные доработки ядра, такие как параметр skip_temp_rel_lock. Этот параметр позволяет пропускать установку блокировок на индексы временных таблиц, поскольку они видны исключительно внутри конкретного сеанса пользователя. Это нововведение позволяет избежать взаимных блокировок и существенно ускоряет работу систем с большим количеством одновременно работающих пользователей.
Организация регулярного резервного копирования — первоочередная задача системного администратора. Выясним, как настроить бэкап базы данных PostgreSQL в режиме «горячего» копирования, когда пользователи продолжают активную работу в системе.
Для небольших баз данных (размером до 20–30 Гб) отлично подходит штатная утилита логического резервного копирования pg_dump. Она создает согласованный снимок базы данных на момент начала своей работы, не блокируя при этом чтение и запись для пользователей. Процесс можно легко автоматизировать с помощью планировщика задач (Task Scheduler в Windows или Cron в Linux).
Рассмотрим пример создания простого скрипта для автоматического резервного копирования под управлением Windows:
@echo off
rem Настройка переменных окружения
set PGUSER=postgres
set PGPASSWORD=ВашПарольПользователяPostgres
set BACKUP_DIR=D:\Backup1C
set PG_BIN="C:\Program Files\PostgresPro\1c\bin\pg_dump.exe"
set DB_NAME=trade_db
rem Формирование имени файла с текущей датой
set FILE_NAME=%DB_NAME%_%date:~10,4%-%date:~4,2%-%date:~7,2%.backup
rem Запуск резервного копирования в сжатом формате
%PG_BIN% -h localhost -p 5432 -U %PGUSER% -F c -b -v -f "%BACKUP_DIR%\%FILE_NAME%" %DB_NAME%
Для крупных и высоконагруженных баз данных (от 50 Гб и выше) использование логического бэкапа через pg_dump становится неэффективным, так как процесс может занимать длительное время и создавать высокую нагрузку на дисковую подсистему. В таких случаях мы рекомендуем использовать специализированную утилиту физического резервного копирования pg_probackup.
Инструмент pg_probackup позволяет выполнять:
В отличие от MS SQL Server, архитектура PostgreSQL основана на принципе версионности строк (MVCC). При изменении или удалении записи СУБД физически не перезаписывает старые данные, а помечает их как «мертвые» и записывает новую версию строки. Это позволяет избежать блокировок при одновременном чтении и записи.
Однако со временем база данных начинает накапливать большое количество «мертвых» строк, что приводит к увеличению ее физического размера и деградации производительности (эффект «раздувания» базы или bloat). Для борьбы с этим явлением необходимо настроить регулярные регламентные операции:
В современных версиях PostgreSQL за очистку и сбор статистики отвечает встроенная служба autovacuum. Для баз данных 1С, характеризующихся высокой интенсивностью записи, стандартные настройки автовакуума могут быть слишком «мягкими». Рекомендуется скорректировать параметры автовакуума в файле postgresql.conf, сделав его более агрессивным, чтобы очистка происходила быстрее и чаще.
Разберем влияние операционной системы на производительность СУБД PostgreSQL. Исторически PostgreSQL разрабатывался под UNIX-подобные операционные системы, поэтому его архитектура наиболее эффективно работает именно в среде Linux.
Проанализируем основные различия:
Рассмотрим ситуацию, когда необходимо перенести существующую базу данных 1С с СУБД MS SQL на PostgreSQL (или обратно). Универсальным и наиболее надежным способом, поддерживаемым платформой, является использование механизма выгрузки и загрузки конфигурации вместе с данными через файл с расширением *.dt.
Пошагово этот процесс выглядит следующим образом:
*.dt.*.dt.Важно помнить, что для очень крупных баз данных (размером более 100-150 Гб) процесс выгрузки в формат *.dt может завершаться критическими ошибками нехватки памяти на стороне сервера приложений или занимать слишком много времени. Для миграции таких баз применяются специализированные программные инструменты и скрипты, осуществляющие прямой перенос данных на уровне таблиц СУБД.
СУБД PostgreSQL (особенно в редакции Postgres Pro для 1С) на сегодняшний день является полностью зрелым, стабильным и высокопроизводительным решением промышленного класса. Для небольших компаний с количеством пользователей до 20–50 человек внедрение PostgreSQL позволяет существенно сэкономить ИТ-бюджет без потери качества и быстродействия систем автоматизации. Главное — использовать специализированные сборки СУБД, уделить внимание базовой настройке параметров планировщика и автоматизировать регулярные регламентные процедуры обслуживания.