Почему PostgreSQL работает медленнее MS SQL в связке с 1С и как решить проблему производительности с помощью реструктуризации

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Переход с MS SQL Server на PostgreSQL — это актуальная задача для многих системных администраторов и разработчиков 1С в условиях импортозамещения. Однако часто после миграции специалисты сталкиваются с неприятным сюрпризом: типовые операции, которые в MS SQL выполнялись мгновенно, начинают «тормозить», а замеры производительности показывают замедление в десятки и сотни раз. Рассмотрим конкретный кейс, где выборка табличной части документа выполнялась за 710 мс на PostgreSQL против практически мгновенного выполнения на MS SQL, и выясним, как реструктуризация базы данных позволяет ускорить работу системы в 7000 раз.

Анализ проблемы производительности

Проанализируем ситуацию: при вызове метода ПолучитьОбъект() для документа «Больничный лист» (БЛ) планировщик запросов PostgreSQL тратил аномально много времени на выполнение простейшей выборки. Разберем конкретные цифры замеров:

Такая колоссальная разница в производительности (более чем в 7000 раз) при одинаковых данных и идентичном тексте запроса указывает на то, что проблема кроется не в коде 1С, а во внутреннем состоянии таблиц СУБД и неоптимальности планов запросов. Проанализируем, почему стандартные средства переноса данных, такие как ibcmd или загрузка из .dt, не всегда гарантируют высокую скорость «из коробки».

Роль реструктуризации информационной базы

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

  1. Борьба с раздуванием таблиц (Bloat): В отличие от MS SQL, PostgreSQL использует механизм MVCC. При обновлении строк старые версии данных помечаются как «мертвые кортежи» и продолжают занимать место до тех пор, пока их не вычистит процесс VACUUM. Реструктуризация полностью пересоздает файлы таблиц, устраняя фрагментацию и «мусор».
  2. Обновление статистики планировщика: Планировщик PostgreSQL (Query Planner) строит путь выполнения запроса на основе статистики о распределении данных. После массового переноса данных из MS SQL через репликацию или утилиты импорта, статистика часто оказывается неактуальной. Реструктуризация инициирует сбор свежих данных, что позволяет СУБД выбрать правильный индекс.
  3. Физическое упорядочивание: Запись данных в новые таблицы при реструктуризации происходит последовательно. Это обеспечивает более плотное размещение данных на диске, что ускоряет операции чтения.

Сравнение методов переноса данных

Рассмотрим опыт использования различных инструментов миграции. Использование репликации (например, через ibcmd) позволяет быстро перенести данные, но, как показывает практика, состояние индексов и таблиц после такой процедуры может быть далеко не оптимальным. Проанализируем результаты теста обработки 177 документов «Больничный лист»:

Для сравнения, в MS SQL аналогичный показатель составлял около 26 док./сек. Таким образом, правильно настроенный и «причесанный» PostgreSQL может даже превосходить MS SQL по производительности в определенных сценариях 1С.

Технические нюансы оптимизации PostgreSQL под 1С

Чтобы закрепить результат реструктуризации и избежать деградации производительности в будущем, разберем ключевые настройки сервера PostgreSQL, которые критичны для работы платформы 1С. Если оставить параметры по умолчанию, даже реструктуризация может не дать долгосрочного эффекта.

Параметр shared_buffers: Этот параметр определяет объем оперативной памяти, используемый PostgreSQL для кэширования данных. Для серверов 1С рекомендуется устанавливать его на уровне 25% от общего объема ОЗУ.

Параметр random_page_cost: По умолчанию он настроен на 4.0 (для HDD). Если ваша база работает на SSD, обязательно уменьшите его до 1.1 или 1.0. Это заставит планировщик чаще использовать индексы вместо полного сканирования таблиц.

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

Регламентное обслуживание как замена частой реструктуризации

Посмотрим на вопрос практического применения: нельзя делать реструктуризацию каждый день, так как это требует монопольного доступа и занимает много времени на больших базах. Чтобы поддерживать скорость, полученную после реструктуризации, необходимо настроить регламентные задачи средствами СУБД. Рассмотрим пример скрипта для обслуживания:


-- Выполнение очистки и обновления статистики для всей базы
VACUUM FULL ANALYZE;

-- Если база очень большая, можно ограничиться обычным VACUUM и ANALYZE
VACUUM ANALYZE;

-- Пересоздание индексов для устранения их раздувания
REINDEX DATABASE "имя_вашей_базы";

Важно помнить, что VACUUM FULL и REINDEX блокируют таблицы, поэтому их следует запускать только в технологическое окно. Однако именно они позволяют поддерживать структуру базы в том «идеальном» состоянии, которое достигается методом реструктуризации в 1С.

Выводы и рекомендации

Подводя итог нашему разбору, сформулируем основные шаги при миграции на PostgreSQL для обеспечения максимальной скорости:

  1. Всегда выполняйте полную реструктуризацию информационной базы после первоначальной загрузки данных, каким бы способом они ни были перенесены (из .dt, через ibcmd или сторонние утилиты).
  2. Используйте сборки PostgreSQL, адаптированные для 1С (например, от Postgres Professional или фирменные сборки с портала 1С), так как они содержат важные патчи для планировщика запросов.
  3. Проверяйте актуальность статистики. Если запрос внезапно начал тормозить, первым делом выполните ANALYZE для проблемной таблицы.
  4. Настройте конфигурацию сервера. Особое внимание уделите параметрам памяти и стоимости дисковых операций (random_page_cost).

Реструктуризация — это не просто сервисная функция, а мощный инструмент оптимизации физического уровня хранения данных, который позволяет PostgreSQL работать на равных с коммерческими СУБД в экосистеме 1С.

← На главную