Comments 11
Скажите, а на сколько большой у вас каталог? По тексту было что-то про in-memory.
Правильно ли я понимаю, что у вас "плоская" структура каталога? Или же продукты могут иметь иерархическую связь? Если есть иерархия - то как вы на Elasticsearch работаете с этим? На сколько знаю он в это плохо умеет.
И вы все еще на Elasticsearch или на Opensearch перешли?
Присоединяюсь к вопросу. Много звучит выражений вроде "проект немаленький", но никакой конкретики. Хочется понятных цифр:
1) в каталоге N товаров, M категорий, L свойств, K атрибутов,
2) бэкенд сайта написан на языке Бейсик (подставьте свой язык), работало на серверах вот в такой конфигурации.
Потому что минимальные требования Эластика известны, и они немаленькие.
( я спрашиваю потому, что имел некоторое отношение к некоторым интернет-магазинам, с десятками брендов. И там места для Эластика почему-то не нашлось)
минимальные требования Эластика известны, и они немаленькие
Это налог на незнание о GIN и tsquery в PG
Согласен, цифр не хватает. Исправиляюсь :) Параметры каталога:
Около 20К товаров
Около 200К вариантов
Около 700 подборок. Многие из них имеют довольно большое количество фильтров, самое большое - на данный момент аж 194
Атрибутов порядка 150
Значений атрибутов порядка 50 тысяч
Конечно это довольно скромные цифры, все-таки мы не Мвидео, а магазин одежды )
Бек написан на PHP/Laravel, Эластик на одном инстансе (размещение облачное), на данный момент 12 ядер и 12 гигов памяти, но это с запасом: сейчас низкий сезон, и нагрузка даже в пиках не превышает 30%.
Rps чисто на каталог товаров - около 150.
Горизонтально не скалировали. На Opensearch пока тоже не переходили.
По размеру каталога ответил выше. Что касается иерархических данных: в определенном смысле иерархия есть - варианты являются подмножеством продуктов. И сложности, связанные с этим, в статье я тоже привел. Да, они есть, но работать с этим вполне можно.
Да, меня тоже интересуют цифры: rps, latency, количество sku, количество и параметры машин эластика, количество шардов и реплик индекса.
Я тоже работаю с эластиком в качестве хранилища денормализованых данных каталога товаров. Время поиска конечно относительно неплохое, но не могу сказать что сопоставимо с редисом.
Но проблемы ведь все еще есть?
Из написанного вижу еще 2 проблемы:
1.
Получаем из эластика пагинированные id карточек, отвечающие условиям фильтра (запрос приведен ниже)
Задача на полнотекстовый поиск есть? Если есть, получается он не работает? Если работает, то из статьи совсем не понятно, как это происходит.
2.
Конечно мы не избавились от использования реляционной базы полностью, но вынесли за ее пределы наиболее нагруженную часть – непосредственно фильтрацию.
Выглядит так, что значения фильтров не меняются в зависимости от запроса. Т.е. фильтрация может выдать пустое множество. Тогда предстоит реализовать еще и фасетный поиск. Если нужно, то алгоритм есть здесь https://habr.com/ru/articles/517074/
@Vladimir_ch_dev посмотрел befree.ru. Об этом же сайте речь? Там есть полнотекстовый поиск и фасетные фильтры.
можете рассказать на чем ни сделаны, если вы раньше не использовали Эластик? хотя бы в 2-х словах.
Полнотекстовый поиск - это отдельная история, по которой можно написать отдельную статью. Здесь это сознательно оставлено за рамками, и в момент реализации описанного функционала такая задача еще даже не стояла. Сейчас пользуемся для этого сторонним сервисом (хотя лично я конечно от такого решения не в восторге :)) Если запилим свой - напишем
Фильтры для пользователя - тоже отдельная история. Они у нас есть, и пока они работают как и раньше на скуле покрытые кешем с прогревом для топа регионов, и их мы на эластик еще даже не перенесли. Поэтому я описал фильтры только со стороны того, как они используются при формировании подборок.
Спасибо за статью!
Ускоряем каталог интернет-магазина с помощью Elasticsearch