Зачем для кеширования использовать Redis, если можно сделать файловое кеширование?

Question

[eugene159]

Часто слышал, что Redis используют для кеширования. У меня возник вопрос. Чем Redis лучше файлового кеширования? На подключение .php файла с нужными данными уйдет меньше времени и ресурсов, чем на получение данных из Redis. Таким образом, хранить кеш в .php файлах эффективнее. Зачем тогда для этой цели используют Redis?

Comments

[Сергей delphinpro]

вот, погуглил за вас https://habr.com/ru/companies/wunderfund/articles/...

[ThunderCat]

На подключение .php файла с нужными данными уйдет меньше времени и ресурсов, чем на получение данных из Redis.

Во первых - слишком категоричное утверждение и размытая формулировка. Где запущен редис и какой отклик по скорости? Как подключена партиция с кэш-файлами? Что храним? Как часто пишем/читаем? Какой объем кэша?
А во вторых - где пример, где это реализовано с выкладками по времени на, допустим, цикл 10000 запись-чтение?

Пока выглядит просто как банальное "я слышал от дедушки что..."

Answer 1

[Ипатьев]

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

Но понятие кэша гораздо шире. Кэшироваться может и специфичная для конкретного пользователя или запроса информация. В этом случае никаких .php файлов не напасешься.

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

Еще одна причина, не главная, но все равно важная - масштабирование. Один сервис редиса можно использовать с несколькими инстансами РНР. Плюс сам редис можно масштабировать на несколько физических инстансов.

Answer 2

[Сергей delphinpro]

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

Comments

[Ипатьев]

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

[Dmitry Bay]

Советую автору вопроса еще прочитать книгу, она маленькая, но объясняет принципы и основы REDIS.
https://www.3s.group/upload/iblock/890/890258c1a79...

Answer 3

[mayton2019]

Разработка софта - это наука не теоретическая а практическая. Кеш или мемоизация вычислений - это просто один из множества паттернов оптимизации. Вполне возможно что найдется задача где Redis не нужен. Или при интенсивной записи может оказаться что затраты на актуализацию кешей перекрывают
их полезный эффект при чтении. Кеши могут быть отравлены (poisoned) кривыми данными с бесконечным TTL
и это может быть проблема. Кеши могут требовать реализации чуть более сложных веб-сценариев с
If-None-Match или If-Modified-Since. Тоесть их использование не бесплатно для разработки. Ну это не
чек-боксик включить. Это - архитектурный вопрос и над ним надо думать.

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

Вообще для Redis и Nginx не существует оценочной формулы полезного эффекта. Вы просто берете
за образец некую работающую систему. Смотрите как на best practices и применяете к своей задаче.

И потом через A/B тестирование смотрите какие были полезные изменения. Что стало лучше работать.
Что стало хуже (плата за биллинг использования новых серверов или нодов или больше памяти).