А чем фацетный поиск принципиально отличается от просто view с большим количеством раскрытых фильтров?

Главные вкладки

Комментарии

Аватар пользователя bumble bumble 30 июня 2019 в 21:23
1

Принципиально - всем. Разные подходы, разные алгоритмы, разные источники данных (вероятно, даже, разное назначение).

Для фасетного поиска используется специально подготовленный индекс, обычные же фильтры представлений используют "голые" ("raw") данные из БД.

Если очень коротко - раскрытые фильтры подправляют запрос, в соответствии с введенными данными, а фасетные фильтры предоставляют вхождения для фильтрации, относительно текущей позиции выборки данных, и позволяет далее корректировать выборку по существующим вариациям.

Тут можно немного почитать. Ну и погуглить дальше, если интересно как все внутри работает.

Аватар пользователя marassa marassa 30 июня 2019 в 21:45

А я вижу больше сходств чем различий. Понятно, что "под капотом" разные источники данных, но для пользователя выглядит совершенно одинаково - множество фильтров по заданным атрибутам, позволяющих сузить выборку. Не вижу принципиальных противоречий между

подправляют запрос, в соответствии с введенными данными

и

позволяет далее корректировать выборку по существующим вариациям

Я могу понять зачем строить "специально подготовленный индекс" для текстовых полей/статей, где нужен быстрый поиск по ключевым словам, да ещё с учётом словоформ/падежей. Но не могу понять зачем его строить по полям "типу товара, марке, цене" (© wiki) - по этим полям уже есть вполне годные индексы в основной БД, если конечно ее проектировал не полный олигофрен.
У меня в базе практически нет текстов - только названия, имена, адреса, теги, перекрестные ссылки. Я уже готовился осваивать фацеты и вдруг понял, что не понимаю зачем они мне нужны, когда я могу всё что мне нужно реализовать на простых вьюхах. Поэтому и решил посоветоваться с более продвинутыми товарищами.

Аватар пользователя bumble bumble 30 июня 2019 в 21:55
1

В целом, все верно: если не нужен именно фасетный поиск - значит он не нужен.

Разница в том, что фасеты позволяют сделать выборку по только пересекающимся значениям, а обычные фильтры - просто выбирают информацию согласно введенным данным.

Вот картинка с вики, которая признана для визуальной передачи различий:

Еще раз, фасеты - это поиск постепенными уточнениями, обычные фильтры представлений - фильтрация условий выборки (читать добавление условий "WHERE *").

Аватар пользователя marassa marassa 30 июня 2019 в 22:18

Еще раз спасибо за терпение, но всё равно не очень понятно.
Сравнивать с "навигационным поиском" некорректно - я же не его предлагаю.
Возьмем пример прямо из вики - есть тип материала "товар", у него три поля: тип товара, марка, цена. Если верить вики - это классический случай для фасетов.
Я создаю вью по товарам с тремя раскрытыми множественными фильтрами - тип товара, марка, цена. В отображаемых полях товара вывожу еще и картинку.
Пользователь может выбрать в первом фильтре "телевизор", во втором "Philips, Sony", в третьем "< 50000р" и получить список товаров, удовлетворяющим заданным условиям.
Если то же самое сделать на фасетах, какие дополнительные плюшки получу я как разработчик и мой пользователь?
И, кстати, картинки в выводе легко будет добавить? Когда читал по диагонали документацию по фасетам, там что-то такое было написано, что поля можно выбирать только из серч-индекса, а там картинка вряд ли окажется.

фасеты - это поиск постепенными уточнениями, обычные фильтры представлений - фильтрация условий выборки (читать добавление условий "WHERE *")

Так добавление условий WHERE и есть способ постепенного уточнения.

Аватар пользователя bumble bumble 1 июля 2019 в 0:21
2

Пользователь может выбрать в первом фильтре "телевизор", во втором "Philips, Sony", в третьем "< 50000р" и получить список товаров, удовлетворяющим заданным условиям.

При фасетном поиске будет немного другой шаблон поведения:

  1. Шаг 1: Пользователю показаны все товары:
    • Блоки фильтров:
      • Тип товара:
        • Телевизор
        • Холодильник
        • Дилдо для попугаев
      • Марка:
        • Philips
        • Sony
        • Завод Красной Звезды
      • Цена:
        От: [10,099] до [50,489]
    • Товары (6 шт):
      • Телевизор Philips P12 - $21,548
      • Телевизор Philips P15 - $35,999
      • Телевизор Sony S22 - $30,099
      • Холодильник Philips C42 - $50,489
      • Холодильник Sony S2525 - $49,999
      • Дилдо для попугаев ЗКЗ Ы69 - $10,099
  2. Шаг 2: Пользователь отмечает фильтр "Тип товара" как "Телевизор":
    • Блоки фильтров:
      • Тип товара (только выбранное):
        • Телевизор
      • Марка (только пересечения):
        • Philips
        • Sony
      • Цена (только пересечения):
        От: [21,548] до [35,999]
    • Товары (3 шт):
      • Телевизор Philips P12 - $21,548
      • Телевизор Philips P15 - $35,999
      • Телевизор Sony S22 - $30,099
  3. Шаг 3: Пользователь отмечает фильтр "Марка" как "Sony":
    • Блоки фильтров:
      • Тип товара (только выбранное):
        • Телевизор
      • Марка (только выбранное):
        • Sony
      • Цена (только пересечения):
        От: [30,099] до [30,099]
    • Товары (1 шт):
      • Телевизор Sony S22 - $30,099
Аватар пользователя marassa marassa 30 июня 2019 в 22:44

Кажется понял - принципиальная разница в том, что при каждом клике динамически перестраиваются и доступные фильтры, и отобранные товары. То есть главная разница по сути - в динамике UI.

Аватар пользователя bumble bumble 7 июля 2019 в 20:46
1

То есть главная разница по сути - в динамике UI.

Если смотреть с т.з. UI, то да.
Но, для меня лично, главная разница в реализации поиска. На самом деле, можно наколхозить такую динамику и обычными фильтрами представлений, даже модули есть. Просто нужно понимать, что для получения относительно того же результата, нужно будет каждый раз проделывать приблизительно следующее:

  • загружать все сущности, согласно примененных фильтров
  • в цикле, читать значения по каждому зависимому фильтру и отбирать только существующие
  • делать еще одну выборку, уже по конкретному запросу (по страницам) и рендерить

И все это, проецируя на нашу много-джойновую систему хранения данных в Друпал, может давать весьма значительные оверлоады, вплоть до превышений времени загрузки, не говоря уже о скорости работы таких фильтров, на хоть сколько серьезно заполненной БД.

А фасеты, по индексу, сразу получают выборку кроссов, а при выносе в специализированные хранилища - еще и дают неплохой буст.

Вообще, лучше от задачи плясать, а не лепить фасеты или фильтры от балды.

Аватар пользователя gun_dose gun_dose 30 июня 2019 в 22:35
1

Во-первых, про индекс в корне неверно. Обычные раскрытые фильтры можно сделать и на Search API индексе.

Фасетный поиск сам по себе - это сужающаяся выборка, в которой возможные значения фильтра зависят от уже имеющихся результатов выборки. Это независимо от друпала, а вообще. То есть в двух словах, если есть фильтры по бренду и ОС, то при клике на эппл фильтр "андроид" пропадёт, не дав накликать критерии с нулевой выборкой.

Что касается фасетного поиска конкретно на друпале: очень важно понимать, что фасетные фильтры - это ссылки, а не форма. Поэтому после каждого клика по фильтрам идёт загрузка новых результатов.

Аватар пользователя marassa marassa 30 июня 2019 в 22:41

Фасетный поиск сам по себе - это сужающаяся выборка, в которой возможные значения фильтра зависят от уже имеющихся результатов выборки

Но я же в принципе могу это и на раскрытых фильтрах намутить - ограничить список доступных городов выбранной страной, если есть очевидная связь город->страна? Или тогда мои раскрытые фильтры превратятся в фасеты?

очень важно понимать, что фасетные фильтры - это ссылки, а не форма. Поэтому после каждого клика по фильтрам идёт загрузка новых результатов

Это существенно, да.

Аватар пользователя gun_dose gun_dose 30 июня 2019 в 22:47
1

Связь не всегда так однозначна. Например, бренд/диагональ экрана/цена и т.д. Пользователь может очень долго и вдумчиво задавать значения фильтра, а потом нажмёт применить и получит пустую выборку, потому что выберет параметры "эппл на андроиде ценой до 200$". С фасетами же такая ситуация невозможна в принципе.

Аватар пользователя bumble bumble 30 июня 2019 в 22:52

Во-первых, про индекс в корне неверно. Обычные раскрытые фильтры можно сделать и на Search API индексе.

Э, не... Это представление по индексу, что не есть "просто view с большим количеством раскрытых фильтров".

ЗЫ: Когда форма - тоже, каждый раз новая выборка и новые результаты. Данные фильтров - также, гетами формируются в урле. Ссылки вместо формы - исключительно условность реализации в друпал. Формами так же можно, просто париться больше чтоб правильный биндинг сабмитов настроить при работе на клиенте (в JS) и косяков не огребать с каждой темой.

Аватар пользователя gun_dose gun_dose 30 июня 2019 в 23:05

Представление по индексу - это тоже представление и раскрытые фильтры в представлении по индексу ничем не отличаются от таковых в любом другом представлении. Более того, ничто не мешает использовать раскрытые фильтры и фасеты одновременно.

Что касается формы - она всегда одна, если это не selective filters. Если есть магазин, где 50 товарных групп и 200 критериев фильтрации, то раскрытая форма как раз не подходит из-за того, что она всегда будет показывать 200 критериев. А фасеты будут показываться только те, что есть в текущей выборке.

Аватар пользователя bumble bumble 30 июня 2019 в 23:28
1

Ну, как не отличаются Lol
Давай разбираться что мы вкладываем в понятие "представление"...

Если это ГУЙня для накликивания списков отображаемых сущностей - то да, ничем не отличаются, вроде как. И здесь можно собрать, и тут.

Если это про принципы хранения и выборки данных для отображения - то отличаются, как раз тем что представления по индексу использует этот самый индекс (сорри за туфту) для выборки, а не тупо таблицы сущностей под которые настроены. Я представлял с этой стороны, т.к. вопрос был о принципиальных различиях, не думаю что ТС имел цель узнать различия в сборке представления из админки для вьюх по индексу и без.

И да, ничего не мешает вместе, и я думаю что не о том мы спор ведем, на самом деле Smile
Моя реплика была касательно того что ".. про индекс в корне неверно", в то время когда именно в индексе и есть различие между выборкой для фильтров обычных представлений (которые не по индексу), и для фасетов (которые используют тот самый индекс). И для этого я писал о нем (индексе).

А про пересечение критериев я чуть выше отписал ТСу. ИМО.

Аватар пользователя gun_dose gun_dose 30 июня 2019 в 23:42

Search API views - это всего лишь несколько плагинов для вьюса. Можно написать плагин для выборки вьюсом данных, скажем, из экселевской таблицы. От этого вьюс вюсом быть не перестанет.

Аватар пользователя Orion76 Orion76 1 июля 2019 в 7:20

Ну по сути получается, фасеты это
более юзерфрендли интерфейсы (меню вместо селектов-чекбоксов и т.п.)
+ индекс
+ текущее кол-во элементов в выборке для каждого доступного "критерия-фильтра"
и прочие аяксы.

Что там, что там условия выборки обычно(если не настроено иначе): ИЛИ в пределах терминов одного словаря, И - в пределах словарей, участвующих в выборке.