Это не кэш.
Это другой сервис.

Что это за процедура такая? Один запрос...

Если redis не кэш, то что это?

Ну не знаю, говно какое-то

Там у тебя в where почти нет никаких фильтров.
А селективных фильтров нет вообще.


На основе чего этот запрос можно вообще оптимизировать?

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

1. Эти два кэша будут работать с разными сущностями
2. В кассандре кэш в том числе сбрасывается на диск, я не знаю подробностей, но как минимум для того чтобы холодный старт был не таким холодным
3. Дела с TTL могут обстоять принципиально иным образом.
4. Данные гарантированно держатся в оперативе
5. Если каким-то образом данные оказались на диске, а не в оперативе (например, взяли аэроспайк и сказали ему держать всё на диске, потому что денег на то чтобы держать весь датасет в памяти нет) - кассандра будет собирать запись по частям, а read-optimized k/v возьмет её ровно из одного места на диске.
6. Кэшируется только то, что интересует (e.g. только одна таблица), в то время как узел кассандры не может быть спрофилирован таким образом
7. Двухступенчатая система позволяет полностью потерять один из сервисов и всё равно остаться на плаву, пусть и с деградировавшим приложением

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

привет всем, с Новым годом)

с новым годом!)

Есть такой вопрос. Начинаю писать дипломный проект - соц. сеть кулинарных рецептов, соответственно будут юзеры, посты с рецептами, фолловеры (основные сущности). Вот остановился на построении архитектуры. Смотрел на реляционные базы  в частности постгрес, как стандартное решение. Но вот если у нас будет оочень много юзеров, постов и т.д., запросы джоинов буду проходить очень медленно (такие, как сделать сначала выдачу постов юзеров, за которыми следит данный пользователь). Потом пошел к NoSQL решениям, смотрел Кассандру - но в ней не получится сделать то, что нужно (например отфильтровать посты по кол-ву ингредиентов (ну сами понимаете, как устроена Кассандра)). Смотрел графовые БД, Neo4j, но они не очень предназначены для хранения больших данных, запросы тоже будут идти  долго. Потом решил загуглить как устроен Интсаграмм, они как-то умудряются юзать и Кассандру и Постгрес, не знаю как. Ну ок. Решил всё таки остановится на Постгресе. Но вопрос в том как с помощью системы кеширования (Редис, например) ускорить время ответа на запрос. Можно ли делать так? Берем 1000 грубо говоря постов с постгреса и кладём в Редис, ну и потом уже с клиента идём в Редис и пагиннируем (с лимитом 12 постов допустим) эти посты и возвращаем нужное клиенту? Или можно как-то по-другому это реализовать? Подскажите пожалуйста, буду очень благодарен)

какой облачный реляционный DBaaS используете?
чтобы никогда не упал и чтобы был автоматически горизонтально масштабируемым и реляционным.

никакой пока, а какие есть и какой можете посоветовать?

сорян, мой вопрос не относится к вашему вопросу)

меня интересует реляционный DBaaS. Сам нуждаюсь в совете.
Просто не хочу поднять все это дело самому и админить.

Как у вас все интересно медленно получилось еще даже без какой либо реализации 😄 Ни сколько пользователей предполагается, ни сколько постов предполагается, ни каких цифр, но все медленно, даже на касандре 😅

По-моему вы слишком заранее оптимизируете. Просто набросайте архитектуру для ваших требований, надо будет нормализовать данные в каком-то виде? нормализуйте! надо будет кешить какие-то выборки? ну используете редис для сохранения ответа от бд при конкретном запросе, а не переносите бд из постгреса в редис!

Надо будет доп таблички сделать с нужной инфой? сделайте доп таблички!

Но в начале нужно сделать просто архитектуру, которая работает, а потом оптимизировать, а не сразу говорить что все медленное 😃