1С и СУБД: PostgreSQL 9.6/10 против MS SQL 2016 - батл, нагрузочное тестирование, DT и УПП

Для 1С:Предприятие 8.3 выбор между PostgreSQL и MS SQL редко решают слухами с форумов - нужны батл и нагрузочное тестирование. Ниже разобрано сравнение PostgreSQL 9.6 и 10 с MS SQL Server 2016 на одном железе под Windows: загрузка DT и тяжёлая операция типовой УПП. Приведены условия прогона, цифры по DT, контекст промышленного контура на Linux и то, что смотреть в технологическом журнале и счётчиках СУБД, если захотите повторить методику.

Зачем снова сравнивать PostgreSQL и MS SQL

MS SQL долго оставался привычной СУБД для установок 1С: лицензии понятны, админы обучены, типовые конфигурации проходят регрессию под эту связку. PostgreSQL в экосистеме 1С вырос из экономики масштаба: сотни информационных баз, терабайты данных, резервные копии с реплик, поднятие тестовой базы без отдельного полного файла бэкапа. После перевода сотен баз на PostgreSQL под Linux легко переоценить субъективный комфорт и недооценить разрыв в отдельных сценариях.

Батл задуман как контрольный эксперимент: один релиз платформы, одно железо, одинаково ограниченный параллелизм на обеих СУБД, чтобы отделить свойства движка от привычки. Экономику и стоимость владения в статье в цифрах не моделируем, но именно они толкают к PostgreSQL; батл отвечает на другой вопрос - где MS SQL всё ещё быстрее при равных настройках.

Production-опыт: Windows, Linux и репликации

Старт внедрения шёл через PostgreSQL на Windows: порядка пяти баз суммарно около 100 ГБ. Такой шаг снижает риск одновременной смены СУБД и ОС, но не повторяет целевую архитектуру 2020R09;х. На Windows всплыла проблема файлов статистики PostgreSQL: сервер часто переименовывает служебный файл статистики, а NTFS блокирует rename, пока файл читают. СУБД переходит на устаревшую статистику, а транзакции периодически замирают примерно на 15 секунд. Симптомы воспроизводились до эскалации в Postgres Pro и подтверждения дефекта со стороны вендора.

Дальнейший рост ушёл на Linux: сейчас в контуре более 400 баз, около 15 ТБ данных, у мастеров есть реплики (в том числе каскадные и несколько реплик на один master). Резервное копирование снимают с standby; восстановление рабочей базы в тест или базу разработчиков выполняют без создания отдельного полного файла бэкапа, с сохранением транзакционной целостности. Для продуктива PostgreSQL с 1С на Windows сегодня трактуют как legacy или временный мост; сравнение на Windows Server 2012 R2 в батле - лабораторная площадка, а не рекомендуемый эталон размещения.

Репликация и backup в современном контуре строятся на штатных средствах экосистемы: физический базовый backup через pg_basebackup, инкрементные схемы через pg_probackup (по документации выбранного дистрибутива Postgres Pro или патчированного PostgreSQL от 1С). Политика восстановления должна совпадать с регламентом 1С: время простоя, точка восстановления, отдельная проверка загрузки DT и тяжёлых регламентных операций после restore.

Правила батла: платформа, железо, версии

Площадка: одно железо, Windows Server 2012 R2 для обеих СУБД, чтобы Linux-оптимизации PostgreSQL не искажали сравнение. Версии: MS SQL Server 2016; PostgreSQL 9.6 и отдельный прогон на ветке 10. Платформа 1С - актуальный релиз на момент теста, профиль настроек ориентирован на многопользовательскую нагрузку (буферы, лимиты соединений, autovacuum, checkpoint). Параллелизм намеренно сведён к единичным значениям на обеих сторонах (для MS SQL - MAXDOP 1; для PostgreSQL отключены параллельные worker-ы там, где это зеркалирует политику SQL), иначе различие в планах запросов смешает эффект СУБД и эффект степени параллелизма.

Перед промышленным выбором сверьте матрицу поддержки платформы с выбранным релизом 8.3. На странице «СУБД» системных требований 1С (v8.1c.ru) для x86-64 перечислены PostgreSQL с патчем от 1С линий 14.23–18.4, Postgres Pro 1С/Standard/Enterprise/CERT соответствующих мажоров, Tantor SE 1C; MS SQL Server 2016, 2017, 2019, 2022 (версия SQL на Linux допустима при рабочих серверах 1С на Windows). Батл на 9.6/10 и SQL 2016 остаётся исторически валидным, но новый проект планируют под версии из актуального списка, а не под снятые с поддержки комбинации.

Рекомендуемые ориентиры по PostgreSQL для 1С из отраслевых и вендорских материалов согласуются с многобазовым контуром: shared_buffers порядка 25% RAM (с верхней оговоркой для очень больших серверов), work_mem умеренно и с учётом числа одновременных сортировок, предсказуемый autovacuum для таблиц 1С, checkpoint_timeout и max_wal_size под дисковую подсистему, max_connections с запасом под пул 1С, но без тысяч idle-сессий. На Linux дополнительно выносят WAL и данные на разные тома, отключают лишние службы и держат statistics collector в RAM там, где это предписано дистрибутивом после инцидентов на Windows.

Чтобы методику можно было повторить, до старта прогона фиксируют согласованный набор KPI.

Схема 1: KPI батла: DT, объём базы, длительность, параллелизм

Единый перечень условий снижает риск сравнения «SQL на SSD» с «Postgres на SATA».

Раунд 1: загрузка большого DT в пустую базу

Сценарий: загрузка DT объёмом более 40 ГБ в пустую базу; после завершения операции итоговый размер базы порядка 2 ТБ. Это проверка не только диска, но и сервера 1С, сетевого пути к файлу DT и параметров выгрузки/загрузки. Большие DT возможны, если заранее выделить ресурсы под временные файлы, каталоги log и каталоги СУБД.

Итог раунда: MS SQL Server 2016 примерно в два раза быстрее PostgreSQL 9.6/10 при описанных настройках. По порядку длительности MS SQL укладывался примерно в сутки, PostgreSQL - около двух суток. Разница не отменяет использования PostgreSQL в продуктиве, но задаёт ожидания по окну обслуживания при полной перезаливке DT.

На форумах периодически советуют отключать fsync или ослаблять durability ради скорости загрузки. Выигрыш небольшой, цена - риск полной потери данных при сбое питания или kernel panic. Корректный ответ - быстрые диски (NVMe/SSD, отдельные тома под data и WAL), достаточный RAM под буферы и контроль autovacuum после загрузки, а не отключение гарантий записи.

Доминирующее время в PostgreSQL уходит на CREATE INDEX при развороте структуры из DT; MS SQL на том же железе строит индексы заметно быстрее. В PostgreSQL 12 и новее появились оптимизации построения индексов (в ряде сценариев меньше полной перезаписи таблицы); к раунду на 9.6/10 это относится как перспектива миграции версии, без пересчёта старых цифр.

Наглядно сопоставляются порядки длительности DT-прогона на одной площадке.

Раунд 2: тяжёлая операция УПП (партионный учёт)

Второй раунд ближе к повседневной эксплуатации: на типовой «1С:Управление производственным предприятием» запускают восстановление последовательности партионного учёта управленческих партий (штатная обработка конфигурации, типовой код, данные из исходного батла). Считают время от старта до завершения на MS SQL 2016 и на PostgreSQL в идентичных условиях, параллельно смотрят блокировки и I/O.

Методика для администратора 8.3: включить LOG с фильтром по длительности операций (события с высокой duration, контекст SDBL/DBPOSTGRS или DBMSSQL в зависимости от СУБД), параллельно снять счётчики waits и disk latency на стороне SQL Server (DMV sys.dm_os_wait_stats, sys.dm_io_virtual_file_stats) и на PostgreSQL (pg_stat_activity, pg_stat_database, pg_stat_user_tables). Сравнивают связку «длительность на стороне 1С, ожидания СУБД, диск».

Числовые итоги второго раунда (соотношение MS SQL и PostgreSQL на той же базе УПП) в этой редакции не дублируются: их нужно брать из полной публикации исходного батла вместе с графиками. Здесь зафиксирован только сценарий и способ проверки, чтобы не подменять первоисточник выдуманными процентами.

Итоги сравнения и выбор СУБД

PostgreSQL при корректном размещении на Linux, настройке и схеме репликации масштабируется до сотен баз 1С и больших объёмов данных; батл не опровергает этот опыт, он уточняет цену отдельных операций. MS SQL 2016 на равной Windows-площадке выигрывает тяжёлую загрузку DT примерно вдвое по времени; PostgreSQL остаётся практичной альтернативой, если окна обслуживания и регламент DT согласованы с бизнесом и не опираются на опасный «тюнинг» durability.

MS SQL разумнее, когда критичны частые полные перезаливки DT, команда уже стандартизировала RCSI/tempdb/MAXDOP под 1С, а бюджет лицензий принят. PostgreSQL разумен при большом числе баз, репликации для backup, экономии лицензий SQL и готовности админов поддерживать Linux-контур; перед миграцией прогоняют оба раунда батла на своём железе и релизе 8.3 из актуальной матрицы поддержки.

Перед решением проверьте: время DT на холодной базе; тяжёлую регламентную операцию вашей конфигурации (аналог раунда УПП); восстановление из backup/replica в тест; поведение autovacuum после массовых загрузок. Сравнение на Windows в статье - эталон честности версий, а не целевая архитектура; продуктив PostgreSQL с 1С планируют на Linux и версии PostgreSQL/Postgres Pro из системных требований платформы.

Запросы и параметры для своих прогонов

# фрагмент postgresql.conf (ориентиры, значения под RAM и диск подбирают отдельно)
shared_buffers = 8GB
work_mem = 64MB
maintenance_work_mem = 2GB
max_connections = 200
checkpoint_timeout = 15min
max_wal_size = 4GB
autovacuum = on
autovacuum_max_workers = 6

# базовый физический backup с реплики (пример)
pg_basebackup -h standby-host -U replication -D /var/lib/pgsql/restore/base -Fp -Xs -P

# активные запросы и ожидания PostgreSQL
psql -c "SELECT pid, state, wait_event_type, wait_event, query_start, left(query,120) FROM pg_stat_activity WHERE datname = current_database();"

# снимок I/O по файлам MS SQL (в SSMS)
SELECT DB_NAME(database_id) AS db, file_id, num_of_reads, num_of_writes, io_stall_read_ms, io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL);