Быстрый умный фильтр и поиск на Битрикс для больших каталогов

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

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

Что именно тормозит и как мы это лечим

Мы разбираем умный фильтр и поиск по слоям и оптимизируем каждый из них. Сначала диагностируем медленные запросы фильтра и поиска: смотрим план выполнения, объём данных, наличие фасетного индекса и его актуальность. Затем перестраиваем фасет так, чтобы он покрывал реальные свойства каталога и пересобирался по событию, а не вручную. Тяжёлый полнотекстовый поиск с морфологией выносим в Elasticsearch или Sphinx, которые специально заточены под такие задачи и отдают релевантную выдачу с подсветкой и подсказками за десятки миллисекунд. Поверх настраиваем кеширование фильтра, чтобы повторные запросы вообще не доходили до базы.

Основные узлы, которые мы оптимизируем:

• фасетный индекс умного фильтра — полнота свойств, актуальность и автоматическая пересборка по событию;
• полнотекстовый поиск с морфологией, опечатками, синонимами и релевантной сортировкой выдачи;
• внешние движки Elasticsearch и Sphinx для поиска и агрегаций по большому каталогу;
• автодополнение и живые подсказки в поисковой строке с мгновенным откликом;
• агрегации и счётчики доступных значений фильтра без тяжёлых запросов к базе;
• кеширование результатов фильтра и поиска с корректным сбросом при изменении данных.

Когда нужна оптимизация фильтров и поиска

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

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

Что даёт перенос на Elasticsearch и Sphinx

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

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

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

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

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

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

Где проходит граница между Sphinx и Elasticsearch

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

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

Как мы выбираем решение под каталог

Мы никогда не начинаем с движка — мы начинаем с замеров. Первым делом снимаем медленные запросы фильтра и поиска, смотрим план их выполнения, оцениваем объём каталога, число свойств в фильтре, наличие и актуальность фасетного индекса, качество текущей выдачи. На основе этих цифр становится видно, где узкое место: иногда достаточно перестроить фасет и настроить кеш, и фильтр перестаёт тормозить без всякого движка. Иногда фасет в порядке, но поиск отдаёт пустые выдачи из-за морфологии — тогда нужен Sphinx. А иногда каталог огромен, а нагрузка на базу критична — тогда оправдан Elasticsearch с агрегациями.

Такой подход бережёт ваш бюджет и сопровождение. Нет смысла поднимать тяжёлый кластер Elasticsearch там, где задачу решает пересборка фасета за неделю. И наоборот, нет смысла бесконечно тюнить фасет на каталоге, который давно перерос реляционную базу. Оптимизация фильтров и поиска — это часть общей работы над скоростью каталога, поэтому мы смотрим на неё в связке с остальными узкими местами. Нередко она идёт вместе с оптимизацией каталога на 100 тысяч — 1 миллион товаров, где фильтр и поиск — лишь одна из точек роста наряду с выборками, кешем и базой.

Что важно сделать правильно при переносе на движок

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

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

Как мы держим базу разгруженной

Один из главных эффектов переноса поиска на движок — разгрузка основной базы. Пока поиск и агрегации считаются в реляционной базе, они конкурируют за неё с заказами, корзинами и оплатами. В пик, когда десятки пользователей одновременно крутят фильтр и ищут товар, очередь тяжёлых запросов кладёт не только каталог, а весь сайт. Когда поиск уходит на Elasticsearch или Sphinx, поисковая нагрузка живёт отдельно от транзакционной: база занимается заказами, движок — поиском. Это та же логика, что и при выносе других тяжёлых операций — например, при комплексном ускорении каталога и e-commerce, где разгрузка базы идёт сразу по нескольким направлениям.

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

Возражения, которые мы слышим чаще всего

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

«Внешний движок сложно поддерживать». Sphinx в обслуживании очень лёгкий, а Elasticsearch требует внимания, но мы закладываем сопровождение и автоматическую переиндексацию с первого дня, поэтому в ежедневной работе движок не требует ручного труда. Мы передаём документацию и настройки, так что развивать решение сможет как наша команда, так и ваши специалисты.

«Боимся, что после обновления Битрикса всё сломается». Логику поиска и интеграции с движком мы выносим в собственные модули и обработчики, не правя ядро напрямую. Поэтому обновления платформы проходят без конфликтов, а ваше решение по фильтру и поиску продолжает работать. Это закладывается в архитектуру с самого начала и снижает стоимость поддержки в будущем.

Сценарии, под которые мы настраиваем поиск

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

Для B2B-каталогов на первый план выходит нагрузка и агрегации: десятки менеджеров и клиентов одновременно крутят фильтр по огромному ассортименту, и без переноса счётчиков на движок база не выдерживает. Для маркетплейсов и агрегаторов критична релевантность и аналитика поисковых запросов, потому что от качества выдачи напрямую зависит, дойдёт ли покупатель до товара среди миллионов позиций. Мы не натягиваем один шаблон на все каталоги, а собираем поиск под вашу модель: где-то достаточно точного фасета, где-то нужен полнотекстовый движок с тонкой настройкой ранжирования под бизнес-приоритеты.

Чем оптимизация выгоднее альтернатив

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

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

Что вы получаете по итогу

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

Начните с разговора и бесплатной диагностики. Расскажите о вашем каталоге — объёме, числе свойств в фильтре, том, как сейчас работают поиск и фасет, — и мы снимем замеры, найдём узкие места и предложим решение под вашу задачу: пересборку фасета, Sphinx или Elasticsearch. По итогам диагностики вы получите честную картину, что даст наибольший эффект и за какой срок окупится. Обсудим ваш проект — и сделаем подбор товара в каталоге мгновенным.