1С с MS SQL Server на PostgreSQL: первый реальный перевод

После того как 1С официально зафиксировала поддержку PostgreSQL в 8.3, к нам пошли клиенты с одним и тем же запросом: «хотим уйти с MS SQL Server, у вас есть опыт с PostgreSQL - поможете?». Мы разбирали PostgreSQL для Oracle-миграций и настраивали репликацию, но 1С - это отдельный зверь. Первый реальный перевод на небольшой торговой компании: одна база, около 30 пользователей, Управление торговлей 11 на 8.3.

Делимся тем что увидели - без прикрас.

Почему это не такая же миграция СУБД

Когда переводишь обычное приложение с MSSQL на PostgreSQL, ты контролируешь SQL-запросы, схему, индексы. С 1С иначе: схему базы и все запросы генерирует платформа автоматически. Разработчик конфигурации работает на уровне метаданных 1С, а во что это превращается в SQL - видно только через технологический журнал или трассировку запросов.

Это значит, что «оптимизировать запрос» напрямую нельзя - можно только настроить PostgreSQL так, чтобы планировщик сам принял правильное решение, или влиять на структуру через настройки регистров и индексов 1С.

Специфика драйвера 1С для PostgreSQL

1С поставляет собственную сборку PostgreSQL - это не ванильный пакет с postgresql.org, а патченная версия. Официально поддерживается PostgreSQL 9.2.4 в сборке 1С (на момент когда мы работали), а не актуальный 9.4. Это накладывает ограничения: часть улучшений планировщика из 9.3-9.4, которые могли бы помочь, там просто нет.

Установка идёт через RPM-пакеты 1С под Linux (мы разворачивали на CentOS 7) или через инсталлятор на Windows. Под Linux сервер 1С и PostgreSQL живут на одной машине или на разных - оба варианта рабочие, мы выбрали разные хосты.

Соединение платформы с СУБД - через специальный JDBC-подобный слой внутри платформы. Никакого ODBC или psql напрямую: платформа сама управляет пулом соединений и транзакциями.

Настройка postgresql.conf под 1С-нагрузку

Это главное место где можно помочь производительности. 1С создаёт много коротких транзакций, активно использует временные таблицы (для запросов с большими выборками платформа разворачивает промежуточные результаты во временные таблицы), и имеет характерный паттерн: много читающих сессий + несколько пишущих.

Параметры, которые мы трогали:

• shared_buffers - под 1С рекомендуют 25-40% RAM. У нас 16 ГБ на сервере, поставили 4 ГБ. Платформа активно читает одни и те же страницы метаданных - кеш реально помогает.
• work_mem - критичный параметр. 1С-запросы с сортировками и GROUP BY могут уходить на диск при маленьком work_mem. С другой стороны, 30 сессий умножается на значение, и при 64 МБ это уже 1.9 ГБ только на sort. Мы начали с 32 МБ, потом скорректировали до 48 МБ наблюдая за pg_stat_activity.
• effective_cache_size - подсказка планировщику про кеш ОС. Поставили 8 ГБ (половина RAM), что помогло планировщику выбирать index scan вместо seq scan на больших таблицах.
• checkpoint_completion_target = 0.9 - размазываем запись checkpoint по времени, меньше пиков на диске.
• wal_buffers = 16MB - при интенсивной записи (проведение документов в 1С) помогает снизить ожидание WAL.
• random_page_cost - зависит от дисков. У клиента был RAID на SAS, мы снизили до 2.0. На SSD было бы ближе к 1.1.

Параметр escape_string_warning = off - специфика 1С. Платформа генерирует SQL со строками в старом синтаксисе без E-префикса, PostgreSQL по умолчанию кидает warning на каждый такой запрос. Если не отключить - лог превращается в шум.

Проблемы с локализацией

Вот где было потрачено больше всего времени - и это не было очевидно заранее.

Locale при инициализации кластера. PostgreSQL инициализируется с определённой локалью, которая влияет на сортировку строк (collation). 1С требует ru_RU.UTF-8 и конкретный lc_collate. Если кластер инициализирован с C или en_US.UTF-8 - сравнение строк в 1С-запросах даёт неожиданные результаты: сортировка справочников ломается, поиск по наименованию работает не так как ожидает пользователь.

Мы инициализировали кластер командой:

initdb -D /var/lib/pgsql/data --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF-8

Если кластер уже создан с неправильной локалью - пересоздание с dump/restore, другого пути нет.

Системная локаль на сервере. Locale должна быть установлена в ОС: locale -a должна показывать ru_RU.UTF-8. На минимальных CentOS-установках её может не быть - доустанавливается через localedef или langpack.

standard_conforming_strings = off - исторически 1С-платформа ожидала именно это поведение (обратный слеш как escape). В PostgreSQL 9.2 это ещё настраиваемо, выставляем явно.

datestyle = 'ISO' - 1С передаёт даты в определённом формате, лучше зафиксировать явно чтобы не зависеть от дефолтов.

Что по производительности

Честно: сразу после миграции было медленнее. Не катастрофически, но заметно - особенно на тяжёлых отчётах. MSSQL на том же железе строил планы чуть лучше для 1С-паттернов, которые очень любят горизонтальные джоины по многим таблицам.

Несколько итераций настройки work_mem, effective_cache_size и random_page_cost выровняли картину. На OLTP-операциях (проведение документов, интерактивная работа) разница стала несущественной. Тяжёлые управленческие отчёты по-прежнему чуть медленнее - мы рекомендовали запускать их в нерабочее время, что и раньше было разумно.

Где мы сейчас

База в продуктиве на PostgreSQL около трёх недель - без критичных инцидентов. Backup через pg_basebackup в ежедневном режиме, тестовое восстановление прошли. Из открытых вопросов - докручиваем мониторинг: pg_stat_statements подключён, смотрим на топ медленных запросов через технологический журнал 1С в связке с запросами на уровне PostgreSQL.

Если нужна миграция 1С или других учётных систем на PostgreSQL - это часть нашей практики DWH и аналитики.