Работаю с Битриксом на проектах разного размера, от лендинга на пять товаров до каталога с несколькими сотнями тысяч позиций, и почти каждый раз всё упирается в один и тот же вопрос: как устроен инфоблок Битрикса и когда стандартной сущности уже не хватает. Инфоблок это универсальный контейнер для однотипных данных: новости, каталог, отзывы, вакансии, что угодно с похожей структурой полей. На старте кажется, что в инфоблоки можно засунуть вообще всё, но у структуры есть свои границы, и разговор про Highload-блоки обычно начинается именно в тот момент, когда эти границы нащупали на практике.
Что такое инфоблок в Битриксе и зачем он нужен
Инфоблок в Битриксе это сущность для хранения однотипного контента: у неё есть элементы (сами записи), разделы для иерархии и свойства, задающие структуру полей. Модуль называется iblock и лежит в основе почти всех решений на платформе: каталог интернет-магазина, новости, портфолио, отзывы, вакансии, FAQ, всё это инфоблоки с разным набором свойств под конкретную задачу.Когда беру проект на 1С-Битрикс на поддержку, первым делом смотрю список инфоблоков в админке (раздел «Контент», пункт «Инфоблоки») и их свойства. По этому списку сразу видно, насколько аккуратно был спроектирован сайт. Если для карточки товара заведено сорок свойств, из которых половина не используется в выводе, это будущие тормоза при любой доработке.
Структура инфоблока: типы, разделы и элементы
Типы инфоблоков
Перед созданием инфоблока Битрикс просит выбрать тип, это шаблон с настройками полей по умолчанию (новости, каталог, техподдержка и так далее, либо свой). Тип не хранит контент, он группирует инфоблоки со схожим назначением и общими настройками ЧПУ. На практике почти на каждом проекте завожу отдельный тип под контентные инфоблоки (новости, статьи, отзывы) и отдельный под каталог, чтобы у модуля каталога были свои настройки без конфликтов с обычным контентом.
Разделы и иерархия элементов
Разделы это папки внутри инфоблока, у них тоже есть привязанные свойства, только их немного меньше видов, чем у элементов. Разделы можно вкладывать друг в друга сколько угодно уровней, это удобно для каталога с категориями и подкатегориями, но каждый лишний уровень вложенности добавляет JOIN при построении меню и хлебных крошек.Для интернет-магазина с трёх-четырёхуровневым каталогом это некритично. А вот засовывать в разделы, например, региональную структуру с сотнями городов уже не стоит, для такого объёма лучше подходит справочник на Highload-блоке, о котором расскажу дальше.
Свойства инфоблоков: какие бывают и как их настраивать
Стандартные типы свойств
У элемента инфоблока есть базовый набор полей (NAME, CODE, ACTIVE, SORT, PREVIEW_TEXT, DETAIL_TEXT, PREVIEW_PICTURE, DETAIL_PICTURE), и поверх них можно добавлять свойства под конкретную задачу.Основные типы свойств:
- строка и число
- список с заранее заданными вариантами
- файл или изображение
- привязка к элементам другого инфоблока
- привязка к разделам
- HTML или визуальный редактор
- справочник (тип «С») со своей отдельной таблицей значений и произвольными полями
Для цвета товара обычно беру список, для связки «похожие товары» привязку к элементам того же инфоблока, для сложных характеристик вроде габаритов с несколькими полями справочник.
Множественные свойства и их цена
Свойство можно сделать множественным, тогда у одного элемента может быть несколько значений одного свойства: несколько цветов, несколько файлов. Технически каждое множественное свойство хранится в отдельной таблице b_iblock_element_property построчно, а не как одно поле в общей таблице элементов.Из-за этого фильтр каталога сразу по нескольким множественным свойствам (например, «цвет плюс материал плюс бренд» в фильтре интернет-магазина) превращается в цепочку JOIN-ов. На инфоблоке в несколько десятков тысяч товаров с таким фильтром просадка уже заметна без дополнительного кэширования или без сведения свойств в индексы через модуль каталога.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Торговые предложения и границы производительности
SKU и связанные инфоблоки
Модуль каталога надстраивается над обычным инфоблоком: товары это элементы, а торговые предложения (размер, цвет и так далее) обычно живут в отдельном связанном инфоблоке через свойство с привязкой CML2_LINK к родительскому товару. Так одна карточка «Кроссовки, модель X» превращается в товар-родитель и десяток SKU с разным размером и остатком.Это удобно для вывода на фронт и для интеграции с 1С через обмен CommerceML, но означает, что у каталога на 5000 товаров с 8-10 размерами на каждый по факту 40 000-50 000 элементов лежит в инфоблоке торговых предложений, и это тоже нужно учитывать при оценке производительности.
Где начинаются тормоза на больших объёмах
Инфоблок универсальный инструмент, и за универсальность платишь на объёме. По моей практике первые заметные тормоза на обычном хостинге начинаются где-то от 100 000-150 000 активных элементов в одном инфоблоке, если выборка идёт с фильтром по нескольким свойствам и с сортировкой не по индексируемому полю. Причины типовые:
- каждое множественное свойство это JOIN к отдельной таблице
- у любого элемента десятки служебных полей, даже если реально используются три из них
- сортировка и фильтрация по UF- и PROPERTY-полям почти всегда медленнее, чем по родным колонкам таблицы элементов
- обработчики событий вроде
OnBeforeIBlockElementUpdateвыполняются на каждую операцию, и если их накопилось много за годы поддержки, каждое сохранение элемента ощутимо тяжелеет
Для контентных разделов (новости, статьи) это редко становится проблемой, там обычно сотни или тысячи записей. А вот для логов, истории просмотров, больших справочников (адресный классификатор, справочник брендов на десятки тысяч позиций, история изменения цен) инфоблок как хранилище уже избыточен.
Highload-блоки: когда стандартного инфоблока недостаточно
Чем HL-блок отличается от инфоблока
Highload-блок это модуль highloadblock, который создаёт под сущность обычную таблицу MySQL с произвольными UF-полями и работает через D7 ORM: HighloadBlockTable::compileEntity() и стандартный метод getList(). У него нет разделов, нет привычных PREVIEW/DETAIL-полей, нет истории версий и нет отдельной таблицы под каждое множественное свойство, все поля хранятся в одной строке одной таблицы, поэтому выборка по индексу в разы быстрее, чем аналогичная по свойствам инфоблока.
| Критерий | Инфоблок | Highload-блок |
|---|---|---|
| Хранение свойств | множественные свойства в отдельных таблицах с JOIN | все поля в одной строке одной таблицы |
| Разделы и иерархия | есть из коробки, с вложенностью | нет, придётся эмулировать дополнительным полем |
| Готовые компоненты для вывода | каталог, новости, детальная и списочная страницы | нет, вывод пишется вручную через API |
| Скорость на больших объёмах | просадка от 100 000+ элементов при сложных фильтрах | комфортно работает на миллионах строк при наличии индексов |
| Права доступа по элементам | есть, настраиваются в модуле | нет, права только на весь блок целиком |
| Типичное применение | каталог, новости, отзывы, вакансии | логи, история просмотров, большие справочники, счётчики |
Инфоблок или Highload-блок: как выбрать
Для контента, который читает и редактирует человек через админку (новости, каталог, портфолио, отзывы), инфоблок остаётся правильным выбором: там нужны разделы, права доступа, превью-картинки и готовые компоненты. Highload-блок стоит заводить, когда данные генерируются программно и в основном читаются кодом, а не человеком: журнал действий пользователя, кэш курсов валют, история изменения остатков, счётчики просмотров, большой справочник без иерархии.Смешивать подходы тоже нормально. У меня был проект, где каталог остался на инфоблоке (полторы тысячи товаров, разделы важны для навигации), а историю просмотренных товаров для рекомендаций перенесли на Highload-блок, потому что записей там прибавлялось по несколько тысяч в день, и хранить их как элементы инфоблока со всеми служебными полями было просто нерационально.Если на проекте уже накопились тяжёлые инфоблоки с фильтрами, которые тормозят, и непонятно, что из этого стоит переносить на Highload, а что оставить как есть, разумно сначала сделать аудит структуры данных. Это как раз часть услуги доработка и поддержка 1С-Битрикс: смотрю реальные запросы к базе, а не только количество элементов, и уже по логам решаю, где нужен Highload, а где хватит индекса или кэширования.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Сколько элементов может быть в одном инфоблоке Битрикса?
Жёсткого лимита в самой платформе нет, база данных выдержит миллионы строк. Ограничение практическое: с ростом количества элементов и множественных свойств выборки с фильтрами замедляются, и по моему опыту первые вопросы на эту тему у клиентов появляются в районе 100 000-150 000 активных элементов при сложной фильтрации.
Можно ли позже перенести данные из инфоблока в Highload-блок?
Да, но весь функционал, завязанный на разделы, права по элементам и стандартные компоненты вывода, придётся переписывать под API Highload-блока вручную, готового мастера миграции в модуле нет. Проще спроектировать это заранее, если известно, что данные будут расти быстро.
Нужен ли Highload-блок для обычного интернет-магазина на 2000-3000 товаров?
Почти всегда нет. На таком объёме обычный инфоблок с каталогом и торговыми предложениями работает штатно, а разделы и права доступа, которые есть у инфоблока и которых нет у Highload-блока, для магазина такого размера полезнее прироста скорости, которая на этом объёме почти не заметна.
Чем свойство типа «Справочник» отличается от привязки к элементам?
Привязка к элементам ссылается на другой полноценный инфоблок с его свойствами, разделами и детальными страницами. Справочник (тип «С») это просто отдельная плоская таблица значений без своих свойств и без вывода на фронт. Справочник беру для простых списков вроде «единица измерения» или «статус», а привязку к элементам, когда у связанной сущности должна быть своя карточка.