Проектирование фасетных индексов каталога 1С-Битрикс

Мы проектируем фасетные индексы для каталогов на 1С-Битрикс (официальная документация Wikipedia). Представьте: фильтр на странице каталога с 100 000 товаров тормозит 8 секунд — пользователи уходят, конверсия падает. Правильно настроенный фасетный индекс решает эту проблему: мы ускоряем фильтрацию до 0,15 секунды, что в 53 раза быстрее.

Фасетный индекс — это специализированная таблица b_iblock_{ID}_index, которая предвычисляет связи значений свойств с элементами инфоблока. Вместо сложных JOIN при фильтрации Битрикс выполняет быстрый поиск по этой таблице, что сокращает время ответа с секунд до миллисекунд. На каталоге из 100 000 товаров с 8 фасетными свойствами запрос фильтрации укладывается в 0,15 секунды — это в 53 раза быстрее, чем без индекса.

Однако неправильное проектирование может свести эффект на нет. Типичные ошибки: включение строковых свойств (они не индексируются) или добавление всех свойств без разбора, что увеличивает размер таблицы и время пересоздания. Наша задача — отобрать только свойства, реально участвующие в фильтрации, и настроить стратегию обновления. Стоимость проектирования окупается за счёт роста конверсии и снижения нагрузки на серверы обычно в течение 2–3 месяцев.

Как устроен фасетный индекс изнутри

Фасетный индекс — это таблица b_iblock_{ID}_index, где для каждого свойства типа "Список", "Справочник" или "Число" хранятся пары FACET_ID (зашифрованный идентификатор значения) и ELEMENT_ID. Битрикс через API находит пересечения по выбранным фильтрам — без полного сканирования.

Код управления фасетом — в классе \Bitrix\Iblock\PropertyIndex\Manager. Ключевые методы:

• Manager::updateElementIndex($iblockId, $elementId) — обновить индекс для одного элемента
• Manager::runIndex($iblockId) — пересоздать индекс полностью
• Manager::deleteIndex($iblockId) — удалить индекс

При штатной работе сайта (через интерфейс) индекс обновляется автоматически через обработчик OnAfterIBlockElementUpdate. При массовом импорте из 1С этот обработчик не вызывается — нужно пересоздавать индекс вручную после завершения обмена.

Какие свойства можно добавить в фасет

Фасетный индекс поддерживает только свойства типов: Список (L), Справочник (S:HLBlock), Число (N). Строковые свойства (S) и привязка к элементам (E) не индексируются. Поэтому любое свойство, по которому нужна фильтрация, должно быть типа Список или Справочник, а не строка.

Проектирование стратегии фасетного индекса

Одиночный фасет vs. фасет торговых предложений

Для каталога без SKU — фасет строится на основном инфоблоке. Для каталога с торговыми предложениями — фасет на инфоблоке офферов, компонент фильтра настраивается с параметром OFFER_IBLOCK_ID. Смешивать нельзя.

Выборочное добавление свойств

Добавлять в фасет нужно только свойства, по которым пользователь фильтрует. Каждое дополнительное свойство увеличивает размер таблицы и время пересоздания. Признаки свойства, которое не нужно: заполнено менее чем у 5% элементов, используется только на карточке, не отображается в фильтре.

Фасет и множественные свойства

Множественное свойство (например, совместимые модели) увеличивает записи в N раз: 50 000 элементов × среднее 10 значений = 500 000 записей для одного свойства. Включать такие свойства нужно осознанно.

Оптимизация производительности

Время пересоздания индекса

Полное пересоздание для большого каталога может занимать минуты. Для каталога 200 000 элементов с 10 фасетными свойствами — от 10 до 30 минут. Битрикс не удаляет старый индекс до создания нового, поэтому фильтр продолжает работать.

Оптимизация: пересоздание в часы минимальной нагрузки, запуск через агент или CLI-скрипт:

$manager = new \Bitrix\Iblock\PropertyIndex\Manager($iblockId);
$manager->startIndex();
while (!$manager->continueIndex()) {}
$manager->endIndex();

Инкрементальное обновление

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

Кейс из нашей практики: фасетный индекс для агрегатора запчастей

Наш клиент — платформа с каталогом автозапчастей: 320 000 элементов, 18 свойств. Изначально в фасет добавили все 18, пересоздание занимало 2 часа и блокировало работу в админке.

Аудит:

• 6 свойств типа "Строка" — они не попадали в фасет, но платформа пыталась их индексировать
• 4 свойства заполнены менее чем у 3% элементов
• 2 множественных свойства с 15–20 значениями каждое

Оптимизация:

• Убрали строковые и редкие свойства
• Множественные свойства вынесли в отдельную HL-таблицу с индексом
• Итоговый фасет: 8 свойств

Результат: время пересоздания — 18 минут, фильтр по 5 свойствам — 0,15 секунды (в 53 раза быстрее исходного).

Что входит в работу по проектированию фасетного индекса

1. Аудит свойств каталога: типы, заполненность, участие в фильтре.
2. Выявление строковых свойств — кандидатов на перевод в Список/HL-блок.
3. Проектирование состава фасетного индекса (список свойств).
4. Схема стратегии обновления: инкрементально / пересоздание по расписанию.
5. Настройка фасета через административную панель или скрипт.
6. Тестирование производительности фильтра до и после.
7. Мониторинг времени пересоздания при штатном импорте.
8. Документация по фасетной схеме и рекомендации по поддержке.

Срок: от 2 до 5 рабочих дней для проектирования и настройки, плюс время миграции свойств (если нужно менять типы). Мы гарантируем стабильную работу фильтра и консультируем команду после запуска. Получите консультацию — мы проанализируем ваш каталог без предоплаты.

Почему фасетный индекс критичен для производительности?

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

Когда фасетный индекс не помогает?

Фасет не поддерживает строковые свойства и привязки к элементам. Если в каталоге такие свойства критичны для фильтрации, их нужно перевести в другие типы или использовать альтернативные механизмы (например, HL-блоки с индексацией). Также фасет неэффективен для свойств, которые заполнены менее чем у 5% элементов.

Наш опыт показывает: грамотное проектирование фасетного индекса на старте окупается в 10 раз — вы не тратите ресурсы на бесконечную оптимизацию позже. Если у вас тормозит фильтр — свяжитесь с нами, оценим проект за один день.