Когда Elasticsearch не нужен: честный разбор для e-commerce на Bitrix

Я написал статью про то, почему Elasticsearch — это UX-инструмент, а не просто скорость. С тех пор три клиента спросили одно и то же.

«А нам точно нужен Elasticsearch?»

Честный ответ: не всегда. Иногда — вообще нет. Вот как понять, ваш ли это случай.

Начнём с одного числа

Сколько активных SKU на вашем сайте прямо сейчас?

Это не риторический вопрос. Это первый фильтр.

До 3 000 SKU — штатный поиск Bitrix с нормальными индексами решает задачу для большинства магазинов. Не идеально, но достаточно для конверсии. В проекте с 28k SKU мы перешли на Elasticsearch, и это дало +18% конверсии поиска. При 800 SKU тот же переход дал бы инфраструктурную головную боль без измеримого результата.

3 000–10 000 SKU — серая зона. Зависит от того, что именно ломается. Об этом ниже.

Больше 10 000 SKU с активными фасетами, синонимами и нагрузкой — Elasticsearch, скорее всего, оправдан. Хотя даже здесь нужно считать.

Что Bitrix умеет без Elasticsearch

Штатный поиск Bitrix работает через MySQL LIKE и полнотекстовый индекс. Это не позор. При правильной настройке это:

• точный поиск по артикулу и названию — работает нормально
• поиск по описанию — работает с FullText-индексом
• базовая релевантность — поддерживается, если настроить веса полей в админке
• скорость на малом каталоге — MySQL LIKE по индексированной таблице отвечает за 10–30 мс

Большинство магазинов до 3 000 SKU не реализуют даже эти базовые возможности. Проблема не в движке, а в том, что никто не занялся настройкой.

Первый шаг — не «поставить Elasticsearch», а посмотреть в лог поиска. Что именно ищут и не находят? Там обычно видно: большинство проблем решается правкой синонимов и весов полей, а не сменой движка.

Где штатный поиск ломается

Три сценария, где SQL реально не справляется, независимо от настроек.

Первое — опечатки и транслитерация. Пользователь пишет «самсунк» вместо «самсунг», или latinicej vmesto кириллицы. MySQL LIKE без дополнительного слоя это не обработает. Тут нужен либо Elasticsearch с fuzziness, либо препроцессинг запроса на стороне PHP. Второй вариант реальный, работает на малых каталогах.

Второе — морфология и синонимы. «Носки», «носков», «носочки» для MySQL это не одно слово. Bitrix частично решает это через встроенный морфологический анализатор, но на больших словарях синонимов он падает по скорости. При 200+ парах синонимов MySQL начинает тормозить.

Третье — фасеты под нагрузкой. 50 concurrent пользователей, каждый фильтрует по 5 атрибутам. MySQL с JOIN по таблицам свойств — это O(n) по каждому фасету. На 10k+ SKU это узкое место появляется быстрее, чем кажется. Elasticsearch денормализует данные и отвечает за 5–15 мс независимо от числа фасетов.

MySQL FULLTEXT как промежуточный путь

Между «просто LIKE» и «полноценный Elasticsearch-кластер» есть опция, которую редко рассматривают.

MySQL FULLTEXT с движком InnoDB — это нормальный полнотекстовый поиск. Поддерживает relevance ranking, булев режим, стоп-слова. Не требует отдельного сервера. Не требует синхронизации индекса. Просто работает внутри той же базы.

Для Bitrix это выглядит как перевод поиска с LIKE-запросов на MATCH ... AGAINST. Под нагрузку до 20-30 RPS на поиск это держит нормально.

Ограничения: нет fuzzy, нет сложных синонимов, нет агрегаций для фасетов. Но если у вас 5 000 SKU и нет морфологических проблем — это честный промежуточный шаг перед принятием решения по Elasticsearch.

Пять признаков, что Elasticsearch реально нужен

1. Поиск не находит то, что точно есть в каталоге — часто. Откройте лог нулевых результатов. Если там больше 15% от общего числа запросов, движок не справляется с морфологией или опечатками.

1. Каталог больше 10 000 SKU с активными фасетами. Время ответа на фасетный фильтр превышает 300 мс под реальной нагрузкой.

1. Нужен бизнес-бустинг. Хотите поднять в выдаче товары с высокой маржой, остатками или историей заказов — MySQL так не умеет. Elasticsearch с function_score решает это за пол-дня.

1. Автокомплит с задержкой < 100 мс. Строка поиска должна показывать живые подсказки прямо в процессе ввода. Это Elasticsearch Completion Suggester, не MySQL.

1. Нагрузка выше 50 поисковых RPS при сложных запросах. MySQL начнёт замедляться. Elasticsearch масштабируется горизонтально.

Итог

Elasticsearch — это не «лучший поиск». Это правильный инструмент для определённого масштаба задачи.

Каталог до 3 000 SKU, простые запросы, нет опечаток в критических сегментах: штатный поиск Bitrix с настройкой. Промежуток 3 000–10 000 SKU: смотрите на лог нулевых результатов и время ответа под нагрузкой. Если цифры нормальные, не трогайте.

Когда клиенты спрашивают «ставить Elasticsearch?», я обычно возвращаю другой вопрос: «А что конкретно сломано в поиске прямо сейчас?»

Если ответ «ничего, просто хотим как у Amazon» — это не про Elasticsearch. Это про приоритеты.

Если ответ «вот лог, вот нулевые результаты, вот время ответа» — тогда разговор предметный. И часто выясняется, что проблема решается за день настройки MySQL, а не за месяц внедрения Elasticsearch.

Поиск на сайте без Elasticsearch — это не компромисс. Это правильное решение для большинства магазинов.