Фасетные фильтры: как готовить и с чем подавать

[abratko]

Возможно, я не понял. Но именно эта проблема послужила основой для написания статьи. Для каждого фильтра нужно построить свое множество и на нем сделать агрегацию. Конструкция filter aggregation вместе с terms aggregation решают именно эту проблему.

[abratko]

> можем ли мы в агрегации получить информацию о том, что если мы дополнительно выберем 49дюймов, то кол-во телевизоров увеличится до 70

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

[FlyingDutchman2]

Я когда-то реализовал фасетный поиск при разработке каталога товаров для веб-магазина в реляционной базе данных, на основе паттерна 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 таблиц. В их число также входят таблицы для организации древовидной структура каталога и использования нескольких языков для названий товаров и их свойств (в общем случае неограниченного числа языков).

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

[abratko]

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

[FlyingDutchman2]

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