Разработка каталога товаров на 1С-Битрикс

Разработка каталога товаров на 1С-Битрикс

Типичная ситуация: интернет-магазин запускается на стандартном компоненте bitrix:catalog, через год каталог вырастает до 30 000 SKU, добавляются новые свойства, и страница фильтра начинает генерировать запросы на 4–6 секунд. Проблема не в «слабом хостинге» — проблема в том, что структура инфоблока и логика фильтрации проектировались без учёта масштабирования. Разработка каталога с нуля или рефакторинг существующего — это архитектурная задача, а не просто настройка компонентов.

Структура данных: инфоблоки, HL-блоки, торговые предложения

Первое решение, которое определяет всё дальнейшее, — схема хранения данных. В 1С-Битрикс каталог строится поверх инфоблоков модуля iblock, а торговая часть — поверх модуля catalog.

Плоский каталог vs. каталог с торговыми предложениями (SKU)

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

Структура в базе данных:

• b_iblock_element — основная таблица элементов
• b_iblock_element_property — значения свойств (узкое место при большом каталоге)
• b_catalog_product — цены, остатки, тип элемента (товар/предложение)
• b_catalog_price — цены по типам

Строковые свойства → HL-блоки

Свойства типа «Строка» для справочных значений (бренд, страна, материал) — распространённая ошибка. 50 000 товаров × 8 строковых свойств = 400 000 строк в b_iblock_element_property с повторяющимися VARCHAR-значениями. Правильно: создать highload-блок (например, hl_brand с полем UF_XML_ID, UF_NAME), свойство инфоблока перевести на тип «Справочник». Тогда хранится INT-ключ, а не строка.

Фасетный индекс и производительность фильтра

Без фасетного индекса фильтр по свойствам — это JOIN таблиц b_iblock_element, b_iblock_element_property и нескольких промежуточных с условием по каждому выбранному значению. На 10 000 элементов это ещё терпимо, на 50 000 — уже нет.

Фасетный индекс создаётся через Настройки → Типы инфоблоков → [инфоблок] → вкладка «Настройки» → Фасетный индекс. Битрикс строит таблицу b_iblock_{ID}_index, где заранее сохранены пары «значение свойства → ID элемента». Запрос фильтра превращается в поиск по индексированной таблице.

Условия корректной работы фасета:

• Только свойства типа «Список» или «Справочник» (HL-блок) — строки не индексируются
• После пакетного импорта из 1С индекс нужно пересоздавать (\Bitrix\Iblock\PropertyIndex\Manager::runIndex())
• Для торговых предложений — отдельная настройка фасета на инфоблоке офферов

Кеширование и композитный режим

Грамотная настройка кеша снимает нагрузку даже при неоптимальной структуре данных.

Тегированный кеш (\Bitrix\Main\Data\TaggedCache) позволяет инвалидировать кеш точечно — только при изменении конкретного элемента или раздела, а не всего каталога. Компоненты bitrix:catalog.section и bitrix:catalog.element поддерживают тегированный кеш из коробки, но нужно убедиться, что он включён в параметрах компонента.

Композитный кеш (модуль composite) — для анонимных пользователей страница каталога отдаётся как статический HTML + динамические блоки (корзина, авторизация) подгружаются отдельными запросами. Снижает нагрузку на PHP-обработку в 5–10 раз для высокотрафиковых страниц.

Кейс: рефакторинг каталога строительного интернет-магазина

Магазин строительных материалов, 28 000 SKU, 14 свойств на товар. Жалоба: страница раздела открывалась 6–9 секунд, фильтр по нескольким свойствам — до 12 секунд. Обмен с 1С падал по таймауту.

Аудит показал:

• Все 14 свойств — строковые, фасет не подключён
• b_iblock_element_property содержала 392 000 строк
• innodb_buffer_pool_size — 256MB при размере таблиц 2.1GB
• Кеш компонентов выключен «чтобы цены всегда были актуальными»

Что сделали:

1. Перевели 8 справочных свойств на HL-блоки, мигрировали данные скриптом за 40 минут
2. Создали фасетный индекс — время фильтра упало с 12 до 0.3 секунды
3. Настроили тегированный кеш — инвалидация только по затронутым элементам
4. Подняли innodb_buffer_pool_size до 6GB
5. Вынесли пересоздание фасета в агент, запускаемый после завершения обмена с 1С

Итог: страница раздела — 0.4 секунды, фильтр — 0.2–0.5 секунды, обмен с 1С проходит без ошибок.

Что входит в разработку каталога

• Проектирование структуры инфоблока с учётом типов свойств и планируемого объёма
• Настройка торговых предложений (SKU) и связи «товар — офферы»
• Создание HL-блоков для справочных свойств
• Настройка фасетного индекса и стратегии его обновления
• Разработка или настройка компонента фильтрации (bitrix:catalog.smart.filter)
• Кеширование: тегированный кеш, композитный режим
• Настройка сортировок, постраничной навигации, хлебных крошек
• Интеграция с обменом 1С: проверка маппинга свойств, настройка агентов пересоздания индекса

Сроки зависят от объёма каталога и количества нестандартных требований: от 2 недель для базового каталога до 2–3 месяцев при разработке сложной системы фильтрации с нестандартными типами свойств и интеграцией с ERP.