Как стать автором
Обновить

Комментарии 7

Недавно делал такое же, таким же способом. Прочитал по диагонали.
terms aggregation показывают кол-во товаров с текущим выбором фильтров. Но не показывают как изменится кол-во, если ты выберешь еще 1 значение value_N_M из набора property_N. Для опеределения что изменится нам надо выключить все value_N_M для property_N, сделать фильтрацию и посмотреть агрегации по property_N. И так для всех property_N, для которых мы в данный момент фильтруем.
Но думаю уйти от эластика и всеже переписать на SQL, толкьо ради фасеточного поиска держать elastic накладно. Посмотрю по экспериментам с производительностью.
Возможно, я не понял. Но именно эта проблема послужила основой для написания статьи. Для каждого фильтра нужно построить свое множество и на нем сделать агрегацию. Конструкция filter aggregation вместе с terms aggregation решают именно эту проблему.
Помоложим мы отфильтровали ТВ диагональю 52дюйма и получили что их 50штук, можем ли мы в агрегации получить информацию о том, что если мы дополнительно выберем 49дюймов, то кол-во телевизоров увеличится до 70? Насколько я вижу, в текущем запросе просто побиты на группы наши отфильтрованные элементы. Типа из 50 52дюймовых это 20 самсунг, 15 сони и 15 остальное.
> можем ли мы в агрегации получить информацию о том, что если мы дополнительно выберем 49дюймов, то кол-во телевизоров увеличится до 70

можем, будет именно так. 52, 49 -это термины, агрегация позволяет получить количество по каждому термину. В фильтре можно выводить значение и количество: 52 (50 шт), 49 (20 шт). Если 0, то фильтр блокирует значение или скрывает.

Я когда-то реализовал фасетный поиск при разработке каталога товаров для веб-магазина в реляционной базе данных, на основе паттерна EAV (Entity — Attribute — Value).


Краткое описание реализации для SQL Server можно посмотреть здесь: https://rsdn.org/forum/db/3566910.1 https://www.sql.ru/forum/789723/internet-magazin#9534088


Структура полностью нормализованная, никаких полей типа JSON, XML или BLOB.


Поиск по всем фильтрам, независимо от их количества, производится одним простым запросом с использованием реляционного деления, без дополнительных джойнов. Можно использвать условия OR, AND и их комбинацию.


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


Эта структура использовалась для реализации десятков (а может и сотен) веб-магазинов, в том числе с большим числом товаров (несколько десятков тысяч) и высоконагруженных (сотни запросов в секунду). С производительностью было все в порядке.

EAV не решит задачу полнотекстового поиска.

Нет. Но задачу фасетного поиска решает хорошо.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории