Оптимизация категоризированного поиска товаров

Sheehave

Новичок
Добрый день.

Столкнулся с проблемой скорости загрузки страниц на каталогах подарков http://begift.ru/ и http://begift.com.ua/ На сайте каждый товар имеет ряд параметров, которые его характеризуют. Параметры, в свою очередь, разбиты по категориям. Например, товар: цветы имеют параметры «Праздник» – 8 Марта, 14 Февраля… и «Кому подарить»: Маме, Жене, Девушке и т.д. Пользователь может свободно комбинировать параметры, на основе которых ему показываются подходящие товары. Пытаюсь оптимизировать данную страницу, поскольку время генерации составляет неприличные 10-15 сек: http://tools.pingdom.com/fpt/#!/cmMCQJ/http://begift.com.ua/chto-podarit-na-novyj-god-iz-igrushek/

Подбор товара осуществляется алгоритмом: параметры внутри категории объединяются оператором ИЛИ, сами категории – оператором И. Страница, кроме основного списка, показывает также количество подарков, которое будет получено путем комбинирования уже выбранных и дополнительных параметров. Этот расчет также происходит по тому же алгоритму. Таким образом, мы имеем около 30 таких выборок на каждую загрузку страницы. В большинстве случаев используем подготовленные запросы, но для таких страниц запрос полностью генерируется в php коде вместе с параметрами. Он довольно объемный и плохо оптимизируется с самой базой. Я уже реализовал кэширование (сохраняя результаты всех вычислений для каждой страницы) на стороне сервера. Так как стоимость товара и его наличие обновляется, то этот кэш нужно обновлять раз в 1-2 дня. Страниц около 3000, если кэшировать каждую каждый день, то только на кэширование уйдет 10 часов.

Хочу провести сравнительные тесты разных альтернативных алгоритмов. Возможно, у кого-то есть опыт в таких задачах. Буду благодарен за совет.
 

fixxxer

К.О.
Партнер клуба
Использовать любое решение с инвертированными индексами. Postgresql+GIN/GIST, ElasticSearch, SphinxSearch, на худой конец - генерировать "псевдослова" для параметров и mysql fulltext.
 

Sheehave

Новичок
Использовать любое решение с инвертированными индексами. Postgresql+GIN/GIST, ElasticSearch, SphinxSearch, на худой конец - генерировать "псевдослова" для параметров и mysql fulltext.
Спасибо, о готовых решения раньше не думали. Посмотрим что они предлагают.

А писать свой "велосипед" не вариант? Всё же полнотекстовый поиск нам по сути не нужен, айдишники параметров мы знаем. Я думал в сторону инвертирования индекса, но тогда казалось, что это слишком большой объем данных и должно быть "прямое" решение.

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

AnrDaemon

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