LINUX.ORG.RU

Зачем Redis?

 , , ,


1

2

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

★★★★★
Ответ на: комментарий от deep-purple

т.е. не слабо на пыхе записать в файл класс пыха не сериализуя этот класс?

С чего ты так решил? :) Я говорю, что даже если это сделать - то оно ничего не меняет.

а редис случаем шмем не использует?

Да суть та же - передаешь сериализованные данные куском по ключу. Только в случае пхп оно приварино к хосту.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от deep-purple

а редис случаем шмем не использует

Редис — клиент-сервер. Да, есть попытка присобачить разделяемую память туда:

https://github.com/edgarsi/redis-module-shm

Однако, проблема в том, что для коротких запрос-ответов разделяемая память не дает никаких преимуществ. Потому, например, ALPC использует для мелких буферов копирование памяти вместо использования разделяемой памяти. Чтобы получить преимущества разделяемой памяти, клиент редиса должен складывать в единственный сегмент разделяемой памяти запросы, а потом читать оттуда ответы. По коду redis-module-shm (благо, кода там меньше чем доков) видно, что под каждое соединение выделяется фиксированный буфер 16 кб для каждого направления (клиент->сервер и сервер->клиент) и над этими буферами стоит глобальная блокировка на весь сервер (привет GIL). Чел измеряет задержку, а должен был бы измерять число запросов в секунду. А ведь именно здесь можно было бы получить сотни тысяч запросов в секунду, если не миллионов — и тогда проект возымел бы реальное практическое применение.

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

Чтобы получить преимущества разделяемой памяти, клиент редиса должен складывать в единственный сегмент разделяемой памяти запросы, а потом читать оттуда ответы

Ничто не мешает иметь больше одного сегмента. Но ничто не мешает иметь и только один сегмент шмема и кучу семафоров-ключей.

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

передаешь сериализованные данные куском по ключу

Нет. В случае с пыхом сериализовать не нужно.

в случае пхп оно приварино к хосту

Будто IPC может иначе.

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

Нет. В случае с пыхом сериализовать не нужно.

Судя по сигнатуре передаётся string и получаешь string, а не mixed.

Будто IPC может иначе.

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

crutch_master ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.