Проектируем приложение с Redis в качестве хранилища данных. Что? Зачем?

[korsetlr473]

и сколько выдержит ситуация когда ЛедиГага за 1 час получает около 10 млн лайков на 1 пост ?

[BugM]

2.7к рпс. Выглядит нестрашно для Редиса.

[polearnik]

зависит от сервера но у меня на XEON X5550 было 80к RPS к редису. одно ядро было занято на ~80%. Если грамотно подобрать структуры данных для хранения тобутылочным горлышком редис никогда не будет

[korsetlr473]

вы даже вопроса не поняли , понятное дело что контекст не в редисе , а в вашей структуре данных сетов , которая получается key with nested array . В Той же mongodb в структуре key - nested array в одном документе после 100к записей в массиве уже начинает >1секунды запросы.

[Antharas]

А индексы уже не используют? Почитайте спеку на монгу более детально.

[korsetlr473]

зачем мне читать то в чем я контрибутер?

[karrakoliko]

Спроектировали по сути целый Tinder, можно и в FAANG после такого :-)

вы всего лишь записали хаотично выбранные данные в in-memory key-value хранилище и прочитали их оттуда, спокойно

[DaniilRoman]

в этом и была шутка)

[sse]

Что будет, если этот код выполнится одновременно от двух "лайкеров" одному и тому же юзеру? Чей-то UserLike потеряется?

[ggo]

потеряется.

но кто ж лайки считает, это же не деньги. одним больше, одним меньше.

[OkunevPY]

Блин дичь дичайшая, что за бред с очередями.

Redis выполняет операции атомарно, для счётчиков есть INCR который избавит от всей этой дичи.

Redis это in-memory хранилище, как только подключите Persistance, плакала ваша производительность.

Все возможные статистики по посещениям, просиотрам и т.д. формируються поверх TimeSeries структур и уж точно не в редисе.

Что за странная философия "Я узнал что есть инструмент, а давайте мы на нём сделаем всё!!!".

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

[vadlit]

>Redis это in-memory хранилище, как только подключите Persistance, плакала ваша производительность.

Он же вроде не сразу скидывает на диск, а только по прошествии времени/наступления события? Или я путаю?

[karrakoliko]

там разные режимы есть
https://redis.io/topics/persistence

[Semenych]

Очень полезная статья. Наблюдаю посление лет 10 попытки хранить транзакционные данные в NoSQL базах. В зависимости от выбора БД это имеет разную степень успешности. Но Редис тут не годится совершенно. Что не так

1. не масштабируется - редис быстрый но, но по сути однопоточный

2. не скалируется по объему данных. Если у вас база 64Гб, то вам надо два сервера (мы же хотим отказоустойчивость) с 64Гб памяти для в общем-то крохотной базы которую легко держит postgres установленный на R Pi

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

4. Представьте, что вам нужен список всех пользователей из Костромы? А теперь все пользователи из Ростова старше 40 лет. То что в РСУБД делается за минуту человеком поверхностно знающим SQL тут требует в лучшем случае часов работы программиста

Похожая история была вот у этих ребят https://freefeed.net/ - они сделали микро соц сетку на Редисе и уперлись в перечисленные выше проблемы, особенно больной была проблема номер два. В результате переписывали на постгрес.

Буду обязательно давать читать эту статью начинающим архитекторам.

[aleks_raiden]

Часть замечаний справедлива, часть обходиться заменой редиса на KVRocks ) Редис прекрасно масштабируеться, если что ) До момента памяти, хотя сейчас норма сервера это уже 128+ Гб. Ну и конечно, данные из редиса можно перекладывать потом в другие базы для аналитики.

[Semenych]

Написал и стер три комментария. Рассказыать бизнесу, что ему нужна ОТДЕЛЬНА АНАЛИТИЧЕСКАЯ БАЗА при том, что у него <100 запросов в секунду и все база жалкие 100Гб. Ну так тоже можно конечно, лох не мамонт.

Но я человек старой закалки и мне такое совесть не позволяет.

Отдельное спасибо, еще один пункт в копилку - как не надо делать.

[bondeg]

Не описаны крайне важные моменты.

• Критичные данные типа пользовательских данных, которые редко меняются, обязаны храниться в режиме немедленной записи на диск в отдельном инстансе.

• Чтобы не было описанных в комментах проблем, фичи нужно хранить в раздельных инстансах. При росте это позволит мигрировать данные между серверами без геморроя

• Шардирование данных в целом

• Использование транзакций при необходимости (см. watch или использовать локи для проверки атомарности)

P.S. GEORADIUS: Deprecation notice: as of Redis version 6.2.0 this command is considered as deprecated. While it is unlikely that it will be completely removed, prefer using `GEOSEARCH` and `GEOSEARCHSTORE` with the `BYRADIUS` argument in its stead.

[Antharas]

Как это не может "многопоточно"?

С точки зрения выполнения команд в коре - да. С точки зрения вашего кода - CAS и Retry уже не используется?