Рекомендации по такой структуре проекта?

Question

[WebDev]

Есть проект, где авторы публикуют свои статьи/новости/заметки (новости парсятся и добавляются вручную).
Пользователи подписываются на своих любимых авторов и читают их новости. Помимо этого, пользователи могут настраивать фильтры и читать записи с определенным тегом. Пользователи также могут читать только "непросмотренные" новости, а еще для каждого пользователя лента формируется исходя из его даты регистрации (дата регистрации минус 3 месяца).
Проект на MySQL и получаются замысловатые запросы с разными условиями.
Таким образом получается абсолютно уникальный контент для каждого пользователя: уникальный набор авторов, уникальный набор фильтров, уникальная глубина ленты и разное количество прочитанных новостей.
Хотелось бы услышать рекомендации по организации такого проекта, например, вопрос с кэшем, который я не вижу как может быть применен здесь, потому что лента новостей у всех разная.
Новостей много - уже более 5 миллионов и количество растет (примерно миллион в месяц). Пока все работает быстро, но посетителей на сайте мало. Пытаюсь заранее подготовиться к бОльшему объему данных и количеству пользователей.
Смотрел я недавно доклады с highload++, где один из докладчиков рассказывал, как они в интернет магазине сохраняли всевозможные комбинации фильтров в redis и получали товары по айдишникам. При обновлении/добавлении/удалении товара этот кэш в redis просто пересчитывался. Это очень хорошая идея, но применимо ли что-то похожее в моем проекте? У меня очень много запросов в базу и практически нечего сохранять, контент очень динамический, новые записи появляются постоянно.
NoSQL не подходит, идея проекта сырая, очень часто меняется структура и важно не потерять данные. С NoSQL это было бы адом.
Подытожу: проблем с производительностью нет, но мне проект видится ресурсоемким из-за невозможности ничего закэшировать. Что бы вы посоветовали и действительно ли проект с такой структурой сложен или я зря беспокоюсь?
Спасибо.

Answer 1

[ThunderCat]

Не обязательно что-то прям очень оптимизировать, но допустим можно сразу какие-то наборы ключей в виде массивов хранить в редисе, чтобы каждый раз не выбирать, а делать in(1,2,7,4,21,222,324) - это сильно ускорит выборки, кэш это не только готовые результаты, это могут быть готовые сеты для выборок, например, чтобы ускорять селекты. Много чего можно в редис понапхать, не зря кеш на уровни делят.

Answer 2

[xmoonlight]

Для этого проекта кэш - это фактически 3 типа готовых рендеров для одного материала, которые должны быть кэшированы:
1. HTML-рендер каждой отдельной публикации
2. HTML-рендер одного элемента в списке ленты (с временем публикации, тегами, просмотрами, лайками и прочим).
3. HTML-рендер одного элемента для отображения в баре (похожие публикации, самые просматриваемые, самые комментируемые и т.д.)

Всё остальное - это манипуляция с ID-шниками в БД.

Самое важное: таблица привязки материалов (id) к пользователям ("динамическая лента") при их создании(+ подписке/отписке на тег(и)/автора(ов) и т.д.) на основе предпочтений! Это сильно сэкономит время формирования (выборки) ленты (перечня id-шников) для конкретного пользователя.

UPD: По выбору фреймворка - см. тут.