Highload-блоки в Битрикс: когда нужны и как с ними работать

Highload-блоки в Битрикс я подключаю, когда стандартный инфоблок начинает тормозить на объёме от 50-100 тысяч элементов, а список товаров в админке открывается по 8-10 секунд вместо привычной секунды. За последние несколько лет через мои руки прошло больше десятка проектов, где highload-блоки решали конкретную проблему производительности - от логов интеграции с СДЭК до хранения истории платежей через эквайринг T‑Bank. Ниже разбор без пересказа документации 1С-Битрикс: когда это решение реально нужно, а когда вы просто усложняете себе жизнь ради модного термина.

Что такое highload-блоки и чем они отличаются от инфоблоков

Highload-блок хранит данные в отдельной таблице MySQL с собственными столбцами вместо классической EAV-модели (Entity-Attribute-Value), на которой построены инфоблоки. В инфоблоке каждое свойство элемента - это строка в таблице b_iblock_element_property, и когда у элемента 20-30 свойств, выборка одной позиции каталога превращается в десяток JOIN-ов или дополнительных запросов к базе. Highload-блок вместо этого создаёт обычную таблицу с полями UF_*, где каждое свойство - реальная колонка, на которую при необходимости вешается индекс.

За это отвечает модуль highloadblock, добавленный ещё в редакцию “Бизнес”, архитектурно почти не менявшийся с тех пор - зато обросший инструментами на базе ORM D7, которые заметно упрощают работу по сравнению с классическим CIBlockElement.

Когда highload-блоки реально нужны - сценарии из практики

Пять ситуаций, где highload-блок оправдан на моей практике:

• Каталог от 50 000 SKU и выше с большим количеством фильтруемых характеристик - с индексами по нужным полям выборка по фильтру ускоряется в разы против инфоблочных свойств.
• Логирование интеграций: обмен статусами заказов с СДЭК или журнал вебхуков от эквайринга T‑Bank - тысячи записей в день, версионность и права инфоблоков тут не нужны, а важна скорость записи и выборки.
• Служебные справочники с фиксированной структурой: города доставки, склады, статусы заказов - редактируются через административный список, но не нуждаются в иерархии разделов.
• Данные, которые обновляет внешняя автоматизация - например, сценарий в n8n раз в 15 минут скидывает в highload-блок остатки со склада, а сайт читает их локально без обращения к внешнему API при каждом открытии карточки товара.
• Backend для Telegram-бота на aiogram, работающего в связке с сайтом на Битрикс - бот пишет заявки или статусы напрямую в highload-блок через REST API Битрикса, без отдельной базы и лишней инфраструктуры.

Если каталог на 3000-5000 позиций с обычными фильтрами - инфоблоков хватает с запасом, и добавление highload-блока превращается в лишнюю сущность, за которой потом отдельно следить в админке.

Как создать highload-блок в административной панели

Путь стандартный: Настройки → Highload-блоки → Добавить highload-блок. Указываю название и символьный код таблицы (латиница, станет префиксом hlbd_), сохраняю, перехожу на вкладку полей и добавляю UF-поля тем же интерфейсом, что для допсвойств инфоблоков - тип, множественность, обязательность, значение по умолчанию.

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

Работа с highload-блоками через API D7

Создание блока кодом - удобнее, чем через админку, если планируется деплой на несколько окружений:

<?php
use BitrixHighloadblockHighloadBlockTable;

$result = HighloadBlockTable::add([
    'NAME' => 'CdekOrdersLog',
    'TABLE_NAME' => 'hlbd_cdek_orders_log',
]);

if ($result->isSuccess()) {
    $hlblockId = $result->getId();
}

Добавление UF-поля тем же способом, без похода в интерфейс:

$obUserTypeEntity = new CUserTypeEntity();
$arFields = [
    "ENTITY_ID" => "HLBLOCK_{$hlblockId}",
    "FIELD_NAME" => "UF_TRACK_NUMBER",
    "USER_TYPE_ID" => "string",
    "MULTIPLE" => "N",
    "MANDATORY" => "N",
    "EDIT_FORM_LABEL" => ["ru" => "Трек-номер СДЭК"],
];
$obUserTypeEntity->Add($arFields);

Выборка через ORM D7 - то, ради чего вообще стоит переходить на highload-блоки, а не хранить всё в инфоблоках “по привычке”:

$entity = HighloadBlockTable::compileEntity($hlblockId);
$entityClass = $entity->getDataClass();

$rows = $entityClass::getList([
    'select' => ['ID', 'UF_TRACK_NUMBER', 'UF_STATUS'],
    'filter' => ['=UF_STATUS' => 'DELIVERED'],
    'order' => ['ID' => 'DESC'],
    'limit' => 50,
])->fetchAll();

Пакетная запись - типичный сценарий, когда данные прилетают из внешнего сервиса или сценария n8n через вебхук:

foreach ($ordersFromWebhook as $order) {
    $entityClass::add([
        'UF_TRACK_NUMBER' => $order['track'],
        'UF_STATUS' => $order['status'],
        'UF_UPDATED_AT' => new DateTime(),
    ]);
}

UF-поля, индексы и производительность на больших объёмах

Без индекса на поле, по которому идёт фильтрация, highload-блок работает не быстрее инфоблока - просто получаете ту же деградацию скорости, но без привычных инструментов диагностики из админки Битрикса. На таблице из 300-400 тысяч строк выборка по фильтру без индекса у меня занимала 2-3 секунды, с индексом на нужное поле - 30-50 миллисекунд на том же железе.

Пара практических моментов, которые не всегда прописаны явно в документации:

• Кэш highload-блоки не получают автоматически, как это происходит с компонентами каталога на инфоблоках - на страницах с высокой посещаемостью выборки приходится оборачивать в CPHPCache вручную.
• Множественные UF-поля (MULTIPLE = Y) создают дополнительную таблицу связей и по сути возвращают вас к той же EAV-модели, от которой вы уходили - использую их только когда реально нужна множественность, а не по умолчанию.
• В select лучше явно перечислять нужные колонки вместо выборки всех полей - на широких таблицах с десятком UF-полей разница заметна уже на паре тысяч записей.

Типичные ошибки при внедрении highload-блоков

• Делают highload-блок из каталога на 3000 товаров “на вырост” - теряют торговый функционал (торговые предложения, привязку к CML2, готовые компоненты с фильтром) без реальной выгоды в скорости на таком объёме.
• Забывают про индексы совсем и получают тот же тормоз, что был в инфоблоке, только без привычных средств диагностики запросов.
• Используют множественные UF-поля там, где хватило бы одной строки с JSON или отдельной таблицы связей, спроектированной под задачу руками.
• Не настраивают права доступа отдельно - по умолчанию highload-блок видят все администраторы с доступом к модулю, и если в нём хранятся персональные данные клиентов, это стоит разграничить на вкладке блока.
• Ждут от highload-блока готового компонента с постраничной навигацией и SEO-урлами “из коробки” - такого компонента нет, вывод на фронте почти всегда пишется отдельно поверх ORM.

Для интеграций с внешними сервисами - CDEK API, эквайринг, обмен с CRM - данные клиентов и заказов держу на серверах в РФ, это касается и highload-блоков как хранилища: важно, чтобы персональные данные не утекали в сторонние облачные таблицы или зарубежные сервисы автоматизации.

Частые вопросы

Highload-блоки заменяют инфоблоки полностью?

Нет, это два инструмента под разные задачи. Инфоблоки остаются лучшим выбором для каталога с торговыми предложениями, разделами и стандартными компонентами, а highload-блоки закрывают узкие места - большие объёмы, логи, справочники без иерархии. На одном проекте у меня спокойно уживаются оба: каталог на инфоблоках и журнал статусов доставки на highload-блоке.

Можно ли вывести highload-блок на фронте так же просто, как инфоблок компонентом news.list?

Готового компонента с фильтром, пагинацией и SEO-урлами из коробки нет. Обычно пишу небольшой самописный компонент поверх ORM D7 под конкретную задачу - это занимает от пары часов до пары дней в зависимости от логики фильтрации и объёма данных.

Highload-блоки поддерживают привязку к торговому каталогу и CML2?

Нет, обмен по CML2 и привязка торговых предложений - это механика инфоблоков. Если нужен обмен с 1С для каталога, оставляю каталог на инфоблоках, а highload-блок использую рядом для вспомогательных данных вроде остатков со складов или логов синхронизации.

Что будет, если не создать индекс на часто фильтруемое поле?

На небольшом объёме - до 10-20 тысяч записей - разница почти не заметна. На сотнях тысяч строк без индекса каждый запрос с фильтром по такому полю превращается в полное сканирование таблицы, и время выборки растёт линейно с ростом данных - именно это чаще всего и приводит людей к мысли, что “highload-блоки не такие уж быстрые”, хотя причина в отсутствии индекса, а не в самой технологии.