Memcached против Redis?

мы используем веб-приложение Ruby с Redis сервер для кэширования. Есть ли смысл тестировать Memcached вместо?

Что даст нам лучшую производительность? Любые плюсы или минусы между Redis и Memcached?

нюансы:

  • скорость чтения/записи.
  • использование памяти.
  • сброс дискового ввода/вывода.
  • масштабирование.

17 ответов


сводка (TL;DR)

Обновлено 3 июня 2017,

Redis является более мощным, более популярным и лучше поддерживается, чем memcached. Memcached может сделать только небольшую часть того, что Redis может сделать. Redis лучше даже там, где их функции перекрываются.

для чего-нибудь нового используйте Redis.

Memcached vs Redis: прямое сравнение

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

моменты

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

  • скорость чтения/записи: оба очень быстро. Контрольные показатели различаются по рабочей нагрузке, версиям и многим другим факторам, но обычно показывают, что redis работает так же быстро или почти так же быстро, как из memcached. Я рекомендую redis, но не потому, что memcached медленный. Это не так.
  • использование памяти: Redis лучше.
    • memcached: вы указываете размер кэша, и по мере вставки элементов демон быстро растет до немного большего размера. На самом деле нет способа вернуть любое из этого пространства, кроме перезапуска memcached. Все ваши ключи могут быть просрочены, вы можете очистить базу данных, и она все равно будет использовать полный кусок ОЗУ настроил его.
    • redis: установка максимального размера зависит от вас. Redis никогда не будет использовать больше, чем нужно, и вернет вам память, которую он больше не использует.
    • я сохранил 100,000 ~2kb строк (~200MB) случайных предложений в обоих. Использование memcached RAM выросло до ~225 МБ. Использование Redis RAM выросло до ~228 МБ. После промывки обоих redis упал до ~29MB, а memcached остался на ~225MB. Они одинаково эффективны в том, как они хранят данные, но только один способен вернуть он.
  • дисковый ввод-вывод: явный выигрыш для redis, так как он делает это по умолчанию и имеет очень настраиваемое постоянство. Memcached не имеет механизмов для сброса на диск без сторонних инструментов.
  • масштабирование: оба дают вам тонны запаса, прежде чем вам понадобится более одного экземпляра в качестве кэша. Redis включает инструменты, которые помогут вам выйти за рамки этого, а memcached не.

memcached

Memcached-это простой сервер неустойчивого кэша. Он позволяет хранить пары ключ / значение, где значение ограничено строкой до 1 МБ.

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

при перезапуске memcached ваши данные исчезли. Это хорошо для кэша. Вы не должны хранить что-нибудь важное.

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

Рэдис

Redis может выполнять те же задания, что и memcached, и может делать их лучше.

Redis может действовать как кэш как хорошо. Он может хранить пары ключ/значение. В redis они могут быть даже до 512MB.

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

это тоже супер быстро, часто ограничено пропускной способностью сети или памяти.

если одного экземпляра redis / memcached недостаточно для вашей рабочей нагрузки, redis-это четкий выбор. Redis включает поддержка кластеров и поставляется с высокой доступности (направле-Сентинел) прямо "в поле". За последние несколько лет redis также появился как явный лидер в 3rd party tooling. Такие компании, как Redis Labs, Amazon и другие, предлагают множество полезных инструментов и услуг redis. Экосистема вокруг redis намного больше. Количество крупномасштабных развертываний теперь, вероятно, больше, чем для memcached.

Суперсет Redis

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

документация

Redis лучше документирован, чем memcached. Хотя это может быть субъективным, это кажется все более и более истинным все время.

редис.Ио фантастический легко ориентируемый ресурс. Это позволяет вам попробуйте redis в браузере и даже дает вам живые интерактивные примеры с каждой командой в документах.

там теперь 2x столько результатов stackoverflow для redis, сколько memcached. 2x как много результатов Google. Более доступные примеры на большем количестве языков. Более активное развитие. Более активное развитие клиента. Эти измерения могут мало что значить по отдельности, но в сочетании они рисуют четкую картину того, что поддержка и документация для redis больше и намного более актуальны.

настойчивость

по умолчанию redis сохраняет ваши данные на диск с помощью механизм фиксации. Если у вас достаточно оперативной памяти, он может записывать все ваши данные на диск почти без снижения производительности. Это почти бесплатно!

в режиме моментального снимка есть шанс, что внезапный сбой может привести к небольшому количеству потерянных данных. Если вам абсолютно необходимо убедиться, что данные никогда не теряются, не волнуйтесь, redis имеет свою спину там тоже с режимом AOF (добавить только файл). В этом режиме сохраняемости данные можно синхронизировать с диском по мере записи. Это может уменьшите максимальную пропускную способность записи, чтобы ваш диск мог писать быстро, но все равно должен быть довольно быстрым.

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


используйте Redis if

  1. требуется выборочное удаление / истечение элементов в кэше. (Тебе это нужно)

  2. требуется возможность запроса ключей определенного типа. эквивалент. 'blog1: сообщения:*', ' blog2:категории:xyz: сообщения:*'. О да! это очень важно. Используйте это для выборочного аннулирования определенных типов кэшированных элементов. Вы также можете использовать это для аннулирования кэша фрагментов, кэша страниц, только AR-объектов данного типа, так далее.

  3. Persistence (вам это тоже понадобится, если вы не в порядке с вашим кэшем, который нужно разогревать после каждого перезапуска. Очень важно для объектов, которые редко меняются)

используйте memcached, если

  1. Memcached дает вам headached!
  2. МММ... кластеризация? meh. если вы собираетесь зайти так далеко, используйте лак и Redis для кэширования фрагментов и AR-объектов.

из моего опыта у меня было намного лучше стабильность с Redis, чем Memcached


Memcached является многопоточным и быстрым.

Redis имеет множество функций и очень быстр, но полностью ограничен одним ядром, поскольку он основан на цикле событий.

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


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

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

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

по умолчанию redis использует jemalloc распределитель памяти, который старается изо всех сил быть компактным и быстрым, но это распределитель памяти общего назначения, и он не может идти в ногу с большим количеством выделений и очистки объектов происходит с высокой скоростью. Из-за этого, на некотором грузе шаблоны redis процесс, по-видимому, может утечка памяти из-за внутренней фрагментации. Например, если у вас есть сервер с 7 Gb RAM и вы хотите использовать redis в качестве непостоянного кэша LRU, вы можете найти этот процесс redis с maxmemory установить на 5Gb с течением времени будет использовать все больше и больше памяти, в конечном итоге нажав общий предел ОЗУ, пока убийца из памяти не вмешается.

memcached лучше подходит для сценария, описанного выше, поскольку он управляет своей памятью совершенно по-другому. как memcached выделяет один большой кусок памяти-все, что ему когда - либо понадобится-а затем управляет этой памятью самостоятельно, используя свой собственный реализованный плиты распределителя. Кроме того, memcached изо всех сил пытается сохранить внутреннюю фрагментацию низкой, так как на самом деле использует алгоритм LRU per-slab, когда выселения LRU выполняются с учетом размера объекта.

С учетом сказанного, memcached по-прежнему имеет сильную позицию в средах, где использование памяти должно быть принудительным и/или быть предсказуемый. Мы попытались использовать последний стабильный redis (2.8.19) в качестве непостоянной замены memcached на основе LRU в рабочей нагрузке 10-15k op/s, и он сильно просочился в память; та же рабочая нагрузка сбой экземпляров ElastiCache redis Amazon через день или около того по тем же причинам.


Memcached хорош в том, чтобы быть простым хранилищем ключей / значений и хорошо делать key => STRING. Это делает его действительно хорошим для хранения сеанса.

Redis хорош в выполнении key => SOME_OBJECT.

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

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


Если вы не против грубого стиля письма,Redis vs Memcached в блоге Systoilet стоит прочитать с точки зрения удобства использования, но обязательно прочитайте назад и вперед в комментариях, прежде чем делать какие-либо выводы о производительности; есть некоторые методологические проблемы (однопоточные тесты с циклом занятости), и Redis также внес некоторые улучшения с момента написания статьи.

и никакая ссылка на бенчмарк не завершена без путаницы, так что также проверьте некоторые конфликтующие критерии в Dormondo в ЖЖ и в Antirez блог.

редактировать -- как указывает Антирез, анализ Systoilet довольно непродуманный. Даже несмотря на нехватку одного потока, большая часть несоответствия производительности в этих тестах может быть связана с клиентскими библиотеками, а не с пропускной способностью сервера. Ориентиры на в Antirez блог действительно ли представить гораздо больше яблоки-к-яблокам (с тем же ртом) сравнение.


Я получил возможность использовать memcached и redis вместе в прокси-сервере кэширования, над которым я работал, позвольте мне поделиться с вами, где именно я использовал то, что и причина того же....

Redis>

1) используется для индексации содержимого кэша по кластеру . У меня более миллиарда ключей в распределении по кластерам redis , время отклика redis довольно меньше и стабильно .

2) в основном, его хранилище ключей / значений, так что где - либо в вашем приложении вы имейте что-то подобное, можно использовать redis с большим беспокойством.

3) постоянство Redis, отказоустойчивость и резервное копирование (AOF ) облегчат вашу работу .

Memcache >

1) да , оптимизация памяти, которая может использоваться в качестве кэша . Я использовал его для хранения содержимого кэша, доступ к которому очень часто (с 50 ударами в секунду)с размером менее 1 МБ .

2) я выделил только 2GB из 16 GB для memcached, что тоже, когда мой размер одного контента был >1MB .

3) по мере того , как содержание растет вблизи пределов, иногда я наблюдал более высокое время отклика в статистике(не в случае с redis).

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

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

enter image description here

enter image description here

надеюсь, что это помогает!!


еще один бонус заключается в том, что может быть очень ясно, как memcache будет вести себя в сценарии кэширования, в то время как redis обычно используется в качестве постоянного хранилища данных, хотя его можно настроить так же, как memcached aka выселение наименее недавно использованных элементов, когда он достигает максимальной емкости.

некоторые приложения, над которыми я работал, используют оба, чтобы прояснить, как мы намерены вести себя с данными-материал в memcache, мы пишем код для обработки случаев, когда его нет-материал в redis, мы положись на то, что он там.

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


было бы не неправильно, если мы скажем, что redis-это комбинация (кэш + структура данных), а memcached-это просто кэш.


одно важное отличие, которое не было указано здесь, заключается в том, что Memcache имеет верхний предел памяти во все времена, в то время как Redis не по умолчанию (но может быть настроен). Если вы всегда хотите хранить ключ / значение в течение определенного времени (и никогда не выселять его из-за нехватки памяти), вы хотите пойти с Redis. Конечно, вы также рискуете проблемой нехватки памяти...


очень простой тест для установки и получения 100k уникальных ключей и значений против redis-2.2.2 и memcached. Оба работают на Linux VM (CentOS), а мой клиентский код(вставленный ниже) работает на рабочем столе windows.

Redis

  • время, необходимое для хранения 100000 значений, равно = 18954ms

  • время загрузки 100000 значений равно = 18328ms

Memcached

  • время, необходимое для хранения 100000 значений, равно = 797ms

  • время, необходимое для получения 100000 значений, равно = 38984ms


Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

мы думали о Redis как взлет нагрузки для нашего проекта на работе. Мы думали, что, используя модуль в nginx под названием HttpRedis2Module или что-то подобное, у нас будет потрясающая скорость, но при тестировании с AB-test мы оказались неправы.

возможно, модуль был плохим или нашим макетом, но это была очень простая задача, и было еще быстрее взять данные с php, а затем вставить его в MongoDB. Мы используем APC в качестве кэширующей системы и с этим php и MongoDB. Это было намного быстрее, чем модуль nginx для Redis.

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


самая большая оставшаяся причина-это специализация.

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

Если вы собираетесь настроить выделенный экземпляр Redis, который будет использоваться только как экземпляр LRU, чтобы избежать этого конкретный сценарий, то на самом деле нет никаких убедительных причин использовать Redis над Memcached.

Если вам нужен надежный" никогда не идет вниз " кэш LRU...Memcached будет соответствовать законопроекту, так как невозможно, чтобы у него закончилась память по дизайну, а функциональность specialize не позволяет разработчикам пытаться сделать это так, чтобы это могло угрожать этому. Простое разделение обязанностей.


Redis-это лучше Плюсы Redis являются,

1.It has a lot of data storage options such  as  string  , sets , sorted sets ,  hashes ,  bitmaps
2.Disk Persistence of records 
3.Stored Procedure (LUA acripting)  support
4.Can act as a Message Broker using PUB/SUB

тогда как Memcache-это система типов кэша значений ключей в памяти.

  1. отсутствие поддержки для различных хранилищ типа данных как списки, наборы как внутри Рэдис.
  2. основным мошенничеством является Memcache без сохранения диска .

Memcached будет быстрее, если вы заинтересованы в производительности, даже если Redis включает в себя сеть (TCP-вызовы). Также внутренне Memcache быстрее.

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


Ну, я в основном использовал оба с моими приложениями, Memcache для кэширования сеансов и redis для объектов запросов doctrine/orm. С точки зрения производительности оба почти одинаковы.