Elasticsearch для поиска по каталогу Битрикс

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

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

Что такое Elasticsearch и зачем он каталогу

Elasticsearch — это поисковый и аналитический движок, построенный поверх библиотеки Apache Lucene. В отличие от реляционной базы, он изначально заточен под полнотекстовый поиск: хранит данные в виде документов JSON и строит по ним инвертированный индекс — структуру, которая для каждого слова (точнее, токена) знает, в каких документах оно встречается. Именно поэтому Elasticsearch отвечает на запрос «диван» не сканированием всех товаров, а мгновенным обращением к списку документов, где этот токен присутствует.

Для интернет-магазина на 1С-Битрикс это даёт несколько принципиально новых возможностей, которых у штатного поиска либо нет, либо они реализованы слабо:

• Морфология из коробки. Запрос в любой словоформе находит товар в любой другой: «диваны», «дивану», «диванов» ведут к «диван».
• Устойчивость к опечаткам. «телевизор» найдётся даже при вводе «телевизр» — за счёт нечёткого поиска по расстоянию редактирования.
• Синонимы и переформулировки. «холодильник» и «морозильник», «смартфон» и «телефон» можно связать словарём синонимов.
• Гибкая релевантность. Вес полей, буст по наличию, приоритет точных совпадений — всё настраивается в одном запросе.
• Фасеты и агрегации. Поиск и подсчёт «сколько товаров по каждому бренду и цене» возвращаются вместе с результатами.
• Скорость на объёме. Десятки и сотни тысяч SKU обслуживаются за десятки миллисекунд без нагрузки на основную базу.

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

Пределы штатного поиска 1С-Битрикс

Чтобы решение про Elasticsearch было осознанным, стоит честно понять, где именно упирается штатный поиск. Модуль search в 1С-Битрикс строит собственный полнотекстовый индекс в таблицах MySQL и использует встроенную поддержку морфологии на уровне словарей. Для небольшого и среднего каталога этого вполне достаточно, и городить отдельный кластер там незачем.

Проблемы начинаются с ростом каталога и требований к качеству выдачи:

• Скорость на объёме. Индекс модуля поиска живёт в тех же таблицах MySQL, что и остальной сайт, и на сотнях тысяч позиций полнотекстовые запросы становятся тяжёлыми, конкурируя за ресурсы базы с витриной и оформлением заказов.
• Ограниченное ранжирование. Тонко управлять весами полей, бустами по наличию, приоритетом точных фраз и коммерческими правилами штатный поиск позволяет слабо. В итоге сверху выдачи нередко оказывается не то, что нужно покупателю.
• Слабая работа с опечатками и синонимами. Нечёткий поиск и словари синонимов требуют доработок, а «из коробки» покупатель с опечаткой часто получает пустую выдачу.
• Индексация всего сайта. Модуль поиска исторически индексирует страницы и разделы целиком, а не документ-товар с нужными полями, что усложняет фасеты и точное ранжирование по свойствам каталога.
• Нет фасетов из поиска. Чтобы показать «сколько найдено по каждому бренду», приходится отдельно обращаться к каталогу и умному фильтру, а не получать агрегации вместе с результатом.

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

Архитектура связки Битрикс + Elasticsearch

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

• Инфоблоки каталога. Единственный источник правды по товарам, свойствам, ценам и остаткам. Здесь идёт обмен с 1С и вся привычная работа контент-менеджеров.
• Индексатор. Слой на стороне Битрикса, который превращает элемент инфоблока в поисковый документ JSON и отправляет его в Elasticsearch — по событиям и по расписанию.
• Кластер Elasticsearch. Хранит инвертированный индекс поисковой витрины, выполняет запросы, считает релевантность и агрегации.
• Поисковый сервис. Прослойка, которая принимает запрос пользователя, формирует к Elasticsearch тело запроса (морфология, буст, фасеты, пагинация) и разбирает ответ.
• Витрина. Компонент строки поиска, страница выдачи и подсказки, которые получают готовые данные от поискового сервиса.
• Слой деградации. Логика отката на штатный поиск Битрикса, если кластер недоступен, чтобы сайт продолжал работать.

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

Индекс, маппинг и токены изнутри

Чтобы настраивать поиск осознанно, важно понимать, что происходит внутри при индексации товара. Elasticsearch хранит данные в индексе — аналоге таблицы, но заточенном под поиск. Каждый товар превращается в документ — набор полей в JSON. Как именно движок разбирает эти поля, описывает маппинг (mapping) — схема индекса, аналог DDL в реляционной базе.

Маппинг для товара обычно различает два вида полей, и путаница между ними — источник половины проблем с поиском:

• Текстовые поля (text). Название, описание, бренд, ключевые слова. Они проходят через анализатор, разбиваются на токены и попадают в инвертированный индекс. По ним идёт полнотекстовый поиск с морфологией.
• Ключевые поля (keyword). Артикул, код бренда, идентификаторы категорий, значения для фасетов. Они хранятся как есть, без разбиения на токены, и годятся для точных совпадений, фильтрации, сортировки и агрегаций.
• Числовые и логические поля. Цена, остаток, вес, флаги «в наличии» и «новинка». По ним идут диапазонные фильтры и буст релевантности.

Частая практика — индексировать одно и то же значение сразу в двух видах через мульти-поле: название как text для поиска и как keyword для сортировки и точного совпадения. Так «Диван Осло» найдётся и по слову «осло», и отсортируется по алфавиту, и точная фраза получит буст.

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

Морфология и анализаторы русского языка

Морфология — то, ради чего чаще всего и внедряют Elasticsearch. Именно она превращает «диваны угловые» в находку «Диван угловой». За морфологию отвечает анализатор — конвейер обработки текста, который собирают из нескольких звеньев.

• Токенизатор. Разбивает строку на отдельные слова, отсекая пробелы и пунктуацию.
• Приведение к нижнему регистру. «Диван», «диван» и «ДИВАН» становятся одним токеном.
• Стоп-слова. Служебные слова («и», «в», «на») выбрасываются, чтобы не засорять индекс.
• Морфологический фильтр. Приводит слова к нормальной форме или основе — стеммингом или словарной лемматизацией. Для русского языка обычно подключают морфологический плагин или словарный анализатор.
• Синонимы. Отдельный фильтр подменяет или расширяет токены по словарю: «холодильник» ↔ «морозильник».

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

Отдельная тонкость — согласованность анализаторов. Иногда для поля задают разные анализаторы на индексацию и на поиск: например, при индексации раскладывают слово на N-граммы для поиска по части слова, а при запросе используют обычный анализатор. Это мощный приём для автодополнения, но требует аккуратности — рассогласование анализаторов приводит к тому, что товары «пропадают» из выдачи по, казалось бы, очевидным запросам.

Релевантность и ранжирование выдачи

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

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

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

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

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

Фасеты и агрегации в одном запросе

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

Работает это так: в одном запросе к движку вы передаёте и условие поиска, и список полей, по которым нужны фасеты. Elasticsearch возвращает и топ подходящих документов, и сгруппированные счётчики. Покупатель, набрав «диван», сразу видит: «синие — 42, угловые — 61, до 30 000 ₽ — 88». Клик по фасету добавляет фильтр к тому же поисковому запросу, и выдача с счётчиками пересчитывается мгновенно.

Здесь важно не путать два похожих механизма фасетов в проекте на Битриксе:

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

Автодополнение, подсказки и опечатки

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

• Автодополнение по префиксу. Пользователь ввёл «див» — движок предлагает «диван», «диван угловой», «диван-кровать». Реализуется через специальные поля-автодополнения или анализатор на N-граммах.
• Подсказки-товары. Помимо текстовых вариантов, в выпадашке показывают карточки конкретных товаров с ценой и картинкой — это работает как мини-выдача.
• Исправление опечаток. Механизм «возможно, вы имели в виду» подсказывает исправленный запрос, если по введённому мало или нет результатов.
• Нечёткий поиск. Поиск по расстоянию редактирования находит товар даже с одной-двумя ошибками в слове, не показывая пустую выдачу.

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

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

Синхронизация каталога и индексация

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

Обновление индекса ведут по двум контурам:

• Инкрементальная индексация по событиям. На события ядра Битрикса (OnAfterIBlockElementUpdate, OnAfterIBlockElementAdd, OnAfterIBlockElementDelete и события изменения цен/остатков) вешается обработчик, который ставит товар в очередь на переиндексацию. Так витрина остаётся свежей в течение дня.
• Полная переиндексация по агенту. Регулярное построение индекса целиком — обычно ночью после планового обмена с 1С, в часы низкой нагрузки. Оно гарантирует, что никакие изменения не потерялись, и восстанавливает индекс после сбоев.

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

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

Реализация в 1С-Битрикс

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

1. Разверните кластер Elasticsearch. Для боевого проекта — минимум три ноды с репликами шардов, отдельно от веб-серверов Битрикса. Настройте доступ по внутренней сети и закройте кластер от внешнего мира.
2. Спроектируйте маппинг документа-товара. Определите поля: название и описание как text с анализатором русского языка, артикул и коды как keyword, цена и остаток как числа, флаги наличия и акций. Продумайте мульти-поля для сортировки и точных совпадений.
3. Соберите анализатор. Настройте цепочку токенизации, нижнего регистра, стоп-слов, морфологического фильтра и словаря синонимов. Проверьте разбор типовых запросов вашей тематики.
4. Напишите индексатор. Модуль или скрипт, который читает элементы инфоблока (с ценами и остатками) и формирует документы JSON. Реализуйте пакетную полную индексацию и точечное обновление одного товара.
5. Повесьте обработчики событий. На события изменения товаров, цен и остатков поставьте постановку в очередь на переиндексацию, а фоновый агент пусть разбирает очередь порциями.
6. Настройте агент полной переиндексации. Ночью после обмена с 1С — полное перестроение через новый индекс и переключение алиаса, в часы низкой нагрузки.
7. Реализуйте поисковый сервис. Прослойка формирует запрос к Elasticsearch с морфологией, бустами, фасетами и пагинацией, разбирает ответ, при необходимости добирает актуальные данные из каталога.
8. Подключите витрину. Строка поиска с автодополнением, страница результатов с фасетами и обработкой пустой выдачи. Замените или дополните штатный компонент поиска своим.
9. Заложите деградацию. Если кластер не отвечает в отведённый таймаут, поиск автоматически откатывается на штатный механизм Битрикса и логирует инцидент.
10. Настройте мониторинг. Состояние кластера, время ответа, доля пустых выдач, ошибки индексации — всё должно быть на дашборде с оповещениями.

Elasticsearch, Sphinx и штатный поиск

Чтобы выбор был обоснованным, полезно поставить три подхода рядом. У каждого своя ниша, и «лучшего для всех» решения не существует — есть подходящее под масштаб и требования конкретного магазина.

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

Производительность и отказоустойчивость

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

• Шарды и реплики. Индекс делится на шарды, а реплики шардов дублируют данные на разных нодах. Реплики дают и отказоустойчивость (падение ноды не теряет данные), и параллельность чтения под нагрузкой.
• Минимум три ноды. Кластер из одной ноды — это не отказоустойчивость. Для боевого проекта нужна нечётная кворумная конфигурация, чтобы кластер переживал потерю ноды без split-brain.
• Разделение чтения и записи. Тяжёлую полную переиндексацию планируют на часы низкой нагрузки и делают порциями, чтобы она не конкурировала с пользовательскими запросами.
• Кэширование запросов. Частые одинаковые запросы (популярные слова, фасеты категорий) кэшируются на уровне движка и приложения.
• Таймауты и деградация. У запроса к кластеру должен быть жёсткий таймаут, а при его превышении — автоматический откат на штатный поиск, чтобы страница не «висла».

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

Метрики поиска и что измерять

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

Особенно ценна аналитика поисковых запросов. Топ запросов с пустой выдачей — это прямая инструкция, что чинить: добавить синонимы, поправить морфологию, завести недостающие товары или посадочные. Запросы с высоким объёмом и низким CTR подсказывают, где выдача нерелевантна и нужно править веса. Такой цикл «замерили → поправили → снова замерили» и превращает поиск из технической галочки в канал продаж.

Частые ошибки при внедрении

• Разные анализаторы при индексации и поиске — токены не совпадают, и очевидные товары «пропадают» из выдачи.
• Слишком агрессивный стеммер склеивает разные по смыслу слова и подмешивает мусор в результаты.
• Elasticsearch делают единственным источником данных по товарам — при сбое индекса теряется каталог, а не только поиск.
• Нет отката на штатный поиск — недоступность кластера роняет поиск на всём сайте вместо мягкой деградации.
• Забыли про переиндексацию после обмена с 1С — витрина расходится с реальными ценами и остатками.
• Индексацию вешают только на события и не делают полную ночную — пакетные операции проходят мимо, индекс копит рассинхрон.
• Кластер из одной ноды в бою — нет отказоустойчивости, падение ноды роняет поиск целиком.
• Слишком сильный коммерческий буст перекрывает смысл запроса — по слову покупатель получает не то, что искал.
• Автодополнение бьёт тяжёлым запросом на каждый символ без дебаунса — подсказки тормозят и раздражают.
• Кластер открыт в интернет без аутентификации — прямой риск утечки поисковой витрины.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность поиска перед запуском:

1. Кластер боевой. Минимум три ноды, реплики шардов, доступ только из внутренней сети и по учётным данным, мониторинг состояния настроен.
2. Маппинг спроектирован. Текстовые, ключевые и числовые поля разведены осознанно; мульти-поля для сортировки и точных совпадений заведены.
3. Анализатор согласован. Морфология русского настроена, при индексации и поиске используется совместимая цепочка, типовые запросы тематики проверены.
4. Релевантность откалибрована. Веса полей, бусты по наличию и приоритет точных фраз настроены, есть набор эталонных запросов для регресса.
5. Фасеты и подсказки работают. Агрегации питают фасетную панель, автодополнение лёгкое и с дебаунсом, пустая выдача обрабатывается.
6. Индексация двухконтурная. Инкрементальное обновление по событиям и полная ночная переиндексация через алиас настроены и протестированы.
7. Синхронизация с 1С учтена. После большого обмена индекс гарантированно перестраивается, лаг индексации в пределах минут.
8. Деградация заложена. При недоступности кластера поиск откатывается на штатный механизм и логирует инцидент.
9. Метрики собираются. Время ответа, доля пустых выдач, CTR и конверсия из поиска выведены на дашборд с оповещениями.

Вывод

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