Как кешировать фильтры?

Сразу хочу отметить, что речь не идет конкретно о modx и msearch2, вопрос в целом — об идеях, реализациях, опыте коллег.
Что собственно смущает.
К примеру есть страница, на которой условные товары. Есть фильтр с набором характеристик, к примеру есть
Размер
— s
— m
— x

Цвет
— белый
— черный
— красный

Бренд
— 1
— 2
-3
Какие варианты работы фильтра я вижу:
1) Вариант без кеширования. Любое изменение фильтра вызывает запрос на сервер, который вернет данные, соответствующие фильтру.
2) Кеширование первым пользователем. Когда пользователь что то выбрал в фильтре, отправляется запрос, получаются данные, кешируются. Когда этот же иди другой пользователь накликает в фильтре такую же комбинацию, данные будут отданы из кеша.
3) Полное предварительное кеширование. Кеш всех комбинаций фильтра готовиться заранее и даже первый клиент получает уже ответ из кеша.

Какие проблемы и недопонимания эти варианты вызывают:
1) С первым все более менее понятно. Будет работать, но если количество характеристик постоянно растет (на некоторых проектах у меня менеджеры вывели в фильтр уже 170 типов характеристик и у каждого типа не менее 10 значений) то «тормоза» неизбежны, как ты не оптимизируй и не используй индексы в базе.
2) Второй вариант лично мне кажется бесперспективным. Хотя по моему именно так кешируются большинство фильтров. Прежде всего очень мала вероятность, что пользователи будут накликивать в фильтре одни и теже комбинации, скорее всего каждого будут интересовать разные товары. Можно сказать мол ок, первым 1000 пользователей не повезет, у них будет тормозить но потом все закешируется и пойдет уже лучше. И да и нет. Только если сайт статичен и обновление данных в нем происходит раз в месяц. А что если каждый день или по три раза в день менеджры работаю с товаром, меняют цены, удаляют, добавляют. После каждого такое действия система обязана очистить кеш, иначе пользователь будет видеть нереальные данные. А значит все что успели «накешировать» пользователи удалиться и такой вариант кеширования бесполезен.
3) Примерно так. Внесли изменение в товар, нажали кнопку — закешировать страницы. Просчитались заранее все варианты для фильтра для каждой страницы и теперь каждый запрос от фильтра получает в ответ кеш. Все бы хорошо, если бы не пугающее количество комбинаций, которое возникает в фильтре. Даже в моем примере, где есть три характеристики и у каждой всего три значения, количество возможный комбинаций (математики не сильно ругайтесь, возможно я не прав) равно факториалу от 9, а это более чем 300 000 комбинаций. Если характеристик станет больше, количество возможных комбинаций станет равно миллиардам. И так для каждой страницы. Несколько пугает, особенно если хочешь хранить это все в редис и понимаешь, что на сервере понадобиться 400 гигабайт оперативки. В общем тоже плохой метод.

Ну и собственно, возвращаюсь к самому главному вопросу — а как кешируют фильтру умные люди?
спасибо.
Александр Мельник
26 января 2022, 10:10
modx.pro
426
0

Комментарии: 5

Александр Мельник
26 января 2022, 11:01
0
исправлю немного сам себя. Формула n! имеет смысл если в фильтре есть разница, в каком порядке выбраны характеристики. Если же нет разницы, то формула должна быть другой и общее количество комбинаций будет меньше, но все равно очень большим.
    Алексей Смирнов
    26 января 2022, 11:21
    0
    В данном случае комбинаций будет 3*3*3 = 27, без учета последовательностей. Да и не будет зависимости от последовательности для БД. Так что всего лишь 27+1 разных запросов закэшировать просто. 1 -й это без фильтра вовсе — тоже кэшируется.
      Александр Мельник
      26 января 2022, 11:40
      0
      Насчет того, влияет ли последовательность выбора характеристик в фильтре. Вы правы, что не влияет. Но это если говорить о фильтре для покупателя. Ему не важно, сначала он выберет что хочет красную футболку а потом добавит что хочет еще и белые, или наоборот.
      Но чаще всего наши СЕО специалисты требуют, чтобы фильтр не был только инструментом для пользователя но был и СЕО инструментом и тут начинается такое… Иногда бывают требования, чтобы урл страницы изменялся так, в какой очередности человек кликает в фильтре. К примеру если сначала на красный а потом на белый, то урл чтобы был
      site.com/filter/red-white/
      а если сначала на белый а потом на красный, то
      site.com/filter/white-red/
      и не смотря на то, что оба запроса вернут один и тот же товар, но например это позволит «порадовать» клиента, и показать ему товары сначала красные, а потом уже белые, тоесть «первое слово главнее второго)».
      И получается что от очередности выбора характеристики напрямую зависит то, сколько данных нужно кешировать.
    Алексей Смирнов
    26 января 2022, 11:11
    0
    Думаю, нужно исходить из того какие тормоза. это 1 сек или 10 сек?
    по 2му пункту — я выставляю кеширование БД и как раз для часто используемых вариантов — будет профит.
    3. кешировать после изменения менеджером какого то свойства — тоже такая себе затея. это нужно делать если хотя бы 1 день никто лазить туда не будет. и то сомнительное удовольствие для шаред хостингов.
    Учитывая что магазины у меня не сильно велики, то без кеша БД или кеш по загрузке (включается в MODX настройке) вполне для 5..10 к товаров уместен.
    Если товаров более 10к стоит думать об оптимизации, если фильтрация улетает за 2...3 секунды ожидания.
      Александр Мельник
      26 января 2022, 11:41
      0
      вы правы. я пока только теоретически рассматриваю этот вопрос, как вообще люди подходят к кешированию данных для фильтра. Хочу так сказать чужого опыта набраться)
      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
      5