Создание поиска на сайте стало обычной необходимостью, прежде всего, для удобства пользователей. Но не у всех компаний он безупречно справляется с запросами клиентов, что, в свою очередь, приводит к потере потенциальных покупателей.
По данным ratingruneta, большая часть ecommerce в России сделана на базе 1С-Битрикс. Но насколько бы ни была прекрасна и ужасна данная система, у штатного поиска существуют проблемы и ограничения, а ростом проекта проблемы усугубляются.
В этой статье мы расскажем о нашем опыте улучшения поиска Битрикса с помощью внедрения Elasticsearch.
С чего начали
Наш заказчик - это один из крупнейших российских гипермаркетов автохимии и средств по уходу за автомобилями. Существует на рынке уже более 10 лет.
Сайт клиента работал на штатном поиске, в выдаче присутствовали только товары каталога. Поиск не видел весь контент и не мог вывести в результатах больше вариантов. Это ограничивало пользователей.
Задачи
На основе запросов клиентов были сформированы требования для нового поиска, среди которых:
-
Внедрить поиск, поддающийся гибкой конфигурации (синонимы)
-
Отдельный поиск по бренду
-
Отдельный поиск по разделам
-
Совместить поиск по простым товарам и торговым предложениям
-
Поиск по неточным соответствиям
Выбор инструмента для решения
Встроенный поиск изживал себя, поэтому от его доработки отказались. Saas решения также использовать не хотелось, потому что это не очень гибко плюс постоянная абонентская плата. В итоге выбор встал между Sphinx и Elasticsearch.
Sphinx (англ. SQL Phrase Index) — система полнотекстового поиска. Интегрирует с существующими СУБД (MySQL, PostgreSQL) и API. Из преимуществ Sphinx можно выделить быструю скорость индексации, которая необходима, когда нужно проиндексировать большой объем документов. А также Sphinx менее требователен к ресурсам.
Elasticsearch, в свою очередь, - это очень удобное и богатое API. Представляет собой поисковый и аналитический механизм на базе Apache Lucene. Разработан на языке Java, распространяется по лицензии SSPL (англ. Server Side Public License). Самый популярный поисковый движок с 2010 года.
Поскольку база у нас относительно небольшая, не более 20 тысяч товаров, и были ресурсы по серверу, мы остановились на Elasticsearch. Вот ряд факторов, которые повлияли на окончательное решение:
-
Инструмент обеспечивает высокую скорость выборки, быструю выдачу результатов.
-
Поиск учитывает опечатки.
-
Товары ранжируются с выдачей рекомендаций, новинок и товаров с акциями.
-
Elasticsearch совмещает поисковый движок и базу данных, которая создана для создания товарных категорий. С его помощью можно настроить полнотекстовый поиск без замедления сайта. Выборки документов осуществляются по совпадению имен или текстовое содержимое.
-
Возможность работать с различными типами данных как со структурированными, так и неструктурированными.
-
На практике Elasticsearch часто используется для 1С-Битрикс при множестве выборок. В систему вносится товар, который связан с торговым предложением. Тот, в свою очередь, содержит определенные атрибуты: цены, акции, скидки, персональные предложения.
-
Данные не теряются при отказе серверов. Поиск продолжит работу без сбоев.
Рассмотрим на примере
Интернет-мaгaзин заказчика разработан на базе Битрикс В каталоге содержатся как простые товары, так и товары с торговыми предложениями. Объяснить разницу между ними проще на примере:
Несколько простых товаров: Красное платье Sofi, Синее платье Sofi, Черное платье Sofi.
Один товар Платье Sofi с торговыми предложениями: Красное, Синее, Черное.
Варианты внедрения
У Elasticsearch как у продукта существует несколько вариантов внедрения:
-
облачное решение;
-
коробочное решение.
Ближайший сервер облачного решения находится в Амстердаме, что дает задержку примерно в 1,5-3 секунды на запрос. Нам показалось этого много, и мы решили использовать коробочное решение. К слову, облачный вариант доступен только по подписке.
Коробочное решение можно разделить на 2 продукта:
-
Enterprise;
-
Elastic App Search.
По сути, это две части одного коробочного варианта, но в первом случае вам придется полностью настраивать логику запроса и выборки данных. Это довольно непростой путь и нужен в особых случаях.
Мы же рекомендуем использовать App Search. Это тот же Enterprise, в котором встроены предустановки по поиску от инженеров Эластика. Если ваш проект не обладает очень специфичной базой, этот продукт покажет более высокую точность.
Внедрение в Битрикс
Со стороны сайта клиента требуется сделать три вещи:
Первое. Внедрить обработчик для сборки индексов. Это нужно для того, чтобы записать те данные, по которым планируется поиск в саму систему. Довольно гибко настраивается и удобно работать.
Также в App Search встроена функция веб-краулера, которая позволяет собрать по ссылке на сайт весь имеющийся контент. Вариант рабочий, но данных будет больше, чем нужно, к тому же грязных.
Второе. Написать API, которое будет отправлять запросы в Elastic для получения данных.
Третье. Переделать вывод, чтобы данные поступали не из Битрикса, а от Эластика.
Отдельно стоит упомянуть про функционал синонимов, который поставляется от Elastic. Туда были размещены кейсы, связанные с неправильным написанием брендов или аналогичных “сленговых названий”.
Сбор данных для поиска
Наиболее важной частью является индексирование проекта, так как правильный подход к построению индексов решает много проблем.
В рамках нашего примера поиск должен был выдавать три типа контента - товары/торговые предложения, разделы и бренды. Поэтому под каждый был создан отдельный индекс.
Наиболее простое - это разделы, у них есть только название и описание. С брендами ситуация аналогичная, они имеют лишь пару дополнительных свойств.
Трудности вызвала работа с товарами. Так как часть ассортимента обладает торговыми предложениями (размер, цвет, запах и т.д), в поисковой строке должны были присутствовать именно предложения. Если у товара есть торговые предложения, в базу данных поиска записываются только предложения, если торговых предложений нет (товар является простым), то в базу пишется только товар.
Для обоих видов товара индексируется само название, бренд, артикул, описание и теги.
Описание процесса
Порядок работ можно описать следующим образом:
-
Настройка сервера
-
Планирование способов импорта данных
-
Настройка процесса ввода дополнительных справочных данных
-
Настройка поисковой индексации
-
Внедрение
Управление
Вместе с коробочным решение поставляется Kibana. Выполняет роль бэк офиса для управления поиском.
Kibana – инструмент, который используется для визуального анализа. Проиндексированная в кластере Elasticsearch, информация представляется в виде диаграмм различных типов:
-
столбчатые;
-
линейные;
-
точечные;
-
круговые;
-
а также возможна визуализация данных в привязке к географическим картам.
Интерфейс Kibana из коробки состоит из ряда ключевых блоков:
-
Дашборд, на котором собрана краткая информация по всем разделам.
-
Аналитика. Представляет 4 блока наиболее полезной информации - “популярные запросы”, “популярные запросы без результатов”, “аналитика кликов”, “популярные запросы без кликов”.
-
Документы. Содержит все проиндексированные документы, возможны 3 варианта загрузки - сканер, json, API.
-
Схема - структура хранимых документов.
-
Веб-сканер - обходчик сайтов для сканирования документов.
-
Настройка релевантности. Установка точности поиска и регулировка по отдельным полям.
-
Синонимы - очень полезный функционал, который позволяет уточнить поиск объединяет слова с синонимами.
-
Курирования - то же самое, что синонимы, но сужает выдачу.
-
Настройки результатов - позволяет поэкспериментировать с выдачей на лету.
-
Интерфейс поиска - готовый кит дня внедрения на сайт, можно загрузить архивом.
-
Журналы API - логи API.
Результат
-
В итоге была снижена нагрузка на сервер сайта, ускорена его работа. Данные обновляются оперативно.
-
Реализован полнотекстовый поиск, который учитывает особенности языка и возможные опечатки.
-
Реализован раздельный поиск по товарам, разделам и брендам.