LINUX.ORG.RU

Зачем Redis?

 , , ,


1

2

Нуб вопрос. Зачем нужен Redis если можно просто создать внутренний кэш в приложении? В документации и всяких статьях, написано про большую гибкость и что-то там. Ладно, если это кэш для нескольких приложений одновременно, но для одного-то зачем? Особенно, с учетом того, что данные надо приводить к строкам, чтобы хранить в Редисе. Ну или еще как-то преобразовывать.

★★★★★

Ответ на: комментарий от no-such-file

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

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

petrosha ★★★★★ ()
Последнее исправление: petrosha (всего исправлений: 1)

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

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

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)

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

Уже вроде стар, и умен, и много больших повидал, а всё так же веришь сказкам. Нет, 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)

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

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

byko3y ★★★★ ()
Ответ на: комментарий от crutch_master

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

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

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

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

petrosha ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

petrosha ★★★★★ ()
Ответ на: комментарий от petrosha

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

cdshines ★★★★★ ()
Ответ на: комментарий от petrosha

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

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

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

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

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

byko3y ★★★★ ()
Ответ на: комментарий от petrosha

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

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

crutch_master ★★★★★ ()

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

anonymous ()

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

stave ★★★★★ ()

Философия 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

NeOlip ★★ ()
Ответ на: комментарий от petrosha

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

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

Shadow ★★★★★ ()
Ответ на: комментарий от anonymous

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

stave ★★★★★ ()
Ответ на: комментарий от stave

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

menangen ★★★★★ ()
Ответ на: комментарий от stave

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

anonymous ()

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

PolarFox ★★★★★ ()
Ответ на: комментарий от PolarFox

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

whoisyou ()
Ответ на: комментарий от stave

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

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

petrosha ★★★★★ ()
Ответ на: комментарий от NeOlip

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

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

petrosha ★★★★★ ()
Ответ на: комментарий от PolarFox

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

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

petrosha ★★★★★ ()

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

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

anonymous ()
Ответ на: комментарий от petrosha

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

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

Shadow ★★★★★ ()

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

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

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от PolarFox

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

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

Vit ★★★★★ ()
Ответ на: комментарий от crutch_master

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

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

byko3y ★★★★ ()
Ответ на: комментарий от crutch_master

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

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

byko3y ★★★★ ()
Ответ на: комментарий от NeOlip

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

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

byko3y ★★★★ ()
Ответ на: комментарий от stave

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

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

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

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

byko3y ★★★★ ()
Ответ на: комментарий от byko3y

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от menangen

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

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

byko3y ★★★★ ()
Ответ на: комментарий от byko3y

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

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

Psilocybe ★★ ()
Ответ на: комментарий от crutch_master

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

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

byko3y ★★★★ ()
Ответ на: комментарий от Psilocybe

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

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

byko3y ★★★★ ()
Ответ на: комментарий от no-such-file

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

byko3y ★★★★ ()
Ответ на: комментарий от crutch_master

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от petrosha

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от petrosha

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

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

byko3y ★★★★ ()
Ответ на: комментарий от byko3y

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

anonymous ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.