Как выглядит структура 1С: архитектура и метаданные

Понимание того, как именно организована структура 1С на низком уровне, является фундаментальным навыком для любого серьезного разработчика или системного администратора. Многие пользователи воспринимают платформу как «черный ящик», в который загружаются данные, но внутреннее устройство определяет производительность, возможности резервного копирования и методы миграции. Без знаний о физической организации файлов и логической структуре метаданных невозможно эффективно оптимизировать работу системы или диагностировать сложные ошибки целостности.

В основе архитектуры лежит четкое разделение на клиентскую часть, сервер приложений и сервер баз данных. Однако, если рассматривать именно хранение информации, то здесь ключевую роль играют файлы конфигурации и таблицы данных. Разработчикам часто приходится иметь дело с артефактами вроде файлов 1Cv8.1CD или 1Cv8DD, структура которых кардинально отличается в зависимости от используемого СУБД. Глубокое погружение в эти детали позволяет понять, почему одни запросы выполняются мгновенно, а другие «вешают» сервер на часы.

Рассмотрим детально, из каких компонентов складывается экосистема платформы и как данные трансформируются из объектов метаданных в записи реляционных таблиц. Это знание необходимо не только для написания кода, но и для грамотного администрирования кластера серверов.

Физическая структура файлов базы данных

На физическом уровне структура хранилища данных зависит от выбранного варианта работы. В файловом варианте вся информация упакована в один или несколько бинарных файлов в папке базы. Если же используется клиент-серверный вариант, то данные распределяются по таблицам в PostgreSQL, MS SQL или Oracle. В файловом варианте ключевым элементом является файл 1Cv8.1CD, который содержит основную таблицу данных.

Этот файл представляет собой специфический формат хранения, оптимизированный под движок 1С. Он не является обычной реляционной базой в классическом понимании, хотя и содержит индексы и структуры данных, схожие с ними. При работе в многопользовательском режиме файловая база может создавать временные файлы блокировок, например 1Cv8.cfl, которые критически важны для предотвращения конфликтов записи.

Структура папки файловой базы также включает служебные файлы, такие как 1Cv8Log (журнал регистрации событий) и 1Cv8Tmp (временные данные). Понимание назначения каждого файла помогает администраторам быстро очищать мусор или восстанавливать работоспособность после сбоев питания.

⚠️ Внимание: Никогда не копируйте файловую базу 1С, пока в ней есть активные пользователи или запущен процесс сервера. Копирование «на лету» приведет к рассинхронизации служебных файлов и потере данных при следующем запуске.

Логическая структура метаданных

Логическая структура 1С строится вокруг понятия метаданных. Это описание всех объектов системы: справочников, документов, регистров, отчетов и обработок. Метаданные хранятся в отдельном слое и определяют, какие таблицы будут созданы в физической базе данных. Изменение конфигурации в конфигураторе автоматически влечет за собой перестройку физической структуры таблиц.

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

Разработчики работают с деревом метаданных, где объекты сгруппированы по типам. Это позволяет визуально оценивать сложность конфигурации. Глубокая вложенность объектов или большое количество табличных частей может существенно усложнить физическую структуру и замедлить выполнение запросов. Оптимизация метаданных — первый шаг к ускорению работы системы.

• 📂 Справочники — хранят условно-постоянную информацию (контрагенты, товары, сотрудники).
• 📄 Документы — фиксируют хозяйственные операции во времени с возможностью проведения.
• 📊 Регистры — специальные объекты для быстрого получения итогов и остатков (накопления, сведений, бухгалтерии).
• ⚙️ Планы видов характеристик — используются для расширения функциональности без изменения конфигурации.

Трансляция объектов в таблицы СУБД

Один из самых сложных моментов для понимания — как именно объекты 1С превращаются в таблицы SQL. Платформа использует алгоритм автоматической генерации имен таблиц и полей. Обычно имя таблицы состоит из префикса типа объекта (например, _Reference для справочников) и уникального идентификатора. Реквизиты объектов становятся полями этих таблиц.

Для сложных объектов, таких как документы с несколькими табличными частями, создается несколько физических таблиц. Основная таблица хранит шапку документа (номер, дата, контрагент), а отдельные таблицы — строки табличных частей. Это обеспечивает нормализацию данных и позволяет эффективно выполнять выборки по конкретным позициям документа.

Регистры накопления имеют наиболее сложную структуру, так как они должны поддерживать механизм проведения и перепроведения документов. Для них создаются таблицы движений, таблицы итогов и таблицы срезов. Понимание этой структуры необходимо для написания производительных запросов, которые не будут сканировать миллионы записей движений, а обратятся сразу к агрегированным данным.

-- Пример именования таблиц в SQL Server для документа "РеализацияТоваровУслуг"
TableName: _Document154 (где 154 - UUID документа)
Field: _Period (Период)
Field: _RefRKey (Ссылка на объект)
Field: _Marked (Пометка удаления)

Как узнать соответствие объекта 1С таблице в SQL?

В режиме предприятия откройте любой объект, посмотрите его UUID в свойствах или через консоль запросов. Затем в SQL найдите таблицу, в названии которой есть этот UUID или используйте системные таблицы 1С для маппинга имен.

Система индексации и производительность

Эффективность работы 1С напрямую зависит от того, как настроены индексы в базе данных. Платформа автоматически создает индексы для полей, участвующих в связях (ссылки), полях типов Date и Number, а также для полей, используемых в условиях отбора стандартных форм. Однако для сложных выборок часто требуется создание дополнительных индексов вручную через свойства объектов метаданных.

Отсутствие необходимых индексов приводит к полному сканированию таблиц (Table Scan), что при больших объемах данных (миллионы записей) может занимать часы. Администраторы должны регулярно анализировать планы выполнения запросов и выявлять узкие места. Особенно критична индексация для регистров накопления и больших справочников.

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

Тип объекта	Автоматические индексы	Ручная настройка	Влияние на скорость
Справочники	По коду, наименованию, родителю	Доп. реквизиты отбора	Высокое при поиске
Документы	По дате, номеру, типу операции	Реквизиты частых отборов	Критично для журналов
Регистры	По измерениям и ресурсам	Составные ключи	Максимальное для отчетов
Табличные части	По ссылке на владельца	Редко требуется	Среднее

Управление целостностью и блокировками

Механизм блокировок в 1С реализован на уровне управляемых блокировок СУБД и собственных механизмов платформы. При записи объекта система блокирует соответствующие строки в таблицах, предотвращая одновременное изменение одних и тех же данных разными пользователями. Структура блокировок тесно связана с транзакционной моделью базы данных.

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

Для борьбы с взаимоблокировками (deadlocks) платформа использует механизмы повторного выполнения запросов. Однако в сложных конфигурациях с интенсивным обменом данными deadlocks могут возникать регулярно. Анализ журнала регистрации и SQL-профайлера помогает выявить объекты, вызывающие конфликты, и перестроить логику работы программы.

⚠️ Внимание: Интерфейс и алгоритмы работы с блокировками могут отличаться в зависимости от версии платформы 1С и используемой СУБД. Всегда сверяйте актуальные рекомендации по настройке уровней изоляции транзакций в официальной документации к вашей версии.

Анализ структуры через консоль запросов

Для глубокого анализа структуры работающей базы разработчики используют встроенную консоль запросов. Этот инструмент позволяет выполнять произвольные SQL-запросы к системным таблицам и таблицам данных. С его помощью можно получить точную информацию о количестве записей, размере таблиц и заполненности индексов.

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

Также через консоль можно выполнить команду SP_UPDATESTATS (для MS SQL) или ANALYZE (для PostgreSQL) для обновления статистики. Это критически важно после массовой загрузки данных или удаления больших объемов информации, так как устаревшая статистика приводит к выбору неверного плана выполнения запроса оптимизатором СУБД.

Часто задаваемые вопросы (FAQ)

Можно ли вручную изменить структуру таблиц в SQL для ускорения работы?

Категорически не рекомендуется вносить изменения в структуру таблиц напрямую через SQL-редактор, минуя конфигуратор 1С. Платформа 1С жестко контролирует схему данных. Любые ручные изменения (добавление полей, индексов, изменение типов) будут перезаписаны при следующей компиляции конфигурации или обновлении структуры базы, что может привести к потере данных или неработоспособности системы.

Почему файл 1Cv8.1CD растет в размерах даже после удаления данных?

Файловая база данных не уменьшает физический размер файла автоматически при удалении записей. Освободившееся место помечается как свободное для будущих записей внутри файла, но не возвращается операционной системе. Для уменьшения размера файла необходимо выполнить процедуру «Сжатие базы данных» через меню администрирования или выгрузку/загрузку базы в новый файл.

Как узнать версию структуры базы данных?

Версию структуры можно посмотреть в свойствах базы данных в конфигураторе или в файле dbconf.cfg (для клиент-серверного варианта). Также эта информация доступна через запрос к системным таблицам конфигурации. Это важно при миграции между разными версиями платформы 1С:Предприятие.

Что такое файл 1Cv8.cfl и можно ли его удалить?

Файл 1Cv8.cfl (список блокировок) создается при запуске базы в монопольном или многопользовательском режиме. Он хранит информацию о захваченных объектах. Удалять его можно только если вы уверены, что в базе нет активных сеансов и сервер 1С остановлен. В рабочем режиме удаление этого файла приведет к ошибкам доступа и возможным повреждениям данных.

Влияет ли структура метаданных на скорость работы веб-клиента?

Да, влияет косвенно. Сложная структура метаданных с глубокими иерархиями справочников или большим количеством реквизитов увеличивает объем передаваемых данных между сервером и браузером. Оптимизация метаданных, отказ от лишних полей в основных выборках и правильное использование виртуальных таблиц ускоряют работу веб-клиента так же, как и толстого.