Исторически экосистема 1С:Предприятие развивалась в тесной интеграции со стеком технологий Microsoft. Долгое время связка Windows Server + MS SQL Server считалась безальтернативным стандартом для баз данных средней и высокой нагруженности. Однако технологический рывок свободного ПО, появление специализированных отечественных сборок (в первую очередь Postgres Pro от компании Postgres Professional) и изменившиеся внешние условия кардинально переписали правила игры. Сегодня переход на PostgreSQL — это не просто способ экономии на лицензиях, а стратегический шаг для обеспечения стабильности и импортозамещения.
В этой статье мы подробно проанализируем обе СУБД, разберем ключевые различия в их архитектуре, по шагам настроим критически важные параметры конфигурации, решим проблемы с резервным копированием тяжелых баз и выясним, как выжать максимум производительности из PostgreSQL в среде 1С.
Лицензионная политика Microsoft всегда отличалась высокой стоимостью и сложностью расчета. Для работы MS SQL Server требуются лицензии на процессорные ядра сервера (с минимальным пакетом на 4 ядра) плюс клиентские лицензии доступа (CAL) на каждое рабочее место или устройство, а также лицензии на саму операционную систему Windows Server. В масштабах предприятия с сотнями пользователей стоимость ПО Microsoft оперативно превышает стоимость самого серверного оборудования в несколько раз.
В случае с PostgreSQL ситуация выглядит иначе:
AQO (Adaptive Query Optimization). Она ориентирована на высоконагруженные базы масштаба Highload (тысячи одновременно работающих пользователей, терабайтные объемы) и обеспечивает производительность, сопоставимую с Oracle или топовыми редакциями MS SQL Enterprise.Рассмотрим важную архитектурную деталь. MS SQL Server изначально создавался под ОС Windows и глубоко интегрирован с подсистемой управления памятью и кэшированием этой операционной системы. Попытки запустить PostgreSQL в среде Windows для промышленной эксплуатации часто приводят к разочарованию.
Причина кроется в механизмах работы с файлами и памятью. UNIX-подобные системы (Linux, Astra Linux, РЕД ОС, Альт Линукс) работают с процессами и системным кэшем принципиально иначе. Под Linux СУБД PostgreSQL напрямую использует системный буферный кэш (Buffer Cache) операционной системы без лишних накладных расходов. В Windows аналогичные операции требуют монопольного доступа и сопровождаются блокировками файлов статистики (что было исправлено только в последних версиях, но накладные расходы на уровне API ОС все равно остаются высокими).
Практический вывод: Если вы планируете внедрение PostgreSQL, разворачивайте его исключительно на Linux. Простой перенос СУБД с Windows на Linux на одном и том же физическом оборудовании дает прирост производительности дисковой подсистемы и оперативной памяти до полутора-двух раз.
Проанализируем результаты популярных тестов производительности (например, теста Гилева). При установке по умолчанию («из коробки») MS SQL Server практически всегда опережает PostgreSQL. Это связано с тем, что MS SQL снабжен эффективными механизмами динамического автотюнинга. Он сразу забирает под свои нужды всю доступную оперативную память сервера, оптимизирует планы выполнения и распределяет нагрузку по ядрам.
Дефолтные настройки PostgreSQL, напротив, рассчитаны на то, чтобы запуститься на любом слабом компьютере (например, параметр shared_buffers по умолчанию может быть равен всего 128 МБ). Без ручной конфигурации файлов настроек PostgreSQL на больших базах 1С мгновенно уйдет в глубокие тормоза (так называемые секвенциальные сканирования таблиц — Seq Scan вместо Index Scan).
Кроме того, СУБД существенно отличаются по типу управления транзакциями:
Выясним, какие параметры конфигурационного файла postgresql.conf необходимо изменить в обязательном порядке для обеспечения максимальной скорости работы 1С. Рассмотрим рабочий пример настройки сервера с 16 ГБ оперативной памяти и 4-ядерным процессором:
# Оптимальные параметры postgresql.conf для 1С (на базе 16GB RAM)
listen_addresses = '*'
max_connections = 150
shared_buffers = 4GB # 25% от общего объема ОЗУ
temp_buffers = 128MB # Память под временные таблицы одной сессии
work_mem = 64MB # Лимит памяти на одну операцию сортировки/соединения
maintenance_work_mem = 512MB # Память для создания индексов и VACUUM
effective_cache_size = 12GB # ~75% от всей доступной ОЗУ (ориентир для планировщика)
# Обязательные специфические настройки под платформу 1С:Предприятие
escape_string_warning = off
standard_conforming_strings = off
row_security = off
# Настройки автовакуума (критично для предотвращения деградации базы)
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
Разберем подробнее наиболее важные переменные:
shared_buffers — объем оперативной памяти, выделяемый СУБД для кэширования данных. Оптимальное значение для серверов под управлением PostgreSQL — 25% от физической памяти. Превышать этот порог не рекомендуется, так как остальная память должна оставаться под кэш самой операционной системы Linux.work_mem — лимит памяти для выполнения сложных выборок, группировок и сортировок в рамках одного запроса. Если запросу не хватает этого объема, он начинает сбрасывать временные данные на медленный диск, что парализует производительность. Для 1С оптимально выставлять от 32 до 128 МБ.autovacuum — важнейшая служба очистки. Поскольку PostgreSQL является версионником, при каждом изменении или удалении записи физически создается новая строка, а старая помечается как «мертвая». Если служба autovacuum отключена или настроена некорректно, база быстро раздувается (происходит bloat таблиц и индексов), а скорость поиска снижается в десятки раз. Рекомендуется снизить коэффициенты запуска очистки (scale_factor), чтобы автовакуум срабатывал чаще, но обрабатывал меньшие объемы данных за один проход.В плане администрирования бэкапов MS SQL предоставляет удобный механизм разностного копирования и архивации журнала транзакций непосредственно через графическую консоль SSMS (SQL Server Management Studio). Это позволяет настроить Point-in-Time Recovery (восстановление на любой момент времени в прошлом) для каждой базы индивидуально.
В PostgreSQL штатная утилита pg_dump выгружает базу в виде логического бэкапа (последовательность SQL-команд или специальный сжатый формат). Логический бэкап хорош для небольших баз, так как позволяет легко развернуть его на любой платформе или быстро извлечь конкретную таблицу. Однако для терабайтных баз процесс выгрузки через pg_dump становится слишком медленным.
Чтобы ускорить процесс создания логической копии, мы можем запустить pg_dump в многопоточном режиме без сжатия (параметр -Z 0 отключает сжатие во время выгрузки, перенося эту задачу на более поздний этап или другие диски):
# Пример быстрого многопоточного резервного копирования базы в 4 потока
pg_dump -h localhost -U postgres -d trade_db -Fd -j 4 -Z 0 -f /mnt/backups/trade_db_backup
Для восстановления такой резервной копии используется утилита pg_restore, также поддерживающая параллельные потоки:
# Пример параллельного восстановления базы данных из каталога
pg_restore -h localhost -U postgres -d trade_db_new -j 4 /mnt/backups/trade_db_backup
Если вам требуется профессиональное резервное копирование корпоративного уровня для больших баз данных, рекомендуется использовать утилиту pg_probackup. Она позволяет:
Рассмотрим проблемы, с которыми сталкиваются разработчики и администраторы при переносе старых или сильно кастомизированных конфигураций 1С (таких как УПП 1.3 или КА 1.1) на PostgreSQL.
Одна из частых проблем — падение процесса резервного копирования или реиндексации из-за нехватки памяти при обработке системной таблицы configsave или таблиц, хранящих двоичные данные (хранилища конфигурации, присоединенные файлы). Если в базе долгое время велась разработка с сохранением конфигурации поставщика, эти таблицы разрастаются до огромных размеров.
Решение проблемы для УПП / КА: Постарайтесь очистить базу от неиспользуемых старых конфигураций поставщика. В продуктивной базе крайне не рекомендуется держать включенной возможность изменений с сохранением поддержки непосредственно в рабочей СУБД. Оптимальный сценарий обновления:
.cf.Также разработчикам полезно знать, как быстро получить информацию о количестве записей в крупных таблицах СУБД PostgreSQL. Обычный запрос SELECT count(*) в версионных базах данных вынуждает СУБД производить полное сканирование таблицы (Seq Scan), что на таблицах в десятки миллионов строк занимает длительное время. Мы можем использовать системные каталоги для мгновенного получения приблизительного (оценочного) количества строк:
-- Мгновенное получение оценочного количества строк в таблице из системного каталога
SELECT reltuples::bigint AS estimate_rows
FROM pg_class
WHERE oid = 'public._accumregtotals1234'::regclass;
Этот запрос отрабатывает за миллисекунды, так как берет данные из статистики планировщика, обновляемой при проведении регламентных процедур ANALYZE и VACUUM.
Если вы приняли решение о переходе на PostgreSQL, спланируйте процесс миграции по следующим шагам:
postgresql.conf согласно рекомендациям ИТС и характеристикам вашего сервера..dt. На новом сервере PostgreSQL создайте пустую базу данных через консоль администрирования серверов 1С и загрузите в нее полученный .dt-файл. На базах объемом свыше 100 ГБ стандартный механизм выгрузки-загрузки через .dt может работать нестабильно. В таких случаях используют сторонние конвертеры баз данных или инструменты миграции СУБД.ANALYZE). Это необходимо, чтобы планировщик СУБД построил верные карты распределения данных и не строил неоптимальные планы для первых запросов пользователей.cron в Linux). Создайте скрипты для ежедневного проведения VACUUM ANALYZE и еженедельного REINDEX наиболее загруженных таблиц.Соблюдение этих правил гарантирует стабильную, надежную и быструю работу вашей системы автоматизации на базе СУБД PostgreSQL без лишних затрат на лицензирование зарубежного программного обеспечения.