Выбор системы управления базами данных (СУБД) — это один из самых ответственных этапов при развертывании инфраструктуры 1С:Предприятие. В среде специалистов не утихают споры: стоит ли переплачивать за стабильность и простоту MS SQL Server или же отдать предпочтение свободному, но требовательному к настройке PostgreSQL. В этой статье мы подробно проанализируем обе системы, разберем их сильные и слабые стороны, а также выясним, в каких ситуациях одна СУБД будет работать эффективнее другой.
Проанализируем ситуацию, сложившуюся на рынке. Исторически MS SQL Server считался стандартом де-факто для 1С. Основной аргумент в его пользу — минимальный порог вхождения. Как отмечают опытные администраторы, эта СУБД требует "меньше геморроя" при первоначальной установке. Большинство параметров оптимизировано производителем "из коробки", а графический интерфейс SQL Server Management Studio (SSMS) позволяет выполнять регламентные операции даже специалисту с базовыми знаниями.
С другой стороны, мы имеем PostgreSQL. Это мощный инструмент с открытым исходным кодом. Однако важно понимать, что для работы с 1С нельзя просто скачать стандартный дистрибутив с официального сайта. Разберем, почему это так. Фирма 1С использует специфические механизмы взаимодействия с базой данных, поэтому для корректной работы требуются патчи. Рассмотрим основные варианты сборок:
Основной вывод, который мы можем сделать: PostgreSQL может работать не хуже конкурента (с разницей в производительности всего 3-5%), но только при условии грамотного администрирования. Если в штате нет специалиста, способного тонко настроить конфигурационные файлы, выбор в пользу MS SQL будет более оправданным.
Выясним причину, по которой на форумах часто жалуются на "тормоза" в PostgreSQL при проведении документов. Проблема кроется не в самой СУБД, а в том, как 1С генерирует запросы. Платформа 1С активно использует временные таблицы. Рассмотрим пример типичного кода, который создает нагрузку на движок СУБД:
// Пример запроса с использованием временной таблицы
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Ссылка КАК Товар
|ПОМЕСТИТЬ ВТ_Товары
|ИЗ
| Справочник.Номенклатура КАК Номенклатура;
|
|ВЫБРАТЬ
| ВТ_Товары.Товар,
| Остатки.КоличествоОстаток
|ИЗ
| ВТ_Товары КАК ВТ_Товары
|ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки
|ПО ВТ_Товары.Товар = Остатки.Номенклатура";
Результат = Запрос.Выполнить();
В MS SQL Server работа с такими объектами оптимизирована через системную базу tempdb. В PostgreSQL же создание и удаление множества временных таблиц в короткий промежуток времени может привести к "раздуванию" (bloat) системного каталога. Чтобы избежать деградации производительности, мы должны уделить особое внимание настройке фонового процесса autovacuum. Если этот процесс не успевает очищать метаданные, запросы начинают выполняться значительно дольше.
Проанализируем работу оптимизаторов. MS SQL обладает крайне продвинутым планировщиком, который часто "прощает" разработчику неоптимально написанный программный код. PostgreSQL в этом плане более чувствителен. Для него критически важна актуальность статистики. Если статистика по индексам и таблицам устарела, Postgres может выбрать неэффективный план выполнения (например, Sequential Scan вместо Index Scan), что приведет к жалобам пользователей на медленную работу системы.
Разберем, как с этим бороться. В планах обслуживания для PostgreSQL необходимо настроить более агрессивный сбор статистики и регулярный анализ таблиц (ANALYZE). В MS SQL эти процессы также важны, но автоматика там работает более предсказуемо для новичка.
Рассмотрим вопрос конкурентного доступа. В PostgreSQL реализован механизм MVCC (многоверсионность). Это означает, что читающие пользователи не блокируют записывающих. На первый взгляд это звучит как преимущество, однако при массовом проведении документов в 1С (интенсивная запись в одни и те же таблицы регистров) могут возникать специфические взаимоблокировки (deadlocks). В MS SQL механизм блокировок работает иначе, и он десятилетиями оттачивался именно под нужды 1С, что делает его более стабильным "из коробки" в высоконагруженных системах.
Посмотрим на ситуацию с точки зрения бюджета и операционных систем:
Важно помнить, что PostgreSQL крайне требователен к показателям IOPS (количеству операций ввода-вывода в секунду). На медленных жестких дисках разрыв в производительности между MS SQL и Postgres будет колоссальным не в пользу последнего. Если вы планируете использовать свободную СУБД, обязательно обеспечьте сервер быстрыми NVMe накопителями. Это нивелирует большинство проблем с быстродействием файловой системы.
Подводя итог нашему анализу, сформулируем рекомендации для выбора:
postgresql.conf и мониторингом производительности.Помните пример с 1С:Fresh: огромный облачный сервис работает на PostgreSQL, что доказывает — при правильных руках и настройке эта СУБД способна выдерживать колоссальные нагрузки, не уступая платным аналогам.