← На главную

Вопрос выбора версии СУБД для сервера 1С всегда вызывает живые дискуссии. Многие придерживаются правила «работает — не трогай», однако в случае с PostgreSQL 9.6 ситуация требует более детального анализа. Рассмотрим, почему простого «нормального функционирования» старой версии недостаточно для современного предприятия и какие технические преимущества мы получим при переходе на версии 11 или 12.

Анализ жизненного цикла программного обеспечения (EOL)

Первое, что мы должны проанализировать — это официальный статус версии. PostgreSQL 9.6 официально достигла стадии End of Life (EOL) еще в конце 2021 года. Разберем, что это означает на практике для администратора 1С:

1. Отсутствие исправлений безопасности: Любые новые уязвимости, найденные в ядре СУБД, в версии 9.6 исправляться не будут. Если база данных доступна в сети, это создает прямой риск для конфиденциальности данных 1С.
2. Проблемы совместимости: Новые релизы платформы 1С (например, ветки 8.3.23 и выше) ориентируются на возможности современных СУБД. Оставаясь на 9.6, мы закрываем себе путь к обновлению самой платформы 1С без сложной миграции базы в будущем.

Оптимизация индексов и работа с дисковой подсистемой

Выясним, как обновление влияет на производительность. Одним из самых значимых изменений в PostgreSQL 12 стала глубокая переработка B-tree индексов. Проанализируем, почему это критично для 1С:

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

• Уменьшение размера базы: Индексы могут занимать на 20-40% меньше места на диске по сравнению с версией 9.6.
• Ускорение операций записи: Меньший объем перестраиваемых индексов означает меньшую нагрузку на дисковую подсистему при проведении документов.

Параллельное выполнение запросов в 1С

Разберем один из самых важных механизмов ускорения работы — параллелизм. В версии 9.6 возможности параллельного выполнения запросов были зачаточными. Начиная с 10-й и особенно в 11-12 версиях, PostgreSQL научился задействовать несколько ядер процессора для выполнения одного тяжелого SQL-запроса.

Посмотрим, на что это влияет в контексте 1С:

1. Тяжелые отчеты: Если пользователь формирует сложный аналитический отчет (например, по оборотам за несколько лет), СУБД может запустить Parallel Sequential Scan или Parallel Hash Join, распределив нагрузку между свободными ядрами.
2. Создание индексов: Операция CREATE INDEX стала параллельной, что существенно сокращает время обслуживания базы данных (реиндексации).

Усовершенствование механизма Autovacuum

Проблема «мусора» (мертвых кортежей) в PostgreSQL — это вечная головная боль администраторов. Платформа 1С постоянно создает, изменяет и удаляет записи (особенно во временных таблицах). В новых версиях механизм Autovacuum был существенно оптимизирован.

Проанализируем ситуацию: в версии 9.6 очистка могла не успевать за интенсивной записью в 1С, что приводило к деградации производительности. В версиях 11 и 12 алгоритмы стали более агрессивными и интеллектуальными, что минимизирует вероятность блокировок процессов очистки и снижает нагрузку на CPU во время работы вакуума.

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

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

1С активно использует Temporary Tables для выполнения сложных запросов. В старых версиях PostgreSQL создание большого количества временных таблиц могло вызывать перегрузку системных каталогов. В новых версиях (особенно в сборках от 1С и Postgres Pro) эта проблема решена более эффективно. Также улучшена работа с блокировками, что снижает частоту возникновения ошибок deadlock при одновременной работе большого количества пользователей.

Внедрение JIT-компиляции

Начиная с 11-й версии в PostgreSQL появилась поддержка Just-In-Time (JIT) компиляции запросов. Рассмотрим, стоит ли её использовать:

JIT позволяет компилировать части SQL-запросов в машинный код «на лету». Для очень длинных и сложных запросов в 1С это может дать прирост скорости до 15-25%. Однако стоит помнить, что на коротких запросах JIT может внести накладные расходы. В новых версиях планировщик стал лучше определять, когда JIT действительно необходим.

Совместимость с платформой 1С 8.3.15

Автор указал версию платформы 8.3.15.1830. Это важный момент. Хотя эта платформа поддерживает PostgreSQL 11 и 12, необходимо учитывать следующее:

• Стабильность: Версии PostgreSQL 11 и 12 на данный момент являются максимально «вылизанными» и стабильными.
• Плавный переход: Прямой переход с 9.6 на актуальную 15-ю или 16-ю версию может быть болезненным из-за слишком большого разрыва в технологиях. Обновление до 12-й версии — это идеальный промежуточный этап, обеспечивающий современную производительность при сохранении предсказуемости.

Рекомендации по процессу обновления

Если мы приняли решение об обновлении, разберем шаги, которые необходимо предпринять:

1. Резервное копирование: Обязательно создаем полный дамп базы данных с помощью pg_dump или делаем копию на уровне файловой системы (с остановкой службы).
2. Обновление через выгрузку/загрузку: Поскольку форматы хранения данных в 9.6 и 12 версиях различаются, самым надежным способом является выгрузка базы в .dt файл и загрузка его в новую пустую базу на PostgreSQL 12.
3. Тестирование: Проверим выполнение ключевых операций (проведение документов, закрытие месяца) на копии базы перед обновлением рабочей среды.
4. Настройка конфигурации: После обновления не забудем подкорректировать файл postgresql.conf, учитывая новые параметры, такие как jit, max_parallel_workers_per_gather и обновленные значения maintenance_work_mem.

Резюме: Обновление с PostgreSQL 9.6 до 12.1C является крайне оправданным. Мы получаем не только исправление ошибок, но и реальный прирост скорости за счет оптимизации индексов, внедрения параллелизма и лучшей работы с временными таблицами, что критически важно для высоконагруженных систем на базе 1С:Предприятие.