Зачем Redis?

но для одного-то зачем

Горизонтальное масштабирование? Не, не слышал.

Типа когда кэш очень большой и можно разнести Редис на несколько хранилищ?

Но в примерах советуют хранить в редисе uuid логинов. Даже модуль специальный есть в npm. Сколько там данных-то, может быть если ты не гугель или фб…

Ладно, если это кэш для нескольких приложений одновременно

Да. Это кеш перед бд, чтобы её не дёргать зря.

но для одного-то зачем

Чтобы когда оно грохнется не просрать кэш. Чтобы кэш у тебя не потёк. Чтобы свалить сложность куда-нибудь в другое место. В случае пхп кэш сделать на пхп нельзя. Да мало ли еще для чего. Вопрос из разряда зачем нужна сабельная пила.

В документации и всяких статьях, написано про большую гибкость и что-то там

Уже вроде стар, и умен, и много больших повидал, а всё так же веришь сказкам. Нет, Redis не про большую гибкость и не про что-то там. Redis про неспособность целой кучи скриптовых языков, в первую очередь PHP, к самостоятельному использованию нескольких ядер процессора. В результате запускается несколько независимых интерпретаторов, а взаимодействие между ними обеспечивается неким внешним сервером. Redis и Memchached начинали именно как volatile cache, без заявок на СУБД и pub/sub, но в итоге Redis таки обрел даже pub/sub:

https://redis.io/topics/pubsub

В итоге Redis стал эдакой вариацией сервера сообщений. Алгоритм пользования такой штукой представляет собой что-то аналогичное банальному:

globalCache[key] = newvalue
for subscriber in globalCache.subscripers[key]:
    subscriber.notify(key, newvalue)

Тогда подписчик узнает, что его кэш протух и надо бы свои производные данные пересчитать.

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

Да. Это кеш перед бд, чтобы её не дёргать зря.

Ну собственно в этом и был вопрос, нафига это нужно, если можно внутри приложения сделать состояние, но ты уже объяснил про пхп. Спасибо.

В случае пхп кэш сделать на пхп нельзя.

Не буду задавать напрашивающийся вопрос, на*уа такие языки :))

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

Спасибо за добрые слова, но я только начинаю в серверную скриптотню и вот ничего не знал про PHP, кроме того что он есть.

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

Не буду задавать напрашивающийся вопрос, на*уа такие языки

Ж) Спроси у тех, кто ими пользуется.

Да. Это кеш перед бд, чтобы её не дёргать зря.

Ну собственно в этом и был вопрос, нафига это нужно, если можно внутри приложения сделать состояние, но ты уже объяснил про пхп

Не объяснил. Кэш переводит БД в non-ACID режим. Зачем нужна была ACID СУБД, если в итоге получаешь «согласованность в конечном счете», она же eventual consistency. То есть, неподходящий инструмент выбран не только для написания серверной логики, но и для СУБД. Так и живем. Зато на каждом углу требуются знатоки PHP и MySQL.

Не буду задавать напрашивающийся вопрос, на*уа такие языки :))

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

Зачем нужна была ACID СУБД, если в итоге получаешь «согласованность в конечном счете», она же eventual consistency

Затем, что схема в ACID СУБД есть уже 10 лет и она адски тормозит под гнётом наваленного туда. В этот момент врываются герои на белом редисе и приделывают консистентность на уровне веб.приложения.

Тут никто не умеет в архитектуру. Правильно нужно делать через микросервисы, это очень надежно, а главное позволяет динамически распределять нагрузку по железу через глобальный конфиг. Завязать все нужно через раббит или кафку. Самое главное писать/отлаживать намного легче, чем в монолите с набором велосипедов на пыхе. Воркеры писать можно на любом языке, хоть на плюсах.

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

Философия Unix гласит:

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

https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_Unix

на*уа такие языки

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

Если бы ты умел архитектуру, то сначала бы уточнил требования. А с таким подходом рождают сервисы на 10 рпс на 10 серверов, из которых 9 занимают кафки и прочее барахло, в недрах которых еще и сообщения теряются.

Вот хороший доклад на эту тему https://habr.com/ru/company/odnoklassniki/blog/499316/ с джокера.

Харе уже вестись на вбросы. Redis - это не только кэш, новичкам он нафиг не сдался, как и скриптикам на локалхосте. А, вот, когда надо будет данные скидывать на диск или реплицировать по серверам, вот тогда и обосрутся со своими самописными кешами в скриптах

Ты серьёзно или набрасываешь?

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

Redis — если нужен единый кеш на несколько растянутых в пространстве («масштабирование») или во времени (php и прочий cgi-bin) экземпляров приложения.

Или если прогретый кеш занимает сотни гигов (или даже терров)

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

Вопрос продиктован большим количеством материалов в духе - «Стотыщпиццот первая обертка для Редис в ноде…»

Философия Unix гласит:

Согласен… но приходится писать массу преобразований данных в/из текстовых потоков. Если данных не так много и они сильно разнообразны, это не очень удобно.

:) вместо лайка

Redis — если нужен единый кеш на несколько растянутых в пространстве («масштабирование») или во времени (php и прочий cgi-bin) экземпляров приложения.

:) Наверное, ты выиграл приз лучший ответ треда.

Все пишут про кеш, но редис - это ещё и очень фичастая KV-БД. Я на нём делал рассчёт пересечения множеств пользователей по разным признакам и это было очень быстро благодаря битовым операциям, типа как здесь:

https://redislabs.com/blog/bits-and-bats/

большим количеством материалов в духе - «Стотыщпиццот первая обертка для Редис в ноде…»

- никто не знает, зачем они это делают. Зачем они продолжают ЭТО писать на ноде. Легче выучить другой язык/фреймворк, чем городить эту порнографию.

Ладно, если это кэш для нескольких приложений одновременно, но для одного-то зачем?

Если у тебя физически один процесс - можно и локальный кеш наклепать. Но обычно процессов по количеству ядер. И, возможно, не один сервер. Тогда редиска бывает иногда удобной

Помимо банальщины из общих кешей, и специфичной БД, можно например намутить очередь задач https://github.com/nodeca/idoit.

Особенно, с учетом того, что данные надо приводить к строкам, чтобы хранить в Редисе. Ну или еще как-то преобразовывать.

Эта операция выполняется в процессе, который можно бесконечно масштабировать. Поэтому не является проблемой.

Это только один из вариантов.

Редиска позволяет выполнять атомарные операции над расшаренными данными. На этом можно всякий messaging средней руки строить. И очереди.

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

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

Затем, что схема в ACID СУБД есть уже 10 лет и она адски тормозит под гнётом наваленного туда. В этот момент врываются герои на белом редисе и приделывают консистентность на уровне веб.приложения

Да, они делают СУБД над мускулем. Правда, не совсем ясно, почему бы не сделать сразу СУБД над текстовым файликом SQLite. Люди так боятся изобретать колесо на коленке, но в итоге делают колесо на мускуле.

Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс

Ваш универсальный интерфейс — говно, вы ничего не понимаете в универсальных интерфейсах. Как минимум потому, что текстовой поток тяжело нужно парсить.

Ууу. Да ты серьёзно так набрасываешь. Продолжай.

Вот хороший доклад на эту тему https://habr.com/ru/company/odnoklassniki/blog/499316/ с джокера

Микросервисы с состоянием — это сова на глобусе.

Я уже отвечал по этому поводу, что в одноклассниках нет адекватных программистов, и просто чудо, что проект вообще до сих пор жив — в этом я виню тот факт, что в какой-то момент они отдали переписывание своего бэка на аутсорс. Тот масштаб, который у одноклассников (70 млн пользователей в месяц), в свое время в индусском месенжере и более известном фейсбуке крутился на банальном мускуле с пыхом. Упомянутая тобой презентация является лучшим доказательством того, что все эти микросервисы — это просто способ сделать так, чтобы работа никогда не кончалась.

И да, у меня жопа горит, потому что у меня под боком стахановцы без устали городят «архитектуру», которую гарантировано будет очень тяжело поддерживать (конечно, если ее вообще удастся довести до рабочего состояния), и я уже начинаю страдать от нее.

Правда, не совсем ясно, почему бы не сделать сразу СУБД над текстовым файликом SQLite

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

А, вот, когда надо будет данные скидывать на диск или реплицировать по серверам, вот тогда и обосрутся со своими самописными кешами в скриптах

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

Вообще-то мускуль тоже умеет в кэш :)

Не объяснил. Кэш переводит БД в non-ACID режим.

Кеш это избыточные хранимые данные. Но не всегда избыточность приводит к non-ACID. Пример - обычный индекс в БД тоже избыточная информация.

Слишком толсто.

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

Они и без миграции толком ничего с этой информацией сделать не смогут. Только сесть на нее, как на украденный банкомат, и теплится мыслью о том, что «здесь много ценностей».

Кеш это избыточные хранимые данные. Но не всегда избыточность приводит к non-ACID. Пример - обычный индекс в БД тоже избыточная информация

Ты приводишь понятие кэша к более общему понятию избыточности. Но я не писал про избыточность — я писал про кэш. Индекс не является кэшем, потому что стоит на одном уровне с данными, которые индексирует, обновляется одновременно с ними. Вот если у тебя асинхронный индекс, который не соответствует индексируемым данным — тогда это кэш, и тогда это, как я и писал, non-ACID БД.

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

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

Лицокнига так делает, подтверждаю. На моем рабстве тоже что-то похожее замутили, потому что иначе совсем плохо получается, как у одноклассников.

В случае пхп кэш сделать на пхп нельзя

Вообще-то можно. Даже для работы в fastcgi.

Чтобы когда оно грохнется не просрать кэш

Не суть какая великая проблема. Если оно у тебя не грохается каждые 5 минут. А если грохается, то проблема у тебя не с кэшем.

неспособность целой кучи скриптовых языков, в первую очередь PHP, к самостоятельному использованию нескольких ядер процессора

Как бы php тут вообще в последнюю очередь.

Не буду задавать напрашивающийся вопрос, на*уа такие языки

Ты больше верь всяким балаболам.

Типа когда кэш очень большой

Нет балда, когда у тебя слишком много экземпляров приложения и для них нужно несколько машин. Выгодно взять кучу дохлых нод и подключать-отключать их в зависимости от нагрузки, чем платить 24/7 за одну жирную ноду которая тащит нагрузку в час пик.

А так-то да, любой каприз за ваши деньги.

Так если отдать кэш на клиентскую стороны, смысл тот же, каждый экземпляр клиента со своим кэшем

Смотря что у тебя в кэше. Допустим кэш объектов, ты в одном экземпляре объект обновил, другой экземпляр как об этом должен узнать? Это основная проблема распределённого кэша. Можно конечно изворачиваться, но это уже другая тема.

неспособность целой кучи скриптовых языков, в первую очередь PHP, к самостоятельному использованию нескольких ядер процессора

Как бы php тут вообще в последнюю очередь

Из популярных серверных такая проблема только у питона и PHP. Подразумевая, что руби и перл уже мало кому нужны. Если перепишу «в первую очередь PHP и питон» — ты успокоишься?

Макакин, ты сегодня без борща. Или расскажи как обеспечить когерентность кеша у 200 тыс. клиентов?