mongodb фасетный поиск.

с количеством товара больше 100 000

У мвидео столько товара нету =)

100 000 товара - это практически мгновенный поиск

Не знаю кто такие мвидео. Но большинство моих клинтов стартуют от 50 000. Причем тематики разные, от запчастей до шмоток

3-5 секунд не предел мечтаний. 100 000 это позиции у которой есть по пять различных модификаций. И не забываем о cpu

3-5 секунд не предел мечтаний. 100 000 это позиции у которой есть по пять различных модификаций. И не забываем о cpu

Так а в чем у тебя с монгой проблема-то?

Я с ней не работал. Счас изучаю вопрос. Собираю мнения.

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

А зачем для этого использовать саму СУБД? Почему не использовать тот же Solr? Вроде бы sphinx тоже это умел.

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

А есть боевой опыт? Почитал что эластик справляеться за милисекунды. Попробую с ним поиграться.

Да есть. Можно еще почитать http://highscalability.com/blog/2013/12/2/evolution-of-bazaarvoices-architect...

Вообще твоя задача это не SQL запросы гонять, а построить индекс для документов в виде хэшмэпа и дальше искать пересечения сетов в зависимости от id определенного атрибута товара.

Телевизор: { HD = 1, fullHD = 2, 4k = 3 } { 20" = 1, 24" = 2, 26" = 3 }

Дальше в бакеты по id параметра кидаешь id товара и считаешь пересечение по этим бакетам. Сложность поиска будет невелика, но расход памяти сильно увеличится.

А какой именно запрос тормозит? Скорее всего или сам запрос кривой или индексов не хватает.