Где и как 1С хранит данные: файловый режим, SQL-серверы и скорость работы

1С Предприятие не хранит данные само по себе: у платформы нет «своей» СУБД в привычном смысле. Она работает как прослойка. Вы видите справочники и документы, а платформа переводит их в таблицы реальной базы данных. В файловом режиме это файл 1Cv8.1CD с собственным форматом. В клиент-серверном режиме это MS SQL Server, PostgreSQL и другие серверные СУБД.

Выбор режима определяет всё: сколько пользователей работает без тормозов, как делать копии и что чинить при сбое. Ниже — как это устроено внутри и как выбрать режим под вашу нагрузку.

Как платформа превращает объекты 1С в таблицы

Разработчик конфигурации описывает объекты метаданных: справочник «Контрагенты», документ «Поступление товаров», регистр накопления. Платформа на их основе сама создаёт структуру хранения. Вручную таблицы никто не проектирует.

Что получается на выходе:

• 📦 справочнику соответствует одна таблица, табличные части — отдельные таблицы;
• 📄 у документа своя таблица шапки и по таблице на каждую табличную часть;
• 📊 регистр накопления даёт таблицу движений и таблицы итогов;
• 🔧 служебные таблицы хранят саму конфигурацию, настройки и версии структуры.

Имена таблиц в базе служебные, вроде _Reference123 или _Document45. Прикладной разработчик их не видит и работает через объектную модель и язык запросов 1С. Соответствие имён можно посмотреть в консоли запросов или через метод ПолучитьСтруктуруХраненияБазыДанных().

Три слоя: клиент, сервер приложений, СУБД

В клиент-серверной схеме работают три слоя:

1. Клиент — тонкий или веб-клиент, рисует формы и отправляет вызовы.
2. Кластер серверов 1С — процессы ragent, rmngr и rphost. Агент управляет кластером, менеджер распределяет сессии, рабочие процессы выполняют серверный код и ходят в СУБД.
3. Сервер СУБД — хранит таблицы и выполняет запросы.

В файловом режиме слоёв два: клиент и файл. Серверной логики нет, каждый клиент сам читает и пишет в 1Cv8.1CD по сети или с локального диска.

Файловая база: что внутри и где она упирается в предел

Файловая информационная база — это каталог с файлом 1Cv8.1CD и служебными файлами. Формат закрытый, универсальных сторонних инструментов для чтения нет. Доступа «через SQL» тут не бывает.

Сильные стороны:

• ✅ ставится за минуту, администратор не нужен;
• ✅ копия — просто копирование каталога при закрытых сеансах;
• ✅ не нужны лицензии на СУБД и отдельный сервер.

Слабые стороны:

• ⚠️ все клиенты работают с файлом напрямую, нагрузка ложится на сетевой диск и сеть;
• ⚠️ блокировки грубее: при записи страдает параллельная работа;
• ⚠️ при обрыве связи во время записи файл может повредиться;
• ⚠️ нет полноценного разграничения доступа на уровне хранилища: у кого есть доступ к каталогу, тот может скопировать базу целиком.

Ориентиры из практики: файловый режим комфортен примерно до 5–10 одновременных пользователей и базы в несколько гигабайт. Это не жёсткий лимит платформы, а граница, после которой начинаются заметные задержки при проведении документов и формировании отчётов. Точная цифра зависит от конфигурации, диска и сети.

Не храните файловую базу на сетевой папке с Wi-Fi-подключением клиентов. Это самый частый путь к повреждённому файлу.

Серверные СУБД: MS SQL, PostgreSQL и другие

Клиент-серверный режим нужен, когда пользователей десятки, база растёт, а простои стоят денег. Платформа поддерживает несколько СУБД, основные для большинства компаний — две.

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

Сравнение: когда какой режим выбрать

Единой «правильной» цифры нет, но выбор можно свести к простой логике.

Что реально меняется при переходе на сервер:

• блокировки становятся построчными, а не по крупным областям, параллельная работа ускоряется;
• тяжёлые отчёты выполняются на сервере, а не гоняют данные через сеть к клиенту;
• резервное копирование идёт средствами СУБД и не требует остановки работы;
• появляется отдельное железо или виртуальная машина под СУБД и под кластер 1С.

Сервер не лечит плохой код. Если запрос в отчёте написан неудачно, на SQL-сервере он будет так же плох, только быстрее упрётся в диск.

Когда переезжать на сервер не нужно

Серверный режим — не награда за солидность. Если в базе работают два бухгалтера, а тормоза возникают только при закрытии месяца, сначала разберитесь с причиной. Часто хватает SSD, свежего релиза платформы и чистки старых данных.

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

Признаки, что пора менять режим:

• 🔴 регулярные ожидания блокировок при одновременном проведении документов;
• 🔴 повреждение файла базы чаще раза в год;
• 🔴 нужны регламентные задания и обмены по расписанию без участия пользователя;
• 🔴 в базу заходят удалённые сотрудники и веб-клиенты.

Что делает 1С быстрой или медленной

Производительность складывается из четырёх частей: диск, оперативная память, процессор и качество кода. Чаще всего узкое место — дисковая подсистема.

Железо и параметры сервера

• 💾 Для файла базы и для файлов данных СУБД нужен SSD. Обычный жёсткий диск при многопользовательской работе — частая причина тормозов.
• 🧠 Серверу СУБД нужно достаточно памяти, чтобы горячие таблицы помещались в кэш. На MS SQL ограничьте max server memory, иначе он займёт всю память и вытеснит ОС.
• ⚙️ Сервер СУБД лучше держать отдельно от рабочих процессов 1С, когда нагрузка высокая. На небольшой базе допустимо совмещение.

Регламентные операции на SQL

Серверные СУБД требуют обслуживания. Без него база деградирует месяцами, и никто не понимает почему.

1. Обновление статистики таблиц — планировщик запросов опирается на неё при выборе плана.
2. Перестроение или реорганизация индексов — особенно на больших регистрах.
3. Регулярные полные копии и копии журнала транзакций.
4. Контроль размера журнала транзакций, чтобы он не заполнил диск.

Для PostgreSQL аналог — VACUUM и ANALYZE; автоочистка обычно включена, но её параметры под большие базы приходится настраивать.

Кодовые причины тормозов

Часто «виновата» не СУБД. Типовые причины:

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

Для оценки скорости железа применяют тест Гилёва — он даёт условные «баллы» и позволяет сравнить сервера между собой. Для разбора конкретных медленных операций служат технологический журнал и замеры производительности, встроенные в платформу.

Безопасность данных и резервное копирование

Хранилище — это не только скорость, но и защита. Режимы тут сильно отличаются.

Контроль доступа

В файловом режиме защита опирается на права к каталогу. Если у пользователя есть доступ к папке, он получает всю базу. Для серверного режима доступ к самой СУБД выдают только учётной записи службы 1С и администраторам. Обычным пользователям прямой доступ к SQL-серверу не нужен: они работают через кластер 1С и свои роли в базе.

Дополнительные меры:

• 🔒 не использовать для подключения к СУБД учётку sa или суперпользователя без необходимости;
• 🔒 порты СУБД закрывать от внешней сети;
• 🔒 хранить копии отдельно от основного сервера.

Как делать копии в разных режимах

Выгрузка в .dt делается в Конфигураторе через меню «Администрирование» — «Выгрузить информационную базу». Это удобный страховочный вариант перед обновлением, но не замена регулярным копиям СУБД.

Если база повреждена

В файловом режиме помогает встроенный инструмент «Тестирование и исправление» в Конфигураторе. Перед запуском делайте копию каталога: операция меняет данные. В серверном режиме сначала проверяют целостность средствами самой СУБД, потом — инструмент платформы.

Как перейти с файловой базы на сервер

Типовой порядок такой:

1. Подготовьте сервер, установите платформу и серверный компонент 1С, поставьте и настройте СУБД.
2. Создайте на кластере пустую информационную базу. При создании укажите тип СУБД, имя сервера СУБД, имя базы и учётную запись для доступа.
3. Выгрузите файловую базу в .dt из Конфигуратора.
4. Загрузите .dt в новую серверную базу .
5. Проверьте: запустите проведение нескольких документов, откройте крупные отчёты, сравните остатки с файловой версией.
6. Переведите пользователей на новую базу и закройте старую для редактирования.

Рекомендация по времени: переезд в выходные или вечером, когда никто не вводит данные. Старую файловую копию оставьте на несколько недель на случай отката.

Частые вопросы