Инфоблоки или Highload-блоки: как выбрать хранилище

Справочник городов доставки: пятнадцать тысяч записей, шесть полей. Лежит в инфоблоке, потому что «в Битриксе всё лежит в инфоблоках». Выборка городов с фильтром по региону и признаку активности занимает четыре секунды.

Оптимизация запроса не помогает. Кэширование лечит симптом, но справочник обновляется из внешней системы каждый час, и кэш живёт не дольше. Добавление памяти серверу не даёт ничего.

Проблема здесь не в запросе и не в железе, а в модели хранения — и решается она сменой хранилища, а не оптимизацией. Разберём, чем эти две модели отличаются на самом деле и по каким признакам выбор делается за минуту.

Что такое Highload-блок

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

Инфоблок устроен принципиально иначе. Основные поля элемента — название, дата, активность — лежат строкой в своей таблице, а вот свойства хранятся отдельно, по строке на каждое значение. Эта схема называется EAV, «сущность — атрибут — значение», и она даёт универсальность: свойства можно добавлять и удалять без изменения структуры базы.

За универсальность платят объёмом и скоростью:

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

Чего Highload-блок не умеет

Скорость — не бесплатная. Список того, чего в Highload-блоке нет принципиально, а не «пока не сделали»:

Разделов и вложенности. Плоский список. Дерево категорий придётся реализовывать полем-родителем и писать обход самостоятельно.

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

Детальных страниц. У записи нет URL, нет символьного кода в адресе, нет шаблона детального просмотра. Страницу нужно делать отдельным маршрутом и компонентом.

Штатной индексации поиском. Записи не попадут в поиск по сайту без собственной реализации.

Работы в качестве товара. Highload-блок нельзя положить в корзину и продать: с заказами и каталогом работают элементы инфоблоков.

Полноценной админки. Интерфейс есть, но он заметно беднее списка элементов инфоблока — фильтры, групповые операции, настройка колонок находятся на другом уровне удобства.

Пять признаков для выбора

Вопросы задаются по порядку. Первое же «да» на верхних строках закрывает решение.

Если на первые четыре вопроса ответ «нет», а на пятый «да» — брать инфоблок незачем. Именно эта комбинация описывает справочник городов из начала статьи: своей страницы у города нет, разделы не нужны, права не нужны, товаром он не является, а записей пятнадцать тысяч.

Типичные сценарии

Справочники значений — бренды, цвета, материалы, единицы измерения. Highload-блок, причём в связке с инфоблоком: свойство типа «справочник» ссылается на него, и товары выбирают значения из быстрой таблицы. Это самая оправданная и самая частая комбинация двух хранилищ. Про то, как устроены нестандартные типы свойств, есть отдельный разбор.

Журналы и история — записи об изменениях, обращения, события интеграций. Highload-блок или своя таблица. Растут быстро, читаются редко, страниц не имеют.

Кэш выборок из внешних систем — остатки от поставщика, курсы, тарифы доставки. Highload-блок: обновляются целиком, читаются по ключу.

Каталог, статьи, страницы — инфоблок, без вариантов. Здесь нужны URL, разделы, SEO-поля и всё остальное.

Таблицы соответствий — сопоставление своих ID с ID маркетплейсов, коды регионов. Своя таблица через ORM: даже админка не нужна.

Работа с Highload-блоком в коде

Обращение отличается от инфоблоков одной особенностью: класс сущности не существует заранее, его нужно скомпилировать.

<?php
use Bitrix\Highloadblock\HighloadBlockTable;
use Bitrix\Main\Loader;

Loader::includeModule('highloadblock');

/**
 * Компиляция класса сущности — не бесплатная операция, поэтому
 * результат кэшируется на время выполнения скрипта.
 */
function hlDataClass(int $hlBlockId): string
{
    static $cache = [];
    if (isset($cache[$hlBlockId])) {
        return $cache[$hlBlockId];
    }

    $hlBlock = HighloadBlockTable::getById($hlBlockId)->fetch();
    if (!$hlBlock) {
        throw new RuntimeException("Highload-блок {$hlBlockId} не найден");
    }

    $entity = HighloadBlockTable::compileEntity($hlBlock);
    $cache[$hlBlockId] = $entity->getDataClass();

    return $cache[$hlBlockId];
}

Дальше — обычный D7-ORM:

<?php
$dataClass = hlDataClass(3);

$rows = $dataClass::getList([
    'select' => ['ID', 'UF_NAME', 'UF_REGION_CODE'],
    'filter' => [
        '=UF_ACTIVE'      => 1,
        '=UF_REGION_CODE' => 77,
    ],
    'order' => ['UF_NAME' => 'ASC'],
    'limit' => 100,
])->fetchAll();

-- Что реально есть на таблице Highload-блока
SHOW INDEX FROM b_hlbd_cities;

-- Индекс под конкретный фильтр
ALTER TABLE b_hlbd_cities ADD INDEX idx_region_active (UF_REGION_CODE, UF_ACTIVE);

Третий вариант: своя таблица

Про него забывают, а он часто самый уместный. Если сущность вообще не нужна в админке — таблица соответствий, служебная очередь, счётчики, — Highload-блок избыточен: он тянет за собой модуль, пользовательские поля и компиляцию сущности ради интерфейса, которым никто не пользуется.

Битрикс позволяет описать обычную таблицу через ORM и работать с ней тем же синтаксисом. Никаких UF_-префиксов, полный контроль над структурой и индексами, миграции — своими средствами.

Простое правило выбора между двумя быстрыми вариантами: нужен интерфейс редактирования для человека — Highload-блок, не нужен — своя таблица.

Что происходит при неверном выборе

Ошибка в обе стороны обходится по-разному, и это стоит понимать заранее.

Инфоблок вместо Highload-блока — медленно, но работает. Переезд возможен: пишется скрипт переноса, меняются места чтения. Неприятно, но конечно.

Highload-блок вместо инфоблока — быстро, но постепенно обрастает самописной реализацией того, что инфоблок давал бесплатно. Сначала маршрут для детальной страницы, потом ЧПУ, потом карта сайта, потом права для контент-менеджера. Через год это уже подсистема, которую поддерживаете только вы, и переезд обратно означает переписывание всего, что было вокруг неё построено.

Асимметрия здесь очевидна: ошибка в сторону инфоблока дешевле. Поэтому при сомнениях берут инфоблок, а Highload-блок — когда на первые четыре вопроса уверенно отвечено «нет».

Итоги

Разница не в скорости, а в модели. EAV даёт универсальность ценой соединений, плоская таблица — скорость ценой отсутствия всего остального.

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

Highload-блок без индексов не быстрее инфоблока. Их ставите вы, и об этом узнают обычно после переезда.

Справочник значений плюс свойство-справочник — лучшая связка. Быстрая таблица для значений, инфоблок для товаров.

Своя таблица через ORM — недооценённый третий вариант для всего, что не нужно показывать человеку в админке.

И соображение, которое стоит держать в голове при проектировании: инфоблок выбирают не потому, что он лучше, а потому, что это выбор по умолчанию, не требующий обоснования. Ровно поэтому справочники на десятки тысяч записей регулярно оказываются там, где им тяжело. Вопрос «а нужна ли этой сущности страница на сайте» занимает секунду и отсеивает большую часть таких решений до того, как они станут дорогими. Подробный разбор самой технологии — в статье про Highload-блоки.