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

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

HL-блок — это генератор пользовательских таблиц в MySQL/PostgreSQL поверх D7 ORM. Технически HL-блок — это описание в 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-блоки используют систему пользовательских полей (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-блоков

• Анализ свойств инфоблоков: выявление кандидатов для перевода на HL
• Проектирование схемы полей каждого HL-блока
• Определение стратегии индексирования
• Планирование миграции данных из b_iblock_element_property
• Документирование: схема таблиц, назначение полей, связи
• Скрипты создания HL-блоков и первичного заполнения

Срок проектирования: 2–5 рабочих дней на каждые 10–15 HL-блоков в зависимости от сложности предметной области.