Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Оптимизация категоризированного поиска товаров.
Покинул форум
Сообщений всего: 7
Дата рег-ции: Май 2015
Помог: 0 раз(а)
Добрый день.
Столкнулся с проблемой скорости загрузки страниц на каталогах подарков http://begift[dot]ru/ и http://begift[dot]com[dot]ua/ На сайте каждый товар имеет ряд параметров, которые его характеризуют. Параметры, в свою очередь, разбиты по категориям. Например, товар: цветы имеют параметры «Праздник» – 8 Марта, 14 Февраля… и «Кому подарить»: Маме, Жене, Девушке и т.д. Пользователь может свободно комбинировать параметры, на основе которых ему показываются подходящие товары. Пытаюсь оптимизировать данную страницу, поскольку время генерации составляет неприличные 10-15 сек: http://tools[dot]pingdom[dot]com/fpt/#!/[dot][dot][dot]god-iz-igrushek/
Подбор товара осуществляется алгоритмом: параметры внутри категории объединяются оператором ИЛИ, сами категории – оператором И. Страница, кроме основного списка, показывает также количество подарков, которое будет получено путем комбинирования уже выбранных и дополнительных параметров. Этот расчет также происходит по тому же алгоритму. Таким образом, мы имеем около 30 таких выборок на каждую загрузку страницы. В большинстве случаев используем подготовленные запросы, но для таких страниц запрос полностью генерируется в php коде вместе с параметрами. Он довольно объемный и плохо оптимизируется с самой базой. Я уже реализовал кэширование (сохраняя результаты всех вычислений для каждой страницы) на стороне сервера. Так как стоимость товара и его наличие обновляется, то этот кэш нужно обновлять раз в 1-2 дня. Страниц около 3000, если кэшировать каждую каждый день, то только на кэширование уйдет 10 часов.
Хочу провести сравнительные тесты разных альтернативных алгоритмов. Возможно, у кого-то есть опыт в таких задачах. Буду благодарен за совет.
Мелкий
Отправлено: 13 Мая, 2015 - 16:02:35
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Sheehave пишет:
Таким образом, мы имеем около 30 таких выборок на каждую загрузку страницы.
Из чего это вытекает?
Покажите схему БД и код. Если цифры на главной имеют отношение к количеству предложений - то городить несколько уровней кэшей ради пустяковых пары тысяч товаров смешно.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 13 Мая, 2015 - 16:09:58
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Мало инфы. Ты там что, лайками ищешь чтоли? Для каждого параметра заведи айдишник. Ищи по названию в таблице параметров и джойнь все товары через таблицу связи:
Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014
Помог: 10 раз(а)
[+]
Я правильно понял, что у вас фильтры по принципу яндекс-маркета, т.е. включив один фильтр вы рассчитываете активность фильтров из других групп? (Добавление)
Если да, то fixxer на пхпклабе дал верный ответ. Простой оптимизацией вы ничего не решите, берите эластик или что-то вроде этого.
----- self-banned
DeepVarvar
Отправлено: 13 Мая, 2015 - 16:34:02
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
А, так ТС закинул удочку сразу на нескольких ресурсах? MiksIr дай сцыль поглядеть что там, ато он крохи инфы какие-то тут выдал.
Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014
Помог: 10 раз(а)
[+]
Да там не больше инфы. Просто задача известная для тех, кто большие каталоги делал с подобными фильтрами.
----- self-banned
Sheehave
Отправлено: 13 Мая, 2015 - 16:52:23
Новичок
Покинул форум
Сообщений всего: 7
Дата рег-ции: Май 2015
Помог: 0 раз(а)
Количество страниц ограничили до 3000 с около миллиона, добавив ряд логичных ограничений, раньше оно росло факториально от количества параметров
Количество страниц скорее вытекает из числа комбинаций параметров на странице http://begift[dot]com[dot]ua/chto-podarit/
Изначально они вообще генерировались "на лету" и никак отдельно в базе не хранились. "Кеширование" - это и есть такая же генерация.
Кода много и база большая, попробую описать общую схему.
Мелкий пишет:
Из чего это вытекает?
При поиске слева пишут сколько товаров прибавится или убавится с добавлением параметра - вот на каждый такой параметр и происходит перерасчёт.
DeepVarvar пишет:
properties
id, title
products
id, ..., ..., ...
products_properties
property_id, product_id
Это самая простая и логичная схема, у нас та же структура, за исключением добавившихся категорий:
ANDEXISTS(SELECT 1 FROM products_properties ppts WHERE p.id = ppts.product_id AND ppts.property_id IN(1,4))
ANDEXISTS(SELECT 1 FROM products_properties ppts WHERE p.id = ppts.product_id AND ppts.property_id IN(2,3,6))
ANDEXISTS(SELECT 1 FROM products_properties ppts WHERE p.id = ppts.product_id AND ppts.property_id IN(5))
И вот сильно лучше ничего в голову не приходит.
MiksIr пишет:
Я правильно понял, что у вас фильтры по принципу яндекс-маркета, т.е. включив один фильтр вы рассчитываете активность фильтров из других групп?
Где-то так)
Сейчас посмотрю конечно что там за готовые решения предлагают. Изначально не предполагал, что это понадобится - задача вроде несложная
MiksIr
Отправлено: 13 Мая, 2015 - 16:59:55
Забанен
Покинул форум
Сообщений всего: 378
Дата рег-ции: Сент. 2014
Помог: 10 раз(а)
[+]
Задача не сложная, но ресурсоемкая. Т.е. ее можно тупо решить железом. Можно посмотреть на тему всяких оптимизаций, где-то кешом подпереть, но это кардинально ничего не изменит.
Покинул форум
Сообщений всего: 1131
Дата рег-ции: Февр. 2014
Помог: 57 раз(а)
И добавьте индекс (уникальный, однако, если нет одинаковых id параметра для разных категорий) по `product_id` и `property_id` для таблицы `products_properties` (если вдруг он отсутствует)
Мелкий
Отправлено: 13 Мая, 2015 - 17:36:38
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Sail пишет:
добавьте индекс (уникальный
Первичный сразу. Для таблицы связей отличный вариант сразу ставить первичный составной ключ непосредственно на данные.
Sheehave пишет:
При поиске слева пишут сколько товаров прибавится или убавится с добавлением параметра - вот на каждый такой параметр и происходит перерасчёт.
Что в запросе при этом меняется? Это вполне можно одним запросом вытащить.
----- PostgreSQL DBA
Sail
Отправлено: 13 Мая, 2015 - 17:41:37
Участник
Покинул форум
Сообщений всего: 1131
Дата рег-ции: Февр. 2014
Помог: 57 раз(а)
Мелкий, спасибо за уточнение
А в Вашем запросе осталось только опечатки поправить
Мелкий
Отправлено: 13 Мая, 2015 - 17:47:23
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Sail пишет:
А в Вашем запросе осталось только опечатки поправить
Запросто мог что-то прошляпить, но что - не вижу. Ткните носом
----- PostgreSQL DBA
Sail
Отправлено: 13 Мая, 2015 - 17:49:51
Участник
Покинул форум
Сообщений всего: 1131
Дата рег-ции: Февр. 2014
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.