запросами и выводящихчя постранично пользователю. Они так же зависят от разных фильтров(то есть выборки по товарам разные) класть в кеш это все хорошоая идея или есть что то лучше ?
как вариант хранение отдельно, поиск отдельно. как с поисковими машинами кормить какому движку (nosql?), тогда выборку с кучу связей можно не делать. Но от задачи конечно и бюджету
зависит от того сколько у вас вариаций. например. у вас только 1 запрос "отдай все" - будет только 1 запись хранящая 5к товаров в кэше. (считаем сколько съест памяти) сюда добавляется "отдай только красные|синие|остальные_14_цветов" итого у нас 17 записей в кэше. а теперь представим что у вас 30 фильтров чекбоксов (буль, есть|нет). и они стакаются все вместе (можно все врубить, или произвольное количество). получается уже 2^30 или 1 073 741 824 записей. уже не прикольно... даже если каждая запись будет всего в 1 байт - съест гиг памяти.
вроятнее всего 80% всех запросов будет к 20% всех фильтров. а внутри них опять же 80% запросов будет всего к 20% фильтров. итого, закешировав примерно 4% всех вариантов вы обработаете 64% всех запросов. понятно что у вас свое распределение будет... вероятнее всего нужно смотреть в сторону либо какого то поискового движка, либо оптимизировать запросы. я как то забыл индекс накиинуть - так у меня запрос выполнялся по пол минуты. индексирование столбца пол минуты превратило в <50мс (если мне не изменяет память, могу наврать про порядок цифр) у нас тоже как бы дофига кэша нужно, но у нас такая специфика что мы при первом обращении кешируем страницу на 2 минуты а при повторном обращении к ней просто продлеваем кэш. в результате немного страдает первый юзер, но спокойно гуляют все остальные и кэш не копится
а если несколько юзеров сделают запрос когда нет кэша, то каждый перезапишет кэш другого?)
не, там проверяется) очень уж кейс простой
Обсуждают сегодня