Инфоблоки в 1С-Битрикс: версии 1.0 и 2.0, свойства и скорость каталога

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

В этой статье разберём инфоблоки без общих слов: что это за хранилище, чем принципиально отличаются версии 1.0 и 2.0 (и почему это не просто цифра в настройках, а разная схема таблиц в базе), какие бывают типы свойств инфоблока и как они влияют на скорость, почему множественные свойства требуют осторожности, что такое торговый каталог поверх инфоблока, как работает современный доступ через D7 ORM \Bitrix\Iblock, когда выборки пора кэшировать и в какой момент данные разумнее вынести в highload-блок. Материал — выжимка из наших внедрений по разработке каталога товаров на 1С-Битрикс, где грамотная структура инфоблоков определяет и скорость, и удобство поддержки.

Что такое инфоблок

Инфоблок (полностью — «информационный блок») — это штатный механизм 1С-Битрикс для хранения списков однотипных объектов. Представьте настраиваемую таблицу, у которой есть папки для группировки записей и произвольный набор колонок, который вы задаёте сами. Одна такая «таблица с папками и колонками» — это и есть инфоблок. Товарный каталог магазина, лента новостей, блог, отзывы, справочник магазинов, баннеры на главной — почти любой изменяемый контент на сайте под Битриксом лежит в инфоблоках.

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

Почему это удобно? Потому что администратору не нужно программировать структуру данных — он собирает её мышкой в интерфейсе: создаёт инфоблок, добавляет нужные свойства, заводит разделы и наполняет элементами. А компоненты Битрикса (каталог, новости, поиск) умеют работать с любым инфоблоком одинаково, потому что все они устроены по единой модели. Эта универсальность — сильная сторона платформы: один и тот же движок обслуживает и блог из ста статей, и каталог из сотен тысяч товаров.

Инфоблоки в архитектуре Битрикса

Инфоблоки — это отдельный модуль платформы (iblock), от которого зависят почти все остальные функциональные части магазина. Модуль торгового каталога (catalog) надстраивается над инфоблоком, добавляя элементам цены, остатки и складской учёт. Модуль поиска индексирует элементы инфоблоков. Компоненты витрины — список каталога, карточка товара, умный фильтр — все читают данные из инфоблоков. Даже разделы меню и служебные справочники часто хранятся как инфоблоки.

Из этой центральной роли следует важная мысль: структура инфоблоков — это фундамент проекта. Если фундамент заложен грамотно (правильные типы свойств, разумная вложенность разделов, подходящая версия хранения), то каталог легко масштабируется, быстро отдаёт страницы и удобно поддерживается. Если же в структуре ошибки — например, характеристики заведены строками вместо списков, или включена версия 1.0 на большом каталоге, — то тормоза и боль в поддержке становятся системными, и лечить их приходится уже переделкой хранилища, что дороже и рискованнее, чем сделать правильно сразу.

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

Структура: типы, разделы, элементы, свойства

Данные в инфоблоках организованы иерархично, и полезно держать эту иерархию в голове целиком. Сверху вниз она выглядит так:

• Тип инфоблока — верхняя группировка. Например, «Каталог», «Контент», «Сервисы». Это просто способ навести порядок в списке инфоблоков в админке.
• Инфоблок — конкретное хранилище внутри типа: «Каталог товаров», «Блог», «Отзывы». У инфоблока свой набор свойств и настроек.
• Раздел — папка-категория внутри инфоблока с произвольной вложенностью. В каталоге разделы образуют дерево категорий.
• Элемент — запись: товар, статья. Лежит в одном или нескольких разделах.
• Свойство — характеристика элемента. Набор свойств задаётся на уровне инфоблока и общий для всех его элементов.

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

Как инфоблок хранится в базе данных

Чтобы понять разницу версий, нужно спуститься на уровень базы данных. Инфоблоки хранятся в наборе служебных таблиц MySQL. Сами инфоблоки описаны в одной таблице, разделы — в другой, элементы (их стандартные поля: название, код, даты, активность) — в третьей. А вот значения свойств — самое интересное — хранятся по-разному в зависимости от версии.

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

Почему это критично? Потому что реальный каталог — это не только название и цена, а десятки характеристик у каждого товара. Когда витрина выводит список из 36 товаров с их свойствами или фильтр перебирает тысячи позиций по цвету и бренду, база обращается именно к таблицам свойств. От того, как эти таблицы устроены, напрямую зависит, сколько запросов и объединений сделает СУБД, а значит — как быстро откроется страница. Отсюда и практический вес выбора версии.

Версии инфоблока: 1.0 и 2.0

У инфоблока есть параметр «Способ хранения свойств», и у него два значения, которые исторически называют версиями 1.0 и 2.0. Оба способа делают одно и то же — хранят значения свойств элементов, — но организуют данные принципиально по-разному.

Версия 1.0 (единое хранилище значений). Все значения свойств всех инфоблоков сложены в одну общую таблицу. Каждая строка этой таблицы — это одно значение одного свойства одного элемента: «у элемента 100 свойство „бренд“ равно „Apple“». Если у товара десять свойств, для него в таблице десять строк. Плюс подхода — простота и гибкость: добавить свойство ничего не стоит, структура таблиц не меняется. Минус — чтобы собрать полный товар со всеми характеристиками, база должна собрать много разрозненных строк, а при фильтрации по нескольким свойствам сделать много объединений.

Версия 2.0 (отдельная таблица инфоблока). Для каждого инфоблока Битрикс создаёт собственную таблицу, где немножественные свойства становятся отдельными колонками, а один элемент — одной строкой. То есть «бренд», «цвет», «диагональ» — это столбцы, а товар — строка со значениями в этих столбцах. Плюс — выборка одного товара и фильтрация читаются из одной таблицы, часто одним запросом, что быстрее. Минус — таблица «шире», и структура базы жёстче привязана к набору свойств.

Итог простыми словами: 1.0 хранит свойства «вертикально» (много строк на один товар), 2.0 — «горизонтально» (одна строка, много колонок). Эта разница и определяет поведение под нагрузкой.

Хранение свойств: 1.0 против 2.0

Сведём различия в таблицу — это удобная шпаргалка при выборе версии для конкретного инфоблока.

Важная оговорка про множественные свойства. Даже в версии 2.0 «горизонтальными» колонками становятся только немножественные свойства. Множественное свойство (у которого может быть несколько значений — например, «совместимые аксессуары») в 2.0 хранится в отдельной таблице множественных значений этого инфоблока, где на каждое значение снова приходится своя строка. То есть выигрыш 2.0 распространяется на одиночные свойства, а множественные и там остаются «вертикальными». Это ещё один аргумент не злоупотреблять множественностью.

Как версия влияет на скорость каталога

Теперь связка «версия → скорость» становится очевидной. Когда витрина выводит страницу каталога с 36 товарами, каждый из которых имеет, скажем, 15 характеристик, задача базы — собрать эти товары со всеми их свойствами. В версии 1.0 это означает много строк из общей таблицы значений и объединения по каждому свойству; чем больше свойств и товаров, тем тяжелее запрос. В версии 2.0 те же данные лежат колонками в одной таблице, и выборка идёт заметно короче.

Ещё нагляднее разница на умном фильтре. Фильтрация по нескольким свойствам одновременно («бренд Apple И цвет чёрный И диагональ от 6») в терминах 1.0 требует объединять общую таблицу значений саму с собой по каждому условию — это дорого. В 2.0 условия ложатся на колонки одной таблицы. Правда, здесь важная поправка: скорость умного фильтра в первую очередь обеспечивает фасетный индекс — заранее просчитанная структура, которая делает фильтр быстрым независимо от версии. Но фасет строится поверх данных инфоблока, и на 2.0 и построение, и обновление индекса идут комфортнее.

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

Когда какая версия нужна

Разберём по ситуациям, чтобы выбор был не «на глаз», а осознанным.

• Товарный каталог — почти всегда 2.0. Много товаров, много свойств, активная фильтрация и выборки. Здесь выигрыш «горизонтального» хранения максимален, поэтому 2.0 — стандарт.
• Большие контентные списки — 2.0. Блог на тысячи статей, база отзывов, каталог организаций с множеством полей — тоже выигрывают от отдельной таблицы.
• Маленькие вспомогательные инфоблоки — можно 1.0. Пара баннеров на главной, десяток слайдов, короткий справочник — разница незаметна, а гибкость 1.0 (добавление свойств без изменения структуры) иногда удобнее.
• Инфоблоки с очень частым добавлением свойств на лету — нюанс. В 2.0 добавление немножественного свойства меняет структуру таблицы; если по логике проекта свойства заводятся программно и постоянно, это стоит учитывать. Но в типовом каталоге свойства стабильны, и это не проблема.

В большинстве проектов правило простое: всё, что относится к каталогу и большим спискам, — на 2.0; мелкие служебные инфоблоки живут как есть. Если сомневаетесь, выбирайте 2.0 — для роста это безопаснее.

Как узнать и сменить версию

Версия хранения задаётся в настройках конкретного инфоблока, в разделе управления инфоблоками административной части. Параметр называется «Способ хранения свойств» и предлагает выбор между «раздельным» (1.0) и хранением в отдельной таблице (2.0). Там же видно текущий режим.

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

Если вы пишете код и хотите узнать версию инфоблока программно, у объекта инфоблока есть служебное поле версии. Но на практике знать её нужно в основном в двух случаях: при отладке производительности выборок и при написании прямых SQL-запросов (что делать не рекомендуется — лучше идти через API). В обычной работе версия «просто настроена один раз» и дальше не трогается.

Разделы и вложенность каталога

Разделы — это дерево категорий каталога. Они хранятся в отдельной таблице и поддерживают произвольную вложенность: «Электроника → Смартфоны → Флагманы». Технически иерархия разделов реализована через модель вложенных множеств (nested sets) — специальную схему, которая позволяет быстро получать всё поддерево категории одним запросом, без рекурсии. Для витрины это значит, что «показать все товары раздела и его подразделов» работает эффективно.

С разделами связано несколько практических решений, влияющих и на скорость, и на SEO.

• Глубина вложенности. Слишком глубокое дерево (5–6 уровней) неудобно и покупателю, и SEO — длинные цепочки хлебных крошек, размытые категории. Обычно 3–4 уровня достаточно.
• Товар в нескольких разделах. Элемент можно привязать к нескольким разделам (основной и дополнительные). Это удобно для товаров, попадающих в разные категории, но требует аккуратности с каноническими URL, чтобы не плодить дубли.
• Свойства у разделов. У разделов, как и у элементов, могут быть свои свойства — например, картинка категории или SEO-текст. Это удобно для оформления страниц категорий.
• Символьный код раздела. Формирует ЧПУ категории, поэтому его задают осмысленным и не меняют после индексации.

Грамотное дерево разделов — половина успеха каталога. Оно определяет и навигацию, и структуру URL, и логику умного фильтра (который работает в рамках раздела). Поэтому проектированию разделов уделяют столько же внимания, сколько и свойствам.

Символьные коды элементов и разделов

Символьный код (в интерфейсе — «Символьный код», в API — CODE) — это человекочитаемый идентификатор элемента или раздела, из которого формируются «человекопонятные» URL (ЧПУ). Вместо /catalog/element.php?ID=100500 покупатель видит /catalog/smartfony/iphone-15-pro/, где smartfony — код раздела, а iphone-15-pro — код элемента.

Несколько правил работы с символьными кодами, которые экономят нервы:

• Транслитерация автоматом. Битрикс умеет генерировать код из названия по правилам транслитерации при создании элемента. Это включается в настройках инфоблока и избавляет контент-менеджера от ручной работы.
• Уникальность в пределах уровня. Код должен быть уникален, иначе URL начнут конфликтовать. Настройка уникальности задаётся в инфоблоке.
• Стабильность после индексации. Менять код у страницы, которая уже в поиске, — значит терять её позиции и ловить 404. Если менять приходится, настраивайте 301-редирект.
• Латиница и дефисы. В коде используют строчную латиницу, цифры и дефисы; без пробелов, кириллицы и спецсимволов.

Символьные коды напрямую влияют на SEO каталога, поэтому их закладывают в проект осмысленно, а не «как сгенерилось». Хорошие коды — короткие, читаемые, отражающие суть товара или категории.

Типы свойств инфоблока

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

Главное правило выбора типа: тип должен соответствовать тому, как со свойством будут работать. Если по характеристике фильтруют — это «Список», справочник или число, но не строка. Если это связь с другой сущностью — привязка. Если просто текст для показа — строка или HTML. Неверный тип не всегда мешает наполнению, но почти всегда мешает фильтру и выборкам, а переделывать его на живом каталоге дорого.

Списки, справочники и привязки

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

Свойство «Список»

Список — это заранее заданный набор значений, из которого выбирают одно (или несколько при множественности). Это основной тип для характеристик, по которым фильтруют: бренд, материал, тип. Преимущество списка в том, что значения нормализованы — нет разнобоя «Apple» / «apple» / «Эппл», а фильтр строит по ним чистые фасеты. Значения списка хранятся отдельно, а у элемента лежит ссылка на значение.

Привязка к highload-справочнику

Когда значению свойства нужны дополнительные поля, простого списка мало. Классический пример — цвет: кроме названия «синий» хочется хранить HEX-код #0057FF и картинку-образец, чтобы в фильтре и карточке показывать цветные плашки. Для этого значения выносят в highload-справочник (отдельное хранилище на технологии highload-блоков), а свойству задают тип «Привязка к highload-справочнику». Плюс — богатые значения с любыми полями и переиспользование одного справочника в разных инфоблоках.

Привязки к элементам и разделам

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

Множественные свойства и скорость

Любое свойство можно сделать множественным — тогда у него будет не одно, а несколько значений. Это удобно: «совместимые модели», «доступные цвета», «теги». Но за удобство приходится платить производительностью, и важно понимать, почему.

Как мы разобрали выше, немножественное свойство в версии 2.0 хранится колонкой в таблице элемента и читается быстро — одной строкой на товар. А множественное свойство даже в 2.0 живёт в отдельной таблице множественных значений: на каждое значение — своя строка. Если у товара пять множественных свойств по десять значений в каждом, это 50 строк только на один товар. Умножьте на тысячи товаров в выдаче или на фильтрацию — и получите заметную нагрузку.

Отсюда практические правила обращения с множественностью:

1. Включайте множественность только по необходимости. Если у характеристики почти всегда одно значение — делайте её немножественной. Одиночное свойство в 2.0 быстрее.
2. Не фильтруйте по «тяжёлым» множественным свойствам без фасета. Прямая фильтрация по множественным значениям — дорогая операция. Умный фильтр спасает за счёт фасетного индекса, но сам фасет тоже растёт.
3. Следите за числом значений. Множественное свойство с сотнями значений на элемент — сигнал, что данные, возможно, стоит вынести в highload или пересмотреть модель.
4. Разделяйте «показать» и «фильтровать». Если множественный список нужен только для показа в карточке, не включайте у него участие в фильтре — не будете грузить фасет лишним.

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

Highload-справочник как тип свойства

Highload-справочник в роли значений свойства и highload-блок как отдельное хранилище — это связанные, но разные вещи, и их полезно не путать.

Highload-справочник как тип свойства — это когда значения свойства (цвета, размеры, страны) лежат в highload-справочнике, а свойство инфоблока просто ссылается на нужную запись. Вы получаете значения с произвольными доп-полями (HEX, картинка, сортировка, англоязычное написание) и можете переиспользовать один справочник в нескольких инфоблоках. Для витрины это выглядит как обычное свойство-список, но «богаче».

Highload-блок как хранилище — это самостоятельная сущность для больших однотипных наборов данных, которые не нужно показывать как элементы каталога и раскладывать по разделам. О нём подробно — в разделе про вынос данных ниже и в отдельном материале про highload-блоки в 1С-Битрикс.

Когда стоит выбрать highload-справочник вместо обычного списка для свойства:

• У значения есть доп-поля. Цвету нужен HEX и образец, размеру — соответствие сеток, стране — код и флаг. Обычный список этого не хранит.
• Значений много и они переиспользуются. Единый справочник брендов или цветов на весь проект удобнее, чем дублировать список в каждом инфоблоке.
• Значения меняются программно. Справочник удобно наполнять и обновлять через ORM D7, что упрощает интеграции.

Торговый каталог поверх инфоблока

Сам по себе инфоблок — это про хранение и структуру. Чтобы элементы стали товарами с ценами, остатками и продажей, над инфоблоком надстраивается модуль торгового каталога. Технически это выглядит так: инфоблок помечается как «Торговый каталог», и у его элементов появляются связанные сущности — цены (разных типов), складские остатки, единицы измерения, скидки, торговые предложения.

Важно понимать разделение ответственности. Инфоблок хранит саму карточку и характеристики (название, бренд, цвет, описание). Торговый каталог добавляет коммерцию (цены, остатки, склады). Эти данные лежат в разных таблицах, но привязаны к одному элементу. Поэтому, когда вы проектируете каталог, вы сначала решаете вопросы инфоблока (свойства, разделы, версия), а потом — вопросы торгового каталога (типы цен, склады, предложения).

Отдельная большая тема — торговые предложения (SKU), когда у одного товара есть вариации по размеру и цвету с собственными ценами и остатками. Технически это второй инфоблок, связанный с первым, и над ним тоже надстроен торговый каталог. Мы подробно разбираем это в статье про торговые предложения (SKU) в 1С-Битрикс. Здесь важно запомнить: и товары, и их предложения — это всё те же инфоблоки, просто с надстройкой торгового каталога, и всё сказанное про версии, свойства и скорость к ним полностью применимо.

Индексы и оптимизация выборок

Даже на версии 2.0 большой каталог может тормозить, если выборки не оптимизированы. Разберём, за счёт чего добиваются скорости на уровне базы и API.

• Индексы базы. Для полей, по которым часто фильтруют и сортируют, нужны индексы в СУБД. Битрикс создаёт индексы под стандартные поля, но под кастомную нагрузку иногда добавляют свои. На 2.0 индекс на колонку свойства работает эффективнее, чем на общей таблице 1.0.
• Выбирайте только нужные поля. В выборках через API указывайте конкретный список полей и свойств, а не «всё подряд». Каждое лишнее свойство — это лишние данные и, для множественных, лишние объединения.
• Ограничивайте выборку. Постраничная навигация с разумным размером страницы бережёт и базу, и память. Не выгружайте тысячи элементов, если показываете 36.
• Фильтр — через фасетный индекс. Прямая фильтрация по свойствам на большом каталоге дорога; умный фильтр с фасетом делает её быстрой. Не изобретайте свою фильтрацию поверх сырых свойств.
• Тяжёлые операции — по расписанию. Переиндексацию поиска, построение фасета, массовый обмен уводят на часы низкой нагрузки, а не запускают на лету при каждом запросе.

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

D7 ORM: пространство \Bitrix\Iblock

Исторически с инфоблоками работали через «старый» процедурный API — классы вроде CIBlockElement с методом GetList. Он до сих пор работает и поддерживается, но для нового кода в Битриксе есть современный объектный слой D7 — ORM в пространстве имён \Bitrix\Iblock. Он даёт типизированные выборки, удобную работу со связями и встроенное кэширование.

Сравним подходы на простой задаче — получить активные элементы раздела. Старый стиль:

<?php
$res = CIBlockElement::GetList(
    ['SORT' => 'ASC'],
    ['IBLOCK_ID' => 5, 'ACTIVE' => 'Y', 'SECTION_ID' => 12],
    false,
    ['nPageSize' => 36],
    ['ID', 'NAME', 'PROPERTY_BREND']
);
while ($el = $res->GetNext()) {
    echo $el['NAME'] . ' — ' . $el['PROPERTY_BREND_VALUE'] . "\n";
}

Современный D7-подход через API инфоблоков (после подключения модуля и получения класса сущности элемента для нужного инфоблока) читается чище и безопаснее по типам:

<?php
use Bitrix\Main\Loader;
use Bitrix\Iblock\Elements\ElementCatalogTable; // класс сущности инфоблока

Loader::includeModule('iblock');

$elements = ElementCatalogTable::getList([
    'select' => ['ID', 'NAME', 'BREND_' => 'BREND.ITEM'],
    'filter' => ['=ACTIVE' => 'Y', '=IBLOCK_SECTION_ID' => 12],
    'order'  => ['SORT' => 'ASC'],
    'limit'  => 36,
    'cache'  => ['ttl' => 3600],
])->fetchCollection();

foreach ($elements as $el) {
    echo $el->getName() . ' — ' . $el->get('BREND')->getItem()->getValue() . "\n";
}

Что даёт D7 на практике: выборки с понятными фильтрами и связями (referenced-поля вместо ручных объединений), коллекции объектов вместо ассоциативных массивов, встроенный параметр кэша прямо в запросе, и в целом код, который проще читать и поддерживать. Мы пишем новую логику по работе с инфоблоками на D7, а старый код трогаем только по необходимости — переписывать рабочее ради стиля смысла нет.

Кэширование выборок из инфоблока

Кэширование — главный инструмент скорости на большом каталоге, важнее самой версии хранения. Смысл простой: результат тяжёлой выборки сохраняется, и повторные запросы отдают готовый результат, не трогая базу. На каталоге, где данные меняются раз в час (после обмена с 1С), нет смысла спрашивать базу на каждом хите тысяч посетителей.

В Битриксе несколько уровней кэша, и они складываются:

• Кэш компонентов. Компоненты каталога кэшируют HTML-результат. Это самый заметный по эффекту слой: собранная страница списка или карточки отдаётся из кэша.
• Управляемый кэш (managed/tagged cache). Кэш с тегами, который автоматически сбрасывается при изменении конкретного элемента или инфоблока. Позволяет держать долгий TTL и не бояться устаревших данных.
• Кэш выборок D7. Параметр cache в ORM-запросе кэширует результат самого запроса к базе.
• Композитный режим. Отдаёт статическую часть страницы мгновенно, а динамику (корзину, авторизацию) догружает. Резко улучшает воспринимаемую скорость и метрики.

Ключевая тонкость — инвалидация: кэш должен сбрасываться при изменении данных, иначе покупатель увидит старую цену или пропавший товар. Именно поэтому предпочитают управляемый кэш с тегами: он привязан к сущностям и сбрасывается точечно. Настройка кэширования — это отдельная инженерная работа, которой мы посвятили подробный разбор про кэширование в 1С-Битрикс. Здесь запомним главное: версия 2.0 даёт быстрый фундамент, но настоящую скорость каталога обеспечивает грамотно настроенный многоуровневый кэш.

Когда выносить данные в highload-блок

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

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

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

Миграция инфоблока 1.0 → 2.0

Если каталог рос на версии 1.0 и начал тормозить, перевод на 2.0 — разумный шаг. Но это операция с базой данных, и делать её нужно по порядку, а не «щёлкнуть переключатель на проде».

1. Сделайте резервную копию. Полный бэкап базы перед любыми структурными изменениями — обязателен. Если что-то пойдёт не так, откат должен быть под рукой.
2. Проверьте на копии. Прогоните миграцию на тестовой копии сайта, замерьте время и убедитесь, что данные перенеслись корректно, а витрина работает.
3. Выберите окно низкой нагрузки. На больших каталогах перенос значений в новую таблицу может идти заметное время, в течение которого возможны блокировки. Делайте это ночью или в технологическое окно.
4. Переключите версию. В настройках инфоблока смените способ хранения на 2.0. Битрикс создаст таблицу инфоблока и перенесёт немножественные свойства.
5. Перестройте фасетный индекс. После смены версии обязательно пересоберите фасет умного фильтра — иначе фильтр покажет неверную картину.
6. Проверьте кастомный код. Если у вас есть прямые SQL-запросы к таблицам свойств или самописные выборки, они могут зависеть от схемы. Проверьте и, при необходимости, поправьте их под 2.0.
7. Проверьте обмен с 1С. Прогоните тестовый обмен: убедитесь, что цены, остатки и свойства раскладываются корректно, а дубли не появляются.

Обычно основную сложность создаёт не сама смена версии, а самописный код, который лез в структуру напрямую. Если проект написан «по-битриксовому» — через API и компоненты, — миграция проходит гладко. Если в нём много прямых запросов к базе — сначала аудит кода, потом миграция. Это ещё один довод писать всё через штатный API и D7, а не в обход.

Лимиты и большие каталоги

«Сколько товаров выдержит инфоблок?» — частый вопрос. Жёсткого лимита на число элементов у инфоблока нет: ограничения — это возможности сервера и базы данных. На практике каталоги в сотни тысяч и миллионы позиций на Битриксе работают, но требуют инженерной аккуратности. Что становится узким местом при росте:

• Множественные свойства. Как мы разобрали, они множат строки в таблицах значений. На миллионах товаров с множественными свойствами таблицы значений становятся огромными.
• Обмен с 1С. Полная выгрузка большого каталога — тяжёлая операция. Её оптимизируют пакетной обработкой и переходом на инкрементальный обмен (только изменения).
• Построение фасета. Фасетный индекс на огромном каталоге строится долго; его пересборку планируют и оптимизируют.
• Переиндексация поиска. Больше элементов — дольше индексация; её ведут по расписанию, а не на лету.
• Память и время выборок. Большие выборки без ограничений и кэша упираются в лимиты PHP и базы.

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

Частые ошибки

• Характеристики для фильтра заведены строкой. «Бренд» или «цвет» типа «Строка» дают дубли значений и ломают фасет. Нужен «Список» или highload-справочник.
• Версия 1.0 на большом товарном каталоге. На десятках тысяч товаров «вертикальное» хранение тормозит выборки. Для каталога — 2.0.
• Злоупотребление множественными свойствами. Множественность там, где значение почти всегда одно, множит строки в базе и замедляет выборки. Делайте одиночные свойства немножественными.
• Цена и остаток свойством инфоблока. Коммерция должна жить в модуле торгового каталога, а не в свойствах. Иначе теряются типы цен, скидки и корректная корзина.
• Прямые SQL-запросы к таблицам свойств. Они привязаны к версии хранения и ломаются при миграции. Работайте через API и D7.
• Отсутствие кэша на каталоге. Даже 2.0 будет тормозить, если каждая страница собирается из базы заново. Кэш компонентов и managed cache обязательны.
• Смена символьного кода после индексации. Ломает URL и теряет позиции в поиске. Меняете — ставьте 301-редирект.
• Слишком глубокое дерево разделов. 5–6 уровней вложенности путают покупателя и SEO. Держитесь 3–4 уровней.
• Фасет не перестроен после миграции или обмена. Фильтр показывает устаревшую картину. После структурных изменений и крупного обмена фасет пересобирают.
• Всё в один гигантский инфоблок вместо highload. Справочники и служебные массивы данных не нужно хранить как элементы каталога — им место в highload-блоке.

Чек-лист по инфоблокам каталога

Сведём в практический список то, что проверяют при проектировании и приёмке структуры инфоблоков перед запуском каталога.

1. Версия под задачу. Товарный каталог и большие списки — на 2.0; мелкие служебные инфоблоки — как удобно.
2. Типы свойств корректны. Характеристики для фильтра — «Список» или highload-справочник; связи — привязки; показ — строка/HTML. Строк в фильтре нет.
3. Множественность обоснована. Множественные свойства включены только там, где значений действительно несколько; одиночные — немножественные.
4. Разделы спроектированы. Дерево категорий 3–4 уровня, осмысленные символьные коды разделов, продуманные дополнительные привязки.
5. Символьные коды заданы. Транслитерация настроена, коды уникальны, читаемы и не меняются после индексации.
6. Коммерция — в торговом каталоге. Цены, остатки, склады и предложения — через модуль каталога, а не свойствами инфоблока.
7. Тяжёлые данные — в highload. Справочники с доп-полями и большие однотипные массивы вынесены из инфоблоков.
8. Выборки оптимизированы. Выбираются только нужные поля, есть постраничность, под нагрузку добавлены индексы.
9. Кэш настроен. Кэш компонентов, managed cache с тегами, при необходимости композит; инвалидация работает при изменении данных.
10. Фильтр на фасете. Умная фильтрация включена у нужных свойств, фасетный индекс построен и пересобирается после обмена.
11. Код на API и D7. Прямых SQL к таблицам свойств нет; новая логика — на \Bitrix\Iblock; миграция версии не сломает выборки.

Вывод

Инфоблоки — это фундамент, на котором стоит весь каталог и контент магазина на 1С-Битрикс. Разобравшись в том, как они устроены, вы принимаете решения не наугад, а осознанно: выбираете версию хранения под размер каталога, задаёте свойствам правильные типы под фильтр и связи, не злоупотребляете множественностью, выносите тяжёлые справочники в highload и опираетесь на кэш там, где база иначе не справится. Разница между 1.0 и 2.0 — это не косметика, а разная схема таблиц, и на большом каталоге она напрямую превращается в секунды загрузки.

Практический вывод один: структуру инфоблоков закладывают правильно с самого начала, потому что менять её на живом каталоге дорого и рискованно. Товарный каталог — на 2.0, характеристики для фильтра — списками и справочниками, коммерция — в торговом каталоге, большие массивы — в highload, а скорость — на кэше и оптимизированных выборках через D7. Сделайте это аккуратно, и каталог будет одинаково быстрым и на трёх тысячах, и на трёхстах тысячах товаров. А если структуру нужно спроектировать или переработать под рост — мы помогаем с этим в рамках разработки интернет-магазинов на 1С-Битрикс, где грамотные инфоблоки закладываются в основу проекта. Больше разборов по теме — в рубрике «Каталог и поиск».