Подход (алгоритмы и тд) чтобы сделать поиск по параметрам как на Яндекс-маркете?

Question

[blackstone]

Здравствуйте!


Хочу спросить у опытных людей каких образом можно сделать универсальный поиск по базе продуктов как на Яндекс-маркете.


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


Т.е. мы имеем разнотипную продукцию с разными характеристиками — это могут быть:

— числовые характеристики (диапазоны и тд);

— выбор из справочников множественный;

— выбор из справочников одинарный;

— разные единицы измерения;

— другие типы критериев.


Довольно интересный был вводный топик о подходящем использовании для такой задачи MongoDB MongoDB или как разлюбить SQL — там как раз пример Яндекс-Маркета приводился, но тема не была до-конца раскрыта.


Также подскажите — может я замахнулся на слишком сложную идею, которую не под силу реализовать одному человеку за разумное кол-во времени? Тогда придется упростить задачу и не гнаться за универсальным решением?


Наверное я не первый об этом задумался?

Answer 1

[Александр]

Также подскажите — может я замахнулся на слишком сложную идею, которую не под силу реализовать одному человеку за разумное кол-во времени?

начни с минимума, потом поймешь чего не хватает!
главное запуститься, доработаешь в процессе. Я тоже упростил поиск до (разумного) минимума.

Answer 2

[Искандер Гиниятуллин]

Вообще ваша задача как я понял это т.н. фасеточный поиск. en.wikipedia.org/wiki/Faceted_search
Когда передо мной стояла такая проблема я решал ее таким образом: есть таблица «товаров», в которой все товары.
Есть справочник «характеристик».
Есть таблица в которой идут тройки id товара — id характеристики из справочника — значение
Вся эта база индексируется сфинском. Далее делается примерно как описано в статье: habrahabr.ru/blogs/sphinx/64318/

Т.е. сначала например пользователь делает поисковый запрос «телефоны samsung». Одним запросом к базе данных мы выводим все телефоны, а используя группировку по id характеристики получаем все характеристики, которые возможны для этих товаров: т.е. например диагональ экрана, операционная система, ну и потом выбираем для каждой характеристики возможные значения, подходящие под запрос. Благодаря мульти-запросам такой поиск работает довольно быстро.

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

Comments

[Александр]

это все правильно но вот запрос Мониторы Sumsung 21"

[Искандер Гиниятуллин]

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

main_cat | sub_cat | name | desription | properties
Мониторы | LCD | Samsung Z2109 | LCD монитор в серебристом корпусе | Диагональ: 21"; Формат 16:9; и т.д.

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

Сфиксу просто даешь запрос «Мониторы Samsung 21» — он найдет эту запись

Также для запросов к определенным категориям можно писать «помощников» — например если сфинкс нашел по запросу пользователя только товары из категории «мониторы» то можно попробовать распарсить запрос — найти диагональ (\d)" и т.д. и за счет этого уточнить поиск

[Александр]

я это решал иерархическими запросами к Сфинксу.
параметры вытягивал полным поиском, а мониторы и Samsung отсекал аттрибутами.

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

конечно — если есть таблица с параметрами — то все решается проще.

[Искандер Гиниятуллин]

А я не основные, все параметры туда клал и не парился. Просто вес поставил параметрам пониже, а категориям и названию повыше

Answer 3

[Aleksey]

Советую обратить внимание на Apache Solr. Ключевая функциональность требуемая для такого ресурса — фасетная навигация. Apache Solr поддерживает различные фильтры/фасеты по числовым диапазонам (цены), датам, категориям/тэгам (множественные значения) и тд. Все фильтры кэшируются в памяти в ввиде битсетов. В дополнение ко всему отличный полнотекстовый поиск, подсказки правописания, возможность поиска схожих документов-товаров по описанию основанное на tf*idf которое дает высоко релевантные результаты, распределенный поиск, шардирование, репликацию и многое другое. Apache Solr используется весьма известными сайтами поиска товаров типа zappos, cnet и пр.

Answer 4

[Антон]

Я дела так:
Таблица 1: Товар
Таблица 2: Категории для товара
Таблица 3: Названия параметров
Таблица 4: Связка Параметров к категориям (При выборе у товара категории подгружаю соответствующие параметры)
Таблица 5: Связка — Значение параметра с конкретным товаром (id, id_item, id_param,var_param)
Таким образом мы параметры вешаем на категорию, при добавления товара выбираем категорию и получаем набор параметров для этой категории.

Чем мне это нравится:
1) Любая вложенность категории со своими параметрами.
2) Можно делать динамическую форму поиска в который давать выбирать параметры в зависимости от категории.
3) Легкие небольшие запросы.

Comments

[Антон]

Кстати название параметров в виде дерева. Это даем возможность давать параметру значения типа выпадающий список с готовыми вариантами.

Answer 5

[antonlustin]

а чем не устраивает генерация запроса в зависимости от выбранных фильтров?

Comments

[blackstone]

Дело не в генерации запросов, а в гибкой настройке самих фильтров в зависимости от атрибутов продукции — автоматическом создании фильтров с нужными виджетами.

Генерация запроса — это уже второе дело.

[Александр]

у меня был проект типа Афиша, там фильтры автоматически генерировались в зависимости от раздела каталога.

есть таблица параметры,
есть таблица параметры2каталог
есть таблица объект
есть таблица параметр2объект
есть таблица объект2каталог

вот такая вот карусель…

[Александр]

есть еще таблица Значения привязаная к тбл Параметр и Объект

Answer 6

[bagyr]

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

Comments

[TimTowdy]

Простите, но каким образом задача хорошо ложится на РБД? Подобная задача — это как раз каноничный пример, который неплохо решается schemaless nosql.
В РБД придётся либо делать сотни таблиц, для хранения каждого типа объекта, либо использовать не очень-то производительную EAV.

[KLUBS]

а почему EAV не очень производительная?

[bagyr]

Ну да, по таблице на тип данных и имел в виду. О «сотнях» речи не было.

[TimTowdy]

а почему EAV не очень производительная?

Вкратце: невозможность построения эффективных индексов, чтение объектов не блоками, а полями, монструозные запросы с большим количеством посредственно оптимизированных джойнов.

[Александр]

задача явно не для РСУБД, по крайней мере в классическом их выражении.
в результате получатся трехэтажные малопроизводительные запросы, все это мы уже проходили

[Александр]

все это выльется в маленького монстрика, см мой комментарий на пост выше.
При нагрузки 5К монстрик начнет загибаться, а при 10 — протянет ножки.

Answer 7

[Александр]

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

Основные идеи по структуре хранения:
— есть товары (спецификациии)
— есть предложения (данные от магазинов)
— есть модели
-есть каталог

Все предложения от магазинов привязаны к спецификациям и/или к моделям.

Запускается робот, который анализирует названия товаров и принадлежность их к категориям и привязывает их к моделям. В зависимости от того, как поработают эти роботы — будет построен хороший индекс, и соответственно качественный поиск.

И еще не забываем, что в ЯМ — есть куча контент-менеджеров, которые редактируют «спецификации товаров» и сильно облегчают «жизнь роботов».

Основные идеи поиска:
— строим индекс по каталогу, названиям, моделям,
-на каждый индекс делаем по запросу.
— в зависимости от полученных результатов делаем соответствующие вывод
— делаем анализ взаиморасположения поисковых слов
— параметры проходят полнотекстный поиск.

Честно говря я хотел пож этот проект сделать свой поисковик, но сил не хватит. Сперва надо запустить со Сфинксом.

Поддерживаю идею MongoDb как средство хранения информации и быстрого ее извлечение. C использованием MongoDb может быть маленькая проблема (кроме ограничения на размер данных в 2 Гб для 32 бит Ось ), которая выльится в большой геморой: пока индексатор Сфинкса на нее не написан. Я тоже собирался ее использовать, но пока остановился на мускуле.

На последней PHPConf был хороший доклад про использование Сфинкса по поиску миллиона товаров dostavka.ru ( у меня сайт агрегатор — было 2 миллиона) Видео есть на сайте PHPConf

Comments

[TimTowdy]

Под большим геморроем вы подразумеваете xmlpipe? Скрипт, который кормит сфинкс объектами из монго будет состоять из нескольких строчек.

[Александр]

надо еще эти объекты правильно подготовить

Answer 8

[ZOXEXIVO]

MongoDB 3.4 поддерживает Faceted search