Highload-блоки в Битрикс: создание и работа с данными

Highload-блок — это отдельная таблица в базе данных, у которой есть настраиваемые поля и полноценный ORM-интерфейс. Внешне похоже на инфоблок, но устроено принципиально иначе: все данные лежат в одной таблице, а не размазаны по служебным таблицам свойств.

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

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

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

Когда стоит использовать

• справочники на десятки и сотни тысяч записей: города, улицы, марки автомобилей;
• журналы событий и история операций;
• привязанные к товарам характеристики с большим числом значений;
• данные, которые читаются часто, а редактируются редко;
• таблицы синхронизации с внешними системами.

Когда не стоит

• контент сайта: новости, статьи, страницы;
• каталог товаров — там нужны разделы, торговые предложения и цены;
• данные, которые контент-менеджер правит ежедневно;
• небольшие справочники на пару сотен строк — хватит списочного свойства инфоблока.

Создание блока

Highload-блоки живут в разделе Контент → Highload-блоки. При создании задаются два обязательных параметра:

Имя сущности становится частью имени класса, через который вы будете обращаться к данным. Менять его потом нельзя — точнее, можно, но весь написанный код перестанет работать.

После создания блока добавляются поля — на вкладке пользовательских полей. Типы те же, что и у полей инфоблоков: строка, число, список, файл, привязка к элементу.

Получение класса сущности

Работа с данными идёт через ORM, но класс сущности не существует заранее — его нужно получить по идентификатору блока:

<?php

use Bitrix\Main\Loader;
use Bitrix\Highloadblock\HighloadBlockTable;

Loader::includeModule('highloadblock');

$hlblockId = 3;

$hlblock   = HighloadBlockTable::getById($hlblockId)->fetch();
$entity    = HighloadBlockTable::compileEntity($hlblock);
$dataClass = $entity->getDataClass();

Полученный $dataClass — это обычный ORM-класс со всеми знакомыми методами. Общее устройство ORM разобрано в статье ORM в Битрикс.

Получение по имени таблицы

Привязываться к числовому идентификатору неудобно: при переносе на другой сервер он изменится. Надёжнее искать блок по имени таблицы:

<?php

$hlblock = HighloadBlockTable::getList([
    'filter' => ['=TABLE_NAME' => 'city_list'],
])->fetch();

if (!$hlblock) {
    return;
}

$dataClass = HighloadBlockTable::compileEntity($hlblock)->getDataClass();

Работа с данными

Выборка

<?php

$result = $dataClass::getList([
    'select' => ['ID', 'UF_NAME', 'UF_CODE'],
    'filter' => ['=UF_ACTIVE' => 1],
    'order'  => ['UF_NAME' => 'ASC'],
    'limit'  => 50,
]);

while ($row = $result->fetch()) {
    echo $row['UF_NAME'];
}

Обратите внимание на префикс UF_ — все пользовательские поля получают его автоматически.

Добавление

<?php

$addResult = $dataClass::add([
    'UF_NAME'   => 'Москва',
    'UF_CODE'   => 'moscow',
    'UF_ACTIVE' => 1,
]);

if ($addResult->isSuccess()) {
    $newId = $addResult->getId();
} else {
    $errors = $addResult->getErrorMessages();
}

Изменение и удаление

<?php

$dataClass::update($id, ['UF_NAME' => 'Москва и область']);

$dataClass::delete($id);

Все методы возвращают объект результата — проверять isSuccess() нужно всегда, иначе ошибка сохранения останется незамеченной.

Производительность

Главное преимущество highload-блоков раскрывается только при правильной работе с ними.

• Добавляйте индексы. Поля, по которым вы фильтруете, должны быть проиндексированы — это настраивается в свойствах пользовательского поля. Без индекса преимущество перед инфоблоком исчезает.
• Указывайте select явно. Выборка всех полей на миллионе записей съедает память.
• Используйте limit и постраничную выборку. Попытка получить всю таблицу разом закончится нехваткой памяти.
• Кешируйте результаты. ORM поддерживает кеширование выборок через параметр cache.
• Для массовой вставки отключайте лишнее. Добавление записей в цикле по одной работает медленно.

Ограничения, о которых узнают поздно

• Нет разделов. Иерархию придётся делать самому — например, полем с идентификатором родителя.
• Нет готовых компонентов. Вывод в публичной части пишется руками.
• Права только на блок целиком. Разграничить доступ к отдельным записям штатно нельзя.
• Скромный интерфейс. Для контент-менеджера он заметно беднее, чем редактирование инфоблока.
• Нет истории изменений и привычных инструментов вроде документооборота.
• Модуль есть не во всех редакциях. Проверьте доступность до того, как строить архитектуру.

Итог

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

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