Что лучше выбрать для кэширования: файлы, redis, mongodb, memcache?

Question

[1serfer]

Что лучше выбрать для кэширования страниц сайта?
Кэширование в файл или: Redis, MongoDB, Memcache?

Исходные данные: Дедик, PHP, MySQL

Читал что в файл будет быстрее, пока всё ограничивается одним сервером.
Однако если будет очень много папок и файлов на одном сервере, не скажется ли это на работе сервера?
Либо всё-таки лучше использовать NoSQL решения для этого? Тогда что лучше для исходных данных?
Спасибо.

Answer 1

[Yuri Shikanov]

Memcached будет быстрее всего работать.

Comments

[1serfer]

Спасибо за совет.
Даже несмотря на бенчмарки?
systoilet.wordpress.com/2010/08/09/redis-vs-memcached

[Yuri Shikanov]

@1serfer там не совсем корректный бенчмарк, см - dormando.livejournal.com/525147.html

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

[Андрей]

@dizballanze трехлетней давности тесты, при столь разной интенсивности развития обоих продуктов… И я что-то не наблюдаю конфигурационных файлов - редис синкается с диском при этом всем или нет? Из моего опыта - редис быстрее, причем значительно.

[Yuri Shikanov]

@kaasius свежие не смог найти, возможно сейчас уже совсем другие результаты

[Андрей]

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

[Yuri Shikanov]

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

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

[Андрей]

@dizballanze И снова - при каких настройках redis? При загрузке всех ядер или одного (redis однопоточен, а мемкешед нет)? Синтетические тесты такие синтетические.

[Yuri Shikanov]

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

[Андрей]

@dizballanze То, что вы предлагаете, более долгий и, соответственно, дорогой путь. Коллега @1serfer пришел сюда в надежде его сократить.

[Yuri Shikanov]

@kaasius в любом случае, с уверенностью можно сказать, что вне зависимости от выбора (redis или memcached) @1serfer получит достаточно производительное решение. Я исхожу из того, что разница между ними в любом случае очень небольшая и скорее всего возникающие проблемы производительности будут связаны с другими компонентами.

Answer 2

[Сергей Протько]

MongoDB то в список как попал?

По остальному же крайне рекомендую к прочтению:
stackoverflow.com/questions/10558465/memcache-vs-redis

Comments

[Yuri Shikanov]

+1, mongodb есть смысл использовать как кэш, если только он же используется как основная БД, чтобы зоопарк не разводить.

[Андрей]

@dizballanze Нет такого смысла. Если используется mongo как основная база, то ускорить всё за счет кеша в монге же - это фантастика.

[Виталий Архипов]

Почему фантастика? Смысл кеша в том, что он собирает некоторые данные в одно место с доступом по ключу (какую то сложную выборку, например). Т.е. кеш можно делать в любой из СУБД просто создав табличку KEY VALUE. Просто Memcached и товарищи лучше заточены под это, но смысл кеша это не отменяет.

[Андрей]

@arvitaly Смысл конечно не отменяет, но и не прибавляет. Учитывая, как монго работает с изменением данных, ну и множество других нюансов - я бы никогда не стал бы этого делать.

[Виталий Архипов]

@kaasius я не знаю о чем вы. Еще раз повторяю кеш это когда у нас запрос 4 секунды, мы сохраняем его результаты в одно поле и даем ему key и оно теперь возвращает результаты за 0.0001 секунды. И неважно где мы этот key и value сохраняем.

[Yuri Shikanov]

@arvitaly все правильно написал, складываем "горячие" данные для быстрого доступа по ключу. К тому же mongodb позволяет задавать TTL для данных. @kaasius

[Сергей Протько]

горячие данные нужно хранить в памяти. Многа хороша только для логирования, если уж не говорим о непосредственно прямом назначении монги.

[Yuri Shikanov]

@Fesor все от задачи зависит, иногда производительности монги более чем достаточно

[Виктор Краснов]

Прошу прощения, что пишу в такую старую ветку. Но вот как раз столкнулся с выбором инструмента кеширования (хайлоад и кеша может быть очень много) и исходя из того, что память в 10 раз дороже самых быстрых дисков в ДЦ, пришла мысль, а не стоит ли попробовать хранить Кеш в Монго. Так чем у вас дело закончилось?

Answer 3

[Александр N++]

APC или Редиска
Я бы в общем брал бы то что доступно.

1 у вас есть абстракция для работы с кешем
2 у вас есть конфиг где вы указываете, какой кеш провайдер использовать.

Весь код сводится к

if( ! $data = Cache::get( 'news_list0'))
{
    // опа данных нету...
    // нашли из базы
     Cache::set('news_list0' , $data,90);
}

Можно ngnix кешить даже для начала тот же файловый кеш
Если винт разгрузить то только оперативка: редиска и мемкеш итд.

Answer 4

[1serfer]

Спасибо всем.
С MongoDB я конечно погорячился )
Читал что некоторые его и для кэша используют.
Это скорее от нехватки знаний в данной области.

А также, у кого ещё в голове (как и у меня) небольшая неразбериха в области применения NoSQL решений, вот есть небольшая статья:
kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Comments

[Сергей Протько]

все эти versus просто заменить на with и проблема с выбором nosql решается. Каждая nosql для своих целей сделана. универсальной нету...

Answer 5

[afiskon]

Лучше сразу Riak. Он как Memcached или Redis, только с автоматической репликацией и решардингом при добавлении новых узлов. Может быть как in-memory, так и persistent. Возможно, спустя какое-то время захотите его не только как кэш использовать.