{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Галя, у нас отмена! Или оптимизация поиска в каталоге для крупной retail сети

Сегодня retail выходит за рамки привычного нам оффлайн-магазина у дома. Всё больше эта сфера пользуется возможностями разработки, перенося свой бизнес в онлайн.
Сегодня хотим рассказать о, казалось бы, простом кейсе: настройка поиска в каталоге сайта. Но не всё так однозначно, как нам казалось на первом этапе. О том как простая задача превратилась в бег с препятствиями рассказал наш тимлид Андрей Д.

Наш заказчик: крупная федеральная retail сеть (NDA)

CMS: 1С-Bitrix

Цель: настроить оптимальный поиск в каталоге сайта

Задачи:

  1. Организовать сортировку результатов поиска по релевантности:

    Первые в списке отображаются товары, у которых все слова поискового запроса находятся в одной строке.

    Во-вторую очередь товары у которых все слова встречаются в разных свойствах, при этом должен учитывается "вес” свойства (об этом расскажем чуть ниже)

    В - третью - отображаются товары, у которых встречается меньшее количество слов из поискового запроса

  2. Сделать возможность поиска по следующим свойствам:

    Бренд

    Суббренд

    Вид товара

    Название производителя

    Страна производитель

  3. Организовать сортировку результатов поиска в соответствии с "весом" свойства. Вес свойства выстроен по приоритетам:

    Название - самый приоритетный

    Бренд

    Суббренд

    Вид товара

    Состав

    Название производителя

    Страна производитель

    Линейка

    Тип миксовой позиции

    Срок годности - наименее приоритетный

То есть, если мы введем в поисковый запрос “порошок “Альпийская свежесть” ”, то нам в поиске должен выйти сначала товар с ключевыми словами в названии, а только потом товары бренда “Альпийская свежесть”, т.к. коэффициент веса у названия выше, чем у бренда.

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

Заказчиком был определен инструмент, через который мы должны реализовать поиск - система полнотекстового поиска Sphinx. Главными преимуществами системы является высокая скорость поиска и индексации, высокая масштабируемость, поддержка стоп-слов и морфологического поиска.

Но самым главным плюсом, выбранного инструмента являлось то, что Bitrix заявлял поддержку Sphinx “из коробки”.

Реализация была поделена на этапы:

  1. Настройка Sphinx

  2. Настройка Bitrix и интеграция Sphinx

  3. Сдача проекта

Настройка Sphinx

Отказаться от Sphinx и перейти на другую поисковую систему нельзя. Требование заказчика - только эта система. Что ж, приступим.

Все поисковые движки “внутри” работают примерно по одному принципу:

  1. Забирают тексты
  2. Разбивают на отдельные слова
  3. Проводят стемминг слов - вычленяют основу слова
  4. Высчитывают вес фразы в тексте
  5. Возвращаем пользователю отсортированный согласно весу фразы поисковый запрос

Мы помним, что важная задача не только выдавать товары по соответствию слов в поисковом запросе, но ранжировать товары в соответствии с весом свойства.

Так вот, решение Bitrix и Sphinx “из коробки” - это добавить в индекс Sphinx только заголовок и весь текст из описаний и свойств товаров. То есть поиск будет возможен, но их вес не будет поддаваться контролю и ранжированию.

Для того, чтобы все же заставить Sphinx ранжировать товары, а не превращать свойства, описания товаров в кашу из текста нам пришлось настраивать Sphinx.

Этапы настройки Sphinx

Приложения могут взаимодействовать со Sphinx несколькими способами, но самым простым и удобным, является специальный sql-подобный язык запросов, который носит название SphinxQL. В этом случае Sphinx использует протокол базы данных MySql (которая используется у нас и единственный протокол который поддерживает битрикс).

Для этого мы:

  1. Создали новый индекс реального времени
  2. Описали наши поля и атрибуты для индексирования. При использовании баз данных в качестве источника необходимо явно перечислить все поля и атрибуты, которые мы собираемся индексировать. При этом необходимо указать их тип, название и дополнительные параметры, если они есть.

Настройка Bitrix

Теперь перейдем к настройке Bitrix. Вся работа с поисковым индексом происходит через промежуточные таблицы. Поэтому для начала мы создали столбцы для каждого нового свойства (бренд, суббренд, вид товара и тд).

А затем наполнили их, чтобы мы могли добавить их в индекс Sphinx. Для этого на моменте переиндексации товара добавили заполнение наших полей и скорректировали запросы на добавление\обновление данных в Sphinx.

После того как у нас описаны свойства, необходимо было задать коэффициенты веса каждого свойства.

Теперь Sphinx может проранжировать все свойства и выдать корректный ответ на поисковый запрос.

Что в итоге?

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

На данный момент решения работает, не мешает масштабировать каталог, адаптивно к изменениям и обновлениям.

0
Комментарии
-3 комментариев
Раскрывать всегда