При использовании типового механизма дополнительных реквизитов и сведений из Библиотеки стандартных подсистем (БСП) разработчики часто сталкиваются с лавинообразным ростом физического размера базы данных. Особенно остро эта проблема проявляется в файловых базах данных (формат .1CD), где размер одной таблицы жестко ограничен лимитами файловой системы и движка платформы. Ситуация, когда пустые или булевые реквизиты занимают килобайты пространства в каждой строке, требует глубокого понимания физики хранения данных в 1С и применения правильных архитектурных решений.
В этой статье мы подробно разберем, почему раздуваются таблицы дополнительных реквизитов, как устроены составные типы данных на уровне СУБД и какие конкретные шаги необходимо предпринять для оптимизации базы данных.
Для начала выясним причину проблемы. В БСП табличная часть ДополнительныеРеквизиты любого справочника содержит реквизиты Свойство (ссылка на План видов характеристик) и Значение. Поле Значение имеет составной тип данных, определяемый ПВХ ДополнительныеРеквизитыИСведения. Набор доступных типов в этом ПВХ включает Булево, Число, Дата, Строка, а также ссылки на различные справочники конфигурации.
На уровне СУБД (будь то файловая база или SQL-сервер) платформа «1С:Предприятие» не может создать одну универсальную «резиновую» колонку для составного типа. Вместо этого СУБД физически раскладывает составной тип на несколько колонок под каждый базовый тип. В нашем примере поле Значение (в СУБД оно может называться, например, _FLD3633) разворачивается в целое семейство колонок:
_FLD3633_TYPE — байт-идентификатор типа (определяет, какой именно тип сейчас записан в строке)._FLD3633_L — колонка для хранения Булево (1 байт)._FLD3633_N — колонка для Числа._FLD3633_T — колонка для Даты._FLD3633_RRef — колонка для хранения уникального идентификатора ссылки UUID (16 байт)._FLD3633_S — колонка для Строки ограниченной длины.В чем кроется главная проблема файлового варианта (.1CD)? В отличие от современных клиент-серверных СУБД (MS SQL Server, PostgreSQL), которые динамически выделяют память под строки переменной длины и эффективно сжимают пустые поля (NULL/разреженные столбцы), внутренний формат файловой базы 1С устроен гораздо проще. Если в ПВХ разрешена строка ограниченной длины (например, до 1024 символов), то под колонку _FLD3633_S резервируется строго фиксированное место под максимальный размер. Каждый символ Unicode в кодировке UTF-16 занимает ровно 2 байта. Соответственно, строка длиной 1024 символа гарантированно резервирует 2048 байт (около 2 Кб) в файле базы данных.
Это место выделяется в файле данных для каждой строчки табличной части, даже если в этой строке фактически записано простое Булево «Истина/Ложь» или ссылка на справочник, а текстовое поле абсолютно пустое. В итоге, если у одной характеристики номенклатуры создано 10 дополнительных реквизитов (пусть даже простых флажков), каждая строка табличной части будет «весить» более 2 Кб, а сам элемент справочника с его табличной частью займет в базе порядка 20 Кб. При наличии сотен тысяч позиций номенклатуры и характеристик файловая база мгновенно исчерпает лимит размера файлов таблиц (4 ГБ или 6 ГБ в зависимости от размера страницы) и заблокирует работу пользователей.
Самый быстрый и эффективный способ уменьшить аппетиты файловой базы — скорректировать метаданные в Конфигураторе. По умолчанию в типовых конфигурациях 1С для типа «Строка» в ПВХ ДополнительныеРеквизитыИСведения установлена длина 1024 символа.
Выполним следующие шаги для оптимизации:
ДополнительныеРеквизитыИСведения._S во всех связанных таблицах).Проанализируем эффект: уменьшение длины строки со 1024 до 100 символов сократит физический размер колонки _S с 2048 байт до 200 байт. Это мгновенно снизит объем, занимаемый каждой пустой строкой в табличной части дополнительных реквизитов, практически в 10 раз!
Как быть, если пользователям действительно нужны длинные тексты?
В Библиотеке стандартных подсистем этот сценарий уже заложен на архитектурном уровне. В БСП табличная часть ДополнительныеРеквизиты содержит не только поле Значение, но и отдельный реквизит ТекстоваяСтрока с типом Строка неограниченной длины.
Когда пользователь создает в режиме «1С:Предприятие» новый дополнительный реквизит и выбирает тип «Строка», ему доступен флаг «Неограниченная длина». В этом случае БСП работает следующим образом:
Значение остается пустым.ТекстоваяСтрока.Таким образом, ограничив обычную строку в ПВХ до 50–100 символов, мы убираем лишний оверхед, а для ввода больших текстов ориентируем пользователей на выбор типа «Строка неограниченной длины».
Рассмотрим разницу между механизмами дополнительных реквизитов и дополнительных сведений, предоставляемыми БСП:
Номенклатура). Они считываются и записываются вместе с объектом, жестко увеличивая его вес. Даже если у конкретного товара нет ни одного заполненного доп. реквизита, пустые ячейки (или строки) все равно могут создаваться и резервировать место.ДополнительныеСведения. Записи в этом регистре создаются методом «ведущих записей» и существуют только тогда, когда значение реально заполнено.Если определенные свойства товаров или характеристик заполняются редко (например, у 10–20% ассортимента) и их не требуется постоянно держать открытыми на форме элемента для редактирования, переведем их в категорию дополнительных сведений. Это полностью исключит создание пустых «строк-пустышек» в объектах и сэкономит дисковое пространство файловой базы.
Если анализ базы данных показывает, что определенный дополнительный реквизит (например, «Цвет», «Размер» или «Производитель») заполняется практически для всех элементов справочника (90% и более), использовать универсальный механизм БСП становится архитектурно нецелесообразно.
Универсальность БСП удобна для пользователя, но за нее приходится платить избыточностью СУБД. В такой ситуации правильным решением будет отказ от хранения этого свойства в табличной части доп. реквизитов и создание «родного» реквизита конфигурации.
Выполним эту задачу современным способом без снятия конфигурации с поддержки — через Расширение конфигурации:
ХарактеристикиНоменклатуры).Реквизит_Цвет с типом СправочникСсылка.Цвета).Проанализируем разницу в хранении:
СправочникСсылка.Цвета имеет четкий типизированный формат и занимает в СУБД ровно 16 байт (UUID ссылки) + служебный байт типа. Разница в объеме занимаемой памяти составляет более чем 120 раз!Поэтому все массово используемые свойства, критичные для отборов, аналитики и заполняемые у большинства объектов, необходимо переносить в реальные реквизиты базы данных через расширения.
Чтобы не допустить внезапной остановки работы из-за превышения лимитов файловой базы 1С, администратору и разработчику необходимо регулярно мониторить физическое состояние файлов таблиц.
Начиная с версии платформы 1С 8.3.15, мы можем программно получать детальную информацию о размере таблиц базы данных прямо из встроенного языка, используя специализированные функции и методы работы с информационной базой. Для файловых баз также отлично подходят внешние утилиты анализа структуры файлов .1CD (например, утилита Tool1CD или специализированные обработки с ИТС), которые показывают точный размер каждой таблицы данных, индексов и BLOB-полей.
Если вы видите, что размер таблицы табличной части дополнительных реквизитов (например, _InfoRgXXXX для регистров или _ReferenceXX_VTXX для табличных частей справочников) приближается к критическим 4 ГБ, незамедлительно примените один из описанных выше методов оптимизации, после чего обязательно запустите процедуру «Тестирование и исправление» с включенным режимом «Сжатие таблиц» (дефрагментация файла базы данных).