Имеет ли смысл переводить базу 1С на толстом клиенте с файлового режима на SQL-сервер?

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

Файловый режим против клиент-серверного: ключевые архитектурные ограничения

Файловая база данных (формат .1CD) отлично справляется с задачами при малом числе пользователей (до 3–5 человек) и скромных объемах. Однако по мере роста нагрузки проявляются фундаментальные ограничения файловой архитектуры:

1. Блокировка на уровне таблиц: В файловом варианте любая операция записи накладывает монопольную блокировку на всю физическую таблицу. Если один пользователь проводит объемный документ, все остальные процессы, обращающиеся к этой же таблице (даже на чтение при определенных условиях), вынуждены ожидать освобождения ресурса. В клиент-серверном варианте СУБД способна блокировать данные гранулярно — на уровне отдельных строк или страниц данных.
2. Предел размера таблиц в 4 ГБ: Внутренняя структура файла базы данных .1CD накладывает жесткое ограничение на максимальный размер одной таблицы и ее индексов (4 ГБ). При общем объеме базы в 5 ГБ крупные таблицы (например, регистры сведений, регистры накопления или журнал регистрации) могут подойти к критическому порогу, что чревато внезапными сбоями транзакций и риском повреждения базы.
3. Сетевой трафик и конкуренция за диск: При работе 10–15 пользователей по сети без терминального сервера файловый режим генерирует колоссальный сетевой трафик, так как выборка и обработка данных происходят на клиентских машинах. Переход на RDP снижает остроту проблемы, но не устраняет дисковые коллизии и табличные блокировки.

Особенности работы толстого клиента в связке с SQL-сервером

Рассмотрим, что происходит с толстым клиентом при переходе на трехзвенную архитектуру (клиент — сервер 1С:Предприятия — СУБД). В обычном приложении исполняемый код форм и модулей объектов выполняется преимущественно в контексте клиентского процесса. Это накладывает определенные особенности на производительность:

1. Накладные расходы на сетевые вызовы: В файловой базе обращение к данным происходит напрямую в памяти локального процесса. В клиент-серверной архитектуре каждый запрос транслируется через кластер 1С к СУБД, а результаты сериализуются и передаются обратно. Если код написан неоптимально (например, содержит обращения через точку к реквизитам ссылок внутри цикла), база на SQL может работать медленнее файловой на простых операциях одиночного пользователя.
2. Использование Shared Memory: Чтобы свести к минимуму сетевые задержки для толстого клиента, сервер 1С, СУБД и сеансы пользователей (при работе через терминальный доступ) рекомендуется размещать на одном физическом сервере или связывать через высокоскоростной локальный протокол Shared Memory.
3. Преимущество при параллельной работе: Главный прирост от перехода на SQL ощущается не в скорости выполнения одного изолированного запроса, а в масштабируемости. При одновременной работе 10–15 пользователей пропадают зависания, вызванные ожиданием снятия блокировок таблиц.

Пошаговый план перехода и оптимизации базы данных

Разберем последовательность шагов, которая позволит максимально эффективно перевести базу на SQL и устранить замедления в работе отчетов и документов.

Шаг 1. Перевод на управляемые блокировки транзакций

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

1. В конфигураторе переведем свойство конфигурации Режим управления блокировкой данных в значение Управляемый (или Автоматический и управляемый для постепенного перевода объектов).
2. В СУБД MS SQL включим версионирование строк (параметры READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION). Это позволит формировать отчеты и читать данные без блокировки транзакций записи.

Шаг 2. Оптимизация исходного кода конфигурации

Выясним причину, почему документы и отчеты начинают замедляться при росте объема. Основная причина — накопление записей в таблицах при наличии алгоритмических ошибок. Проанализируем проблемные места:

1. Устранение запросов в цикле: Перепишем алгоритмы заполнения и проведения так, чтобы данные считывались одним пакетным запросом с помещением во временные таблицы.
2. Исключение неявных разыменований: Исключим обращения через точку от ссылочных полей составного типа (например, Ссылка.Договор.Владелец) внутри циклов и в секциях ГДЕ запросов.
3. Индексация полей: Проверим, что измерения регистров и реквизиты, по которым осуществляются частые отборы и соединения в запросах, имеют установленный признак индексирования.

Шаг 3. Регламентное обслуживание СУБД

При росте таблиц оптимизатор запросов СУБД начинает строить неверные планы выполнения (например, полное сканирование таблицы Index Scan вместо поиска по индексу Index Seek), если статистики устарели. Настроим обязательные регламентные задания в СУБД:

1. Обновление статистик: Настроим регулярный запуск команды UPDATE STATISTICS для всех таблиц базы.
2. Реиндексация и дефрагментация: Настроим перестроение (REBUILD) и реорганизацию (REORGANIZE) индексов во внерабочее время.
3. Настройка базы tempdb: Разместим файлы базы tempdb на быстрых SSD/NVMe накопителях и разделим ее на несколько файлов данных (по числу физических ядер процессора).
4. Ограничение параллелизма: Установим параметр Max Degree of Parallelism (MAXDOP) равным 1, чтобы исключить накладные расходы на распараллеливание простых запросов платформы 1С.

Шаг 4. Мониторинг и локализация узких мест

Для объективной оценки производительности используем встроенные и системные инструменты анализа:

1. Технологический журнал (ТЖ): Настроим сбор событий TLOCKS (ожидания блокировок), TDEADLOCK (взаимоблокировки) и SDBL (длительные запросы к СУБД с порогом выполнения от 3–5 секунд). Это позволит точно выявить медленные участки кода без субъективных оценок.
2. Оценка производительности (методика APDEX): Внедрим замеры ключевых операций (время проведения документа, время формирования тяжелого отчета), чтобы наглядно зафиксировать динамику быстродействия до и после переноса базы.

Вывод

Перевод самописной базы на толстом клиенте объемом от 5 ГБ с числом активных пользователей 10–15 человек на SQL-сервер однозначно целесообразен. Переход снимет жесткие лимиты на размер таблиц, обеспечит высокую надежность хранения данных и устранит блокировки на уровне файлов. Однако максимальный прирост скорости достигается только в комплексе с включением управляемых блокировок, регулярным обслуживанием СУБД и оптимизацией тяжелых запросов в коде конфигурации.