Работа с многопользовательскими базами

c

Как выбрать СУБД под многопользовательскую нагрузку: пошаговый разбор

На вебинарах по 1С мы часто сталкиваемся с ситуацией, когда компания покупает лицензии на SQL, хотя реально работает 3–5 человек, или наоборот — пытается «разогнать» файловый режим на 20 бухгалтеров. Ниже — пошаговая схема выбора, основанная на замерах реальных проектов.

Шаг 1. Определите фактическое число одновременных сеансов.
— Если до 5–8 пользователей, файловая БД (UDB) при объеме до 2–3 ГБ обычно справляется. Задержка записи — до 0.3–0.5 сек, чтение практически мгновенное.
— При 10–15 пользователях на файловой СУБД растет число блокировок: до 40–60% запросов попадают в ожидание. Время ответа типового документа уходит за 3–5 секунд.
— SQL-сервер (MSSQL/PostgreSQL) становится необходимым при 15+ сеансах, либо при объеме БД свыше 5 ГБ.

Шаг 2. Оцените объемы транзакций и пиковые нагрузки.
В одном из проектов на 12 рабочих мест (торговля склад) средняя транзакция записи — 0.7 сек в SQL, в файле — 2.3 сек. При 200 проводках в день — разница в часах простоя. Замеряйте фактические цифры через монитор производительности 1С.

Шаг 3. Учтите стоимость и квалификацию админа.
— PostgreSQL (Windows/Linux): бесплатно, но требует настройки (shared_buffers, wal_buffers) — типичная экономия в 40–60 тыс. руб. в год против платного MSSQL.
— MSSQL: платная лицензия от 70 тыс. руб., зато «из коробки» считается надежнее для 1С.

Типичная ошибка покупателя: сразу покупать самое дорогое железо, забывая о настройке планов выполнения запросов и индексов. До 30% производительности теряется именно из-за неправильных настроек СУБД, а не из-за слабого процессора.

Управление блокировками в 1С: реальные цифры и последствия «слепых» настроек

На семинарах 2026 года мы разбираем три конкретных кейса перегрузки блокировками.

Кейс 1. «Управляемый» режим блокировок при 20 пользователях.
Внедрили на оптовом складе. Вместо «Авто» поставили принудительный пессимистичный захват строк — 40% времени проводки документов ждали освобождения таблиц. Среднее ожидание блокировки выросло до 4.2 сек. Решение: вернули смешанные блокировки (управляемый режим), время упало до 0.9 сек.

Кейс 2. PostgreSQL — взаимоблокировки из-за дедлоков.
При 18 одновременных документах возврата товара система вставала колом каждые 2 часа. Причина — отсутствие первичных ключей в некоторых таблицах. Добавление ключей и реиндексация снизили deadlock-ситуации с 7 до 0 в день.

Кейс 3. Файловая БД при 8 пользователях: скрытые потери.
Верите или нет, в одной розничной сети 8 человек работали в файле 6 ГБ. Среднее время открытия отчета 1,2 мин, реальные потери времени — 45 часов в месяц. После перехода на SQL-сервер (5 тыс. руб./мес аренда) окупили затраты за 2 недели за счет скорости отчётов.

Совет слушателям наших курсов: перед любыми изменениями снимите срез замеров через штатный монитор 1С (раздел «Тестирование и индексация БД»). Если время ожидания блокировок превышает 0.5 сек при типовом документе — меняйте архитектуру.

Практика настройки разделения прав доступа: пошаговый план с метриками

Многопользовательская база требует тонкого разделения прав не только по соображениям безопасности, но и для снижения избыточных захватов таблиц. Ниже — схема, которую мы даем на интенсивах.

  1. Группировка пользователей по ролям. Не создавайте роль под каждого человека. Для 20–30 человек достаточно 4–5 стандартных ролей (менеджер, бухгалтер, склад, админ, просмотр). На одном из проектов лишние 12 индивидуальных ролей вызвали дублирование прав доступа и рост времени открытия справочника «Номенклатура» с 2 до 8 секунд.
  2. Разделение сеансов на чтение и запись. Если пользователь только смотрит отчеты (аналитик) — отключите для него транзакционные блокировки. В одном кейсе аналитик с правами «редактор» случайно заблокировал таблицу регистров на 20 минут, сорвав закрытие месяца.
  3. Настройка внешних соединений COM и HTTP. Если база используется с веб-клиентом 1С (CRM или документооборот), количество одновременных подключений возрастает в 2–3 раза. В реальном примере с 12 пользователями файлового режима при подключении веб-доступа (3 человека) файл «повис» за 30 минут из-за отсутствия механизма блокировок. SQL-сервер решил проблему на 100%.

Типичная ошибка покупателя курса: полагать, что «бесплатный PostgreSQL» не нуждается в администрировании. По факту, для 20+ пользователей нужен настройщик с сертификатом, а это дополнительные бюджеты от 30 тыс. руб. в месяц. Считайте полную стоимость владения, а не только цену СУБД.

Мониторинг и профилактика рассинхронизации многопользовательской БД

Даже при правильном выборе СУБД база может «зависнуть» из-за накопления ошибок. На курсах мы учим делать регламентные проверки раз в месяц. Вот метрики, которые нужно отслеживать:

В реальном проекте оптового магазина (25 пользователей, MSSQL 2019) ежемесячная реорганизация индексов сократила среднее время отчёта «Продажи по менеджерам» с 55 секунд до 9. Сравните: 0 руб. затрат на новое оборудование, только администрирование.

Важно для слушателей: никогда не запускайте тестирование и исправление ссылочной целостности в рабочее время при активной работе пользователей. Один массовый пересчет итогов (например, закрытие месяца) может заблокировать всех на 2–4 часа, если не запланировать его на ночь или в обед. Планируйте такие процедуры через регламентные задания 1С.

Добавлено: 07.05.2026