При работе с поштучным учетом (будь то ЕГАИС, маркировка «Честный Знак» или другие государственные системы контроля) разработчики 1С часто сталкиваются с лавинообразным ростом базы данных. Ситуация, когда один регистр сведений разрастается до десятков гигабайт и начинает блокировать работу всей системы, блокируя проведение документов и работу ТСД (терминалов сбора данных), к сожалению, классическая.
В этой статье мы подробно разберем, почему возникает такая проблема, проанализируем узкие места стандартного проектирования и выработаем комплексную стратегию оптимизации структуры метаданных и СУБД для обеспечения максимального быстродействия.
Давайте посмотрим на исходную структуру проблемного регистра, которая часто встречается во многих тиражных отраслевых решениях:
Марка — тип Строка (160 символов).Упаковка (Строка 120), Справка (Ссылка), АлкогольнаяПродукция (Ссылка), Организация (Ссылка), ПунктРазгрузки (Ссылка), ОтметкаВыбытия (Булево).При такой структуре база данных объемом в 50 Гб может содержать регистр размером 14 Гб. Главные причины деградации производительности здесь кроются в следующем:
.ldf).---
Первое и самое важное правило проектирования высоконагруженных регистров: измерения должны быть максимально короткими и фиксированными по размеру.
Вместо хранения строки длиной 160 символов непосредственно в измерении регистра необходимо создать справочник (например, Справочник.ШтрихкодыУпаковок или Справочник.НоменклатураЕГАИС). В самом справочнике длина наименования или специального реквизита будет составлять те самые 160 символов, а в измерении регистра мы будем использовать тип СправочникСсылка.
Давайте посчитаем выгоду. На уровне СУБД уникальный идентификатор ссылки (GUID) занимает всего 16 байт фиксированной длины. Сравните это со строкой Unicode длиной 160 символов, которая может занимать до 320 байт. Переход на ссылочный тип данных уменьшает размер индекса регистра более чем в 15 раз! Это позволит SQL-серверу полностью держать индекс в кэше оперативной памяти, что мгновенно ускорит операции поиска и записи.
---
Разделим данные на условно-постоянные (статику) и оперативные (динамику). Выполним декомпозицию исходного регистра на два независимых объекта.
1. Статический реестр марок (Справочник):
При первом сканировании или загрузке накладной марка регистрируется в системе. Мы создаем элемент справочника ШтрихкодыНоменклатуры, где заполняем все неизменяемые свойства:
2. Легковесный динамический регистр (Регистр сведений):
Для отслеживания текущего состояния марки мы создаем независимый регистр сведений СтатусыМаркировки с минимальным набором полей:
Марка (тип СправочникСсылка.ШтрихкодыНоменклатуры).Статус (Перечисление: ВНаличии, Продано, Списано), Организация (Ссылка), ПунктРазгрузки (Ссылка).ДокументДвижения (Ссылка на документ-источник для истории).Такая структура весит в десятки раз меньше исходной и обновляется мгновенно.
---
Подчинение регистра регистратору накладывает жесткие рамки транзакционности. Если бизнес-логика позволяет, переведите регистр сведений в режим "Независимый".
Для ведения истории движений вместо стандартного механизма подчинения регистратору можно записывать данные программно при проведении документов. При этом для обеспечения максимальной скорости записи следует использовать запись наборов в режиме загрузки:
НаборЗаписей = РегистрыСведений.СтатусыМаркировки.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Марка.Установить(ВыбраннаяМарка);
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Марка = ВыбраннаяМарка;
НоваяЗапись.Статус = Перечисления.СтатусыМаркировки.Продано;
НоваяЗапись.Организация = ТекущаяОрганизация;
НоваяЗапись.ДокументДвижения = ИсточникСсылка;
// Записываем с флагом ОбменДанными.Загрузка = Истина для отключения лишних проверок
НаборЗаписей.ОбменДанными.Загрузка = Истина;
НаборЗаписей.Записать(Истина);
Обратите внимание: использование свойства ОбменДанными.Загрузка = Истина позволяет обойти тяжелые обработчики событий платформы 1С, выполняя прямую и быструю транзакцию в СУБД.
---
Если ваша система развернута на современных версиях платформы «1С:Предприятие 8», обязательно используйте встроенные оптимизации работы с СУБД.
Начиная с версий 8.3.26 и 8.3.27, разработчики платформы существенно оптимизировали запись наборов данных. Теперь при записи независимых регистров сведений платформа старается минимизировать избыточные SQL-запросы удаления. Внедрен механизм частичного обновления данных (слияния), что снижает нагрузку на дисковую подсистему сервера БД при массовых операциях записи с ТСД.
---
Марка имеет ограниченный жизненный цикл. После того как товар был окончательно продан конечному покупателю и данные ушли в государственную систему маркировки, держать эту марку в оперативной базе больше нет практического смысла.
Рекомендуется внедрить регламентный механизм свертки и архивирования:
Записать(Истина) с пустым набором полей по отбору.---
Если конфигурация закрыта для изменений (например, находится на поддержке и защищена СЛК), оптимизировать работу СУБД можно административными методами:
Применение этих комплексных мер позволяет сократить объем таблиц маркировки в базе данных в 5–10 раз и полностью ликвидировать задержки при проведении документов и работе складского персонала.