Проектирование структуры highload-блоков 1С-Битрикс

Проектирование структуры highload-блоков 1С-Битрикс

Представьте: каталог на 50 000 товаров с 200 характеристиками — каждый новый параметр добавляет миллионы строк в b_iblock_element_property. База начинает тормозить, индексы раздуваются, фасетный индекс пересоздаётся часами. Как разгрузить систему без потери производительности? Мы видим решение в грамотном проектировании highload-блоков. Это не просто «создать табличку» — это инженерная задача, от которой зависит скорость работы всего каталога.

HL-блок — генератор пользовательских таблиц в MySQL/PostgreSQL поверх D7 ORM. Технически это запись в b_highload_block, набор полей в b_user_field и автоматически создаваемая таблица hl_{XML_ID}. Ничего магического — просто способ создать таблицу с типизированными полями через интерфейс Битрикс без написания SQL. Но именно от того, как эта структура спроектирована, зависит, будет ли HL-блок работать как быстрый справочник или превратится в узкое место.

Когда HL-блок, а когда инфоблок или своя таблица?

HL-блок заменяет инфоблок там, где не нужны разделы, SEO-поля (META_TITLE, META_KEYWORDS), preview/detail-изображения и встроенные механизмы публикации. Это справочники: бренды, страны, теги, единицы измерения, характеристики для фасета.

HL-блок проигрывает собственной D7-таблице (DataManager) когда:

• Нужны составные индексы (HL поддерживает только индексы по отдельным полям через UF_*)
• Нужны внешние ключи и каскадные операции
• Схема таблицы меняется часто и требует миграций

В этих случаях правильнее создать класс, наследующий \Bitrix\Main\ORM\Data\DataManager, и управлять таблицей через него.

Как выбрать между HL-блоком и собственной таблицей?

Вывод: используйте HL-блок, если не нужны составные индексы и связи. Иначе — DataManager.

Типы полей HL-блока и их особенности

HL-блоки используют систему пользовательских полей (UF_*). Доступные типы:

• string / string_formatted — VARCHAR. Для имён, названий.
• integer — INT. Для числовых идентификаторов, сортировки.
• double — DECIMAL/FLOAT. Для цен, коэффициентов.
• boolean — TINYINT(1). Флаги активности.
• file — хранит ID файла из b_file. Для изображений в справочниках.
• enumeration — привязка к b_user_field_enum. Для фиксированных статусов внутри HL-записи.
• datetime / date — DATETIME / DATE.
• iblock_element / iblock_section — привязка к элементу или разделу инфоблока. Используется с осторожностью: создаёт неявную связь между HL и инфоблоком.

Проблема поля типа iblock_element в HL-блоке: при удалении элемента инфоблока HL-запись не обновляется автоматически — нужен обработчик события OnAfterIBlockElementDelete.

Как правильно индексировать HL-таблицы?

По умолчанию HL-блок создаёт таблицу только с PRIMARY KEY по полю ID. Все остальные поля — без индексов. Если HL-блок используется как справочник для фасетного индекса каталога, дополнительные индексы обычно не нужны — фасет работает с b_iblock_{ID}_index, а не с HL-таблицей напрямую.

Но если HL-блок используется для хранения операционных данных (история действий, лог заказов, записи бонусной программы) — индексы по полям выборки критичны. Добавляются вручную через SQL-миграцию:

ALTER TABLE hl_loyalty_history ADD INDEX idx_user_id (UF_USER_ID); ALTER TABLE hl_loyalty_history ADD INDEX idx_date (UF_DATE); 

Битрикс не предоставляет UI для управления индексами HL-таблиц — только прямой SQL или скрипт миграции.

Кейс из нашей практики: HL-блок для B2B-каталога

Дистрибьютор электроники. В каталоге 2 200 уникальных характеристик товаров (технические параметры). Изначально — свойства инфоблока типа «Строка», b_iblock_element_property содержала 8 млн строк.

Решение: перевести справочные характеристики на HL-блоки по доменам:

• hl_tech_connectivity — интерфейсы подключения (USB-C, HDMI, etc.)
• hl_tech_resolution — разрешения экранов и матриц
• hl_tech_standard — стандарты (Wi-Fi 6, Bluetooth 5.2, etc.)

Каждый HL-блок: поля UF_NAME (VARCHAR 255), UF_XML_ID (VARCHAR 50, уникальный), UF_ACTIVE (boolean), UF_SORT (integer). Индексы по UF_XML_ID — добавлены вручную для быстрого поиска при импорте из 1С.

Результат: b_iblock_element_property сократилась с 8 млн до 1.2 млн строк (остались только числовые свойства). Фасетный индекс пересоздаётся за 8 минут вместо 45.

Управление данными HL-блока через D7

Работа с HL-блоком в коде — через \Bitrix\Highloadblock\HighloadBlockTable и динамически создаваемый класс:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($id)->fetch(); $entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock); $dataClass = $entity->getDataClass(); $rows = $dataClass::getList(['filter' => ['UF_ACTIVE' => true]]); 

Это стандартный паттерн — его важно закрепить в code style проекта, чтобы обращения к HL-блокам не расползались по шаблонам в виде SQL-запросов.

Что входит в работу по проектированию HL-блоков

Ориентировочный срок полного цикла для 10-15 HL-блоков — от 2 до 5 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности предметной области и необходимости миграции. Чтобы получить консультацию и оценку вашего проекта — просто напишите нам. Мы — сертифицированный партнер 1С-Битрикс с 10+ годами опыта и 50+ реализованными проектами по оптимизации производительности. Гарантируем прозрачность на каждом этапе.

Полезные ресурсы:

• Подробнее о HL-блоках: документация 1С-Битрикс
• Стандарты ORM: Bitrix D7 ORM