Администрирование · 12 мин
Какой SQL-сервер выбрать для работы с 1С
Какой SQL-сервер выбрать для 1С: сравнение MS SQL, PostgreSQL и файлового режима, критерии выбора, требования к серверу и типичные ошибки при развёртывании.
Платформа 1С:Предприятие умеет хранить базы данных двумя способами: в файловом варианте и в клиент-серверном, где данными управляет внешняя СУБД. Выбор СУБД влияет на производительность, надёжность, стоимость лицензий и требования к обслуживанию, поэтому решать этот вопрос стоит до развёртывания системы, а не после первых проблем с блокировками.
Официально платформа 1С поддерживает четыре СУБД: Microsoft SQL Server, PostgreSQL (включая специальную сборку Postgres Pro), IBM DB2 и Oracle Database. На практике в подавляющем большинстве внедрений используются первые два варианта: MS SQL — как наиболее распространённый и хорошо документированный, PostgreSQL — как бесплатная альтернатива. DB2 и Oracle встречаются редко, в основном в крупных корпорациях, где эти СУБД уже приняты как стандарт.
Файловый режим тоже остаётся рабочим вариантом, но у него есть жёсткие ограничения по количеству одновременно работающих пользователей и устойчивости к сбоям. Ниже разберём, когда достаточно файлового режима, когда нужен SQL-сервер и какой именно.
Какие СУБД поддерживает платформа 1С
Платформа 1С:Предприятие работает с СУБД через собственный слой абстракции: конфигурация не знает, какая база стоит под ней, и один и тот же прикладной код выполняется на любой поддерживаемой СУБД. Тем не менее поведение системы на разных СУБД отличается — по скорости выполнения запросов, механизмам блокировок и требованиям к настройке.
Microsoft SQL Server — исторически основной вариант, на нём тестируется большинство типовых конфигураций, под него написано больше всего инструкций и рекомендаций. PostgreSQL поддерживается через специальные сборки (например, Postgres Pro Standard/Certified), которые адаптированы под особенности платформы 1С; «ванильный» PostgreSQL из официального репозитория для работы с 1С не предназначен.
Когда достаточно файлового режима
Файловый режим подходит для небольших команд: как правило, до 5–10 одновременно работающих пользователей при умеренном объёме данных. Вся база хранится в одном файле в общей сетевой папке или на локальном диске, администрирование практически не требуется, а резервное копирование сводится к копированию файла.
Ограничения файлового режима принципиальны. Запись в файл блокируется целиком, поэтому при росте числа пользователей начинаются взаимные ожидания. Файловая база уязвима к обрывам сети и сбоям питания: прерванная запись может повредить файл, и потребуется восстановление через тестирование и исправление. Кроме того, файловый режим не работает с веб-клиентом в полной мере и не поддерживает часть механизмов платформы, рассчитанных на сервер.
Признак того, что файловый режим пора менять: пользователи жалуются на «зависания» при одновременном проведении документов, база периодически требует восстановления после сбоев, а её размер перевалил за несколько гигабайт.
MS SQL Server: когда это оптимальный выбор
MS SQL Server — стандарт де-факто для 1С в клиент-серверном режиме. Под него существует максимум готовых инструкций, типовые конфигурации тестируются на нём в первую очередь, а найти администратора с опытом связки «1С + MS SQL» заметно проще, чем специалиста по PostgreSQL в контексте 1С.
Для небольших внедрений подходит бесплатная редакция Express: у неё есть ограничения по объёму базы, объёму используемой памяти и числу задействованных ядер процессора, но для компании на 10–20 пользователей с базой умеренного размера их часто достаточно. Когда упираетесь в лимиты редакции, переходят на Standard — это платная лицензия, и её стоимость нужно закладывать в бюджет вместе с лицензиями на саму 1С.
MS SQL хорошо подходит, когда инфраструктура компании уже построена на Windows Server, есть системный администратор с опытом Microsoft-стека и важна предсказуемость: обновления, инструменты мониторинга и резервного копирования здесь стандартизированы.
PostgreSQL: бесплатная альтернатива с оговорками
PostgreSQL позволяет построить клиент-серверную 1С без покупки лицензий на СУБД, что при большом числе пользователей даёт существенную экономию. Для работы с 1С нужна специальная сборка — чаще всего Postgres Pro, распространяемая в том числе через инфраструктуру 1С; обычный PostgreSQL с официального сайта платформа не поддерживает.
Главные оговорки касаются обслуживания. PostgreSQL требует регулярной настройки: параметры памяти, автовакуума и планировщика запросов влияют на производительность 1С сильнее, чем аналогичные настройки в MS SQL. Запросы, сформированные платформой, на двух СУБД могут выполняться с разной скоростью, и иногда на PostgreSQL требуется дополнительная оптимизация конфигурации.
Выбирать PostgreSQL разумно, когда в штате есть (или планируется) специалист, готовый заниматься этой СУБД, либо когда внедрением занимается франчайзи с опытом именно таких развёртываний. Экономия на лицензиях не должна превращаться в регулярные простои из-за некому обслуживаемого сервера.
Сравнение вариантов
До 5–10 пользователей, минимум администрирования. Ограничение: блокировки при одновременной записи, риск повреждения файла при сбоях.
Стандарт для 1С, максимум документации и специалистов. Ограничение: стоимость лицензий Standard-редакции для крупных внедрений.
Бесплатная СУБД, подходит для экономии на лицензиях. Ограничение: требует специальной сборки и квалифицированного сопровождения.
Оправданы, если эти СУБД уже корпоративный стандарт. Ограничение: дорого, мало специалистов именно по связке с 1С.
Критерии выбора: на что смотреть в первую очередь
Первый критерий — число одновременно работающих пользователей и планируемый рост. Если сейчас работают 4 человека, но через год планируется 15, разумнее сразу разворачивать клиент-серверный вариант, чем мигрировать в спешке после первых блокировок.
Второй критерий — бюджет на лицензии и обслуживание. Сравнивать нужно полную стоимость владения: лицензия MS SQL Standard плюс типовое администрирование против бесплатного PostgreSQL плюс более дорогое или внешнее сопровождение. Для компании без собственного ИТ-специалиста MS SQL Express или даже файловый режим часто дешевле в совокупности.
Третий критерий — требования конфигурации. Некоторые решения (например, 1С:Документооборот КОРП, крупные ERP-внедрения) изначально рассчитаны на клиент-серверный режим, и вендор прямо рекомендует конкретные СУБД и их версии. Эти рекомендации стоит проверить в документации к конфигурации до покупки сервера.
Как выбрать действие
Требования к серверу и развёртывание
Для клиент-серверного режима понадобятся два компонента: сервер 1С:Предприятия и сервер СУБД. На небольших внедрениях их часто ставят на одну физическую машину — это допустимо, если ресурсов хватает с запасом; при росте нагрузки СУБД выносят на отдельный сервер.
Ключевой ресурс для базы 1С — оперативная память и быстрые диски. Дисковая подсистема под файлы данных и журнал транзакций должна быть на SSD; размещение базы на медленных HDD — одна из самых частых причин «тормозов», которые ошибочно списывают на платформу. Объём памяти подбирается так, чтобы активная часть базы по возможности помещалась в буфер СУБД.
Обязательно настройте регламентные операции на уровне СУБД: резервное копирование по расписанию, обслуживание индексов и статистики. Резервные копии храните отдельно от сервера базы и периодически проверяйте, что копия реально восстанавливается, — сам факт наличия файла бэкапа ничего не гарантирует.
- 1Определите число пользователей и выберите СУБД по критериям выше
- 2Подготовьте сервер: SSD-диски, достаточный объём оперативной памяти
- 3Установите СУБД и примените рекомендуемые для 1С настройки
- 4Установите сервер 1С:Предприятия той же версии платформы, что и клиенты
- 5Создайте информационную базу через консоль кластера серверов 1С
- 6Загрузите данные из файловой базы через выгрузку/загрузку .dt
- 7Настройте расписание резервного копирования и проверьте восстановление из копии
Типичные ошибки при выборе и настройке
Самая частая ошибка — выбирать СУБД «на вырост» без учёта сопровождения: компания ставит PostgreSQL ради экономии, а через полгода выясняется, что настроить и обслуживать его некому, и база деградирует. Обратная ошибка — покупка дорогих лицензий MS SQL Standard для базы, которая спокойно работала бы на Express.
Вторая группа ошибок касается железа и настроек: размещение базы на медленных дисках, отключённое обслуживание индексов, отсутствие резервного копирования журнала транзакций в MS SQL. Эти проблемы проявляются не сразу, а по мере роста базы, и диагностировать их сложнее, чем предотвратить.
Третья ошибка — миграция с файлового режима на SQL без тестирования. Перенос большой базы через выгрузку .dt может занять часы, и делать это нужно в нерабочее время с предварительной репетицией на копии.
Как проверить, что выбор был правильным
Основной показатель — отсутствие жалоб пользователей на блокировки и скорость при типичной одновременной работе: проведение документов, формирование отчётов, обмены. Если после перехода на SQL типовые операции не ускорились, проблема почти всегда в настройках СУБД или железе, а не в самом выборе сервера.
Технические контрольные точки: резервные копии создаются по расписанию и тестово восстанавливаются, размер журнала транзакций MS SQL не растёт бесконтрольно, на PostgreSQL регламентно выполняется обслуживание. Эти проверки стоит проводить регулярно, а не только после развёртывания.
Как проверить результат
Проведение документов и отчёты выполняются без ощутимых пауз при одновременной работе пользователей
Взаимные блокировки, ожидания на записях, жалобы на «зависания»
Копии создаются по расписанию, тестовое восстановление проходит успешно
Копии не создаются, занимают весь диск или не восстанавливаются
Размер контролируется моделью восстановления и регламентными копиями
Журнал разросся и заполнил диск
Память и диски загружены с запасом в часы пик
Постоянная нехватка памяти, очередь дисковых операций
Что важно запомнить
До 5–10 пользователей достаточно файлового режима. Дальше — клиент-сервер: MS SQL как стандарт с максимумом документации и специалистов, PostgreSQL (Postgres Pro) как бесплатная альтернатива при наличии сопровождения. Производительность определяется не столько выбором СУБД, сколько железом, настройками и регламентным обслуживанием.
Частые вопросы
Можно ли использовать бесплатный MS SQL Express для 1С?
Да, платформа 1С работает с редакцией Express. У неё есть ограничения по размеру базы, объёму используемой памяти и числу задействованных ядер, поэтому она подходит для небольших внедрений. При приближении к лимитам планируйте переход на платную редакцию — сама миграция между редакциями несложная.
Работает ли 1С с обычным PostgreSQL с официального сайта?
Нет. Для работы платформы требуется специальная сборка PostgreSQL — чаще всего Postgres Pro, адаптированная под особенности 1С. Установка стандартного PostgreSQL приведёт к тому, что сервер 1С просто не сможет создать или подключить базу.
Как перенести базу из файлового режима на SQL-сервер?
Стандартный способ — выгрузка базы в файл .dt из конфигуратора и загрузка его в новую клиент-серверную базу. Для больших баз процесс занимает часы, поэтому перенос планируют на нерабочее время и предварительно репетируют на копии, чтобы оценить длительность и проверить результат.
Что выбрать для 1С:Документооборот или ERP?
Для таких конфигураций ориентируйтесь на системные требования и рекомендации в документации к конкретному продукту. Как правило, они рассчитаны на клиент-серверный режим, и вендор указывает поддерживаемые версии СУБД. Отступать от этих рекомендаций без опыта сопровождения подобных систем не стоит.
Можно ли потом сменить СУБД, например с MS SQL на PostgreSQL?
Технически можно: данные переносятся через выгрузку/загрузку .dt, поскольку конфигурация не привязана к конкретной СУБД. На практике смена СУБД — это проект с тестированием производительности: запросы могут выполняться иначе, и часть настроек придётся делать заново. Выбирать СУБД лучше сразу с запасом на перспективу.
Нужен ли отдельный сервер под СУБД?
На небольших внедрениях сервер 1С и СУБД допустимо размещать на одной машине при достаточном запасе памяти и быстрых дисках. При росте числа пользователей и объёма базы СУБД выносят на отдельный сервер — это снижает конкуренцию за ресурсы и упрощает обслуживание.