Memcached против Redis?

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

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

Вопросы для рассмотрения:

Read/write speed. Memory usage. Disk I/O dumping. Scaling.
 MarkHu27 мар. 2014 г., 03:06
Еще один анализ в дополнение к комментариям ниже:Google Trends: redis vs. memcached
 Ben Roberts11 нояб. 2014 г., 20:22
Один комментарий, который не гарантирует ответа: если вы смотрите на облачные сервисы для этих двух систем (например, heroku addons), сервисы Memcached иногда оказываются несколько дешевле на МБ по любой причине.
 the_red_baron23 нояб. 2016 г., 01:38
Для масштабируемости:Imgur and Twitter use both

Ответы на вопрос(17)

Решение Вопроса
Summary (TL;DR)

Updated June 3rd, 2017

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

Для всего нового используйте Redis.

Memcached vs Redis: Direct Comparison

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

Points to Consider

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

Read/write speed: Both are extremely fast. Benchmarks vary by workload, versions, and many other factors but generally show redis to be as fast or almost as fast as memcached. I recommend redis, but not because memcached is slow. It's not. Memory usage: Redis is better. memcached: You specify the cache size and as you insert items the daemon quickly grows to a little more than this size. There is never really a way to reclaim any of that space, short of restarting memcached. All your keys could be expired, you could flush the database, and it would still use the full chunk of RAM you configured it with. redis: Setting a max size is up to you. Redis will never use more than it has to and will give you back memory it is no longer using. I stored 100,000 ~2KB strings (~200MB) of random sentences into both. Memcached RAM usage grew to ~225MB. Redis RAM usage grew to ~228MB. After flushing both, redis dropped to ~29MB and memcached stayed at ~225MB. They are similarly efficient in how they store data, but only one is capable of reclaiming it. Disk I/O dumping: A clear win for redis since it does this by default and has very configurable persistence. Memcached has no mechanisms for dumping to disk without 3rd party tools. Scaling: Both give you tons of headroom before you need more than a single instance as a cache. Redis includes tools to help you go beyond that while memcached does not. memcached

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

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

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

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

redis

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

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

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

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

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

The Redis Superset

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

Documentation

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

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

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

Persistence

По умолчанию Redis сохраняет ваши данные на диск с помощью механизма, называемого снимком. Если у вас достаточно ОЗУ, он может записать все ваши данные на диск практически без снижения производительности. Это почти бесплатно!

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

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

Many Data Types

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

Strings (commands)

Простой текст или двоичные значения, размер которых может достигать 512 МБ. Это единственный тип данных redis и memcached share, хотя строки memcached ограничены 1 МБ.

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

Строки полезны для всех видов использования, поэтому memcached довольно полезен только с этим типом данных.

Hashes (commands)

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

Хеши полезны в качестве пространства имен или когда вы хотите логически сгруппировать много ключей. С помощью хэша вы можете эффективно захватить все элементы, удалить все элементы вместе, удалить все элементы вместе и т. Д. Отлично подходит для любого случая использования, когда у вас есть несколько пар ключ / значение, которые необходимо сгруппировать.

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

Lists (commands)

Списки Redis - это упорядоченные коллекции строк. Они оптимизированы для вставки, чтения или удаления значений сверху или снизу (иначе: слева или справа) списка.

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

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

Sets (commands)

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

Они отлично подходят для таких вещей, как списки контроля доступа, уникальные системы отслеживания посетителей и многое другое. Большинство языков программирования имеют нечто подобное (обычно называемое множеством). Это так, только распространяется.

Redis предоставляет несколькокоманды управлять сетами. Очевидные, такие как добавление, удаление и проверка набора, присутствуют. Поэтому менее очевидны такие команды, как запись / чтение случайного элемента и команды для объединения и пересечения с другими наборами.

Sorted Sets (commands)

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

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

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

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

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

Geo

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

Технически географические данные в Redis хранятся в отсортированных наборах, так что это не действительно отдельный тип данных. Это скорее расширение поверх отсортированных наборов.

Bitmap and HyperLogLog

Как и гео, они не полностью разделяют типы данных. Это команды, которые позволяют обрабатывать строковые данные, как если бы они были либо растровыми, либо гиперлоглогами.

Битовые карты - это операторы уровня битов, на которые я ссылалсяStrings для. Этот тип данных был основным строительным блоком для недавнего совместного арт-проекта reddit:г / Место.

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

Transactions and Atomicity

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

В отличие от транзакций в реляционных базах данных, Redis также имеетоперации которые используют «оптимистическую блокировку»; (ЧАСЫ/MULTI/EXEC).

Pipelining

Redis предоставляет функцию под названием & apos;конвейерная& APOS ;. Если у вас есть много команд redis, которые вы хотите выполнить, вы можете использовать конвейеризацию, чтобы отправлять их в redis «все за один раз», а не по одному.

Обычно, когда вы выполняете команду для redis или memcached, каждая команда представляет собой отдельный цикл запроса / ответа. С конвейерной передачей Redis может буферизовать несколько команд и выполнить их все одновременно, отвечая всеми ответами на все ваши команды в одном ответе.

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

Pub/Sub

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

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

Lua Scripting

Вы можете думать осценарии Луа как, например, собственный SQL или хранимые процедуры redis. Это больше и меньше, но аналогия в основном работает.

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

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

Scaling

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

Conclusion

Не задумываясь, я бы порекомендовал redis over memcached для любых новых проектов или существующих проектов, которые уже не используют memcached.

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

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

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

 06 мар. 2014 г., 16:33
как насчет кластеризации с сервером couchbase? (memcached совместимый)
 09 окт. 2012 г., 06:57
Как Memcached предлагает кластеризацию таким образом, который существует на самом сервере? Я всегда использовал библиотеки, которые распределялись в пул серверов memcached с использованием алгоритмов хеширования или модуля. То же самое относится и к Redis. В основном я использую Python, и, похоже, существует довольно много модулей, которые не используют библиотеку memcached для обработки пулов соединений.
 14 апр. 2013 г., 00:20
@ whardier Вы правы. Обновлен ответ, чтобы отразить, что кластер memcached поддерживает "quot" включен дополнительными инструментами. Должен был изучить это лучше.
 20 мар. 2013 г., 02:47
@ Олег, это не совсем так. Если вы используете multi-exec, команды буферизуются (то есть: не выполняются) до тех пор, пока exec не произойдет, поэтому, если у вас есть исключение перед exec, то никакие команды фактически не выполняются. Если вызывается exec, все буферизованные команды выполняются атомарно, если, конечно, переменная наблюдения не была изменена с момента первого вызова multi. Этот последний механизм является частью оптимистичной блокировки.
 20 февр. 2013 г., 13:40
& quot; Транзакции с оптимистичной блокировкой (WATCH / MULTI / EXEC) & quot; - Redis не имеет права транзакций. То есть если [multi, cmd1, cmd2, cmd3 (исключение), exec], то cmd1 и cmd2 будут выполнены.

This is too long to be posted as a comment to already accepted answer, so I put it as a separate answer

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

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

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

memcached лучше подходит для сценария, описанного выше, поскольку он управляет своей памятью совершенно по-другому. memcached выделяет один большой кусок памяти & # x2014; & # xA0; все, что ему когда-либо понадобится & # xA0; & # x2014; а затем управляет этой памятью самостоятельно, используя собственную реализованнуюраспределитель плит, Более того, memcached старается сохранить низкую внутреннюю фрагментацию, так как на самом делеиспользует алгоритм LRU для каждой плитыкогда выселение LRU осуществляется с учетом размера объекта.

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

 07 сент. 2015 г., 17:42
@StefanNch redis & apos;maxmemory опция не учитывает фрагментацию внутренней памяти. Пожалуйста, смотрите мой комментарий выше для деталей & # x2014; проблемы, которые я здесь описал, рассматривались в сценарии, описанном в «Redis как LRU-кэш»; страница с включенными параметрами ограничения памяти. С другой стороны, memcached использует другой подход, чтобы избежать проблемы фрагментации памяти, поэтому его предел памяти намного более "жесткий".
 04 сент. 2015 г., 10:11
Отredis.io/topics/faq: Redis has built-in protections allowing the user to set a max limit to memory usage, using the maxmemory option in the config file to put a limit to the memory Redis can use. If this limit is reached Redis will start to reply with an error to write commands (but will continue to accept read-only commands), or you can configure it to evict keys when the max memory limit is reached in the case you are using Redis for caching. We have documentation if you plan to use Redis as an LRU cache. link

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

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

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

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

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

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

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

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

Redis & gt;

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

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

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

Memcache & gt;

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

2) Я выделил только 2 ГБ из 16 ГБ для memcached, что также, когда мой единственный размер контента был & gt; 1 МБ.

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

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

Кроме того, на этомссылка на сайт ниже немного света от того же самого,

enter image description here

enter image description here

Надеюсь это поможет!!

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

С моей нынешней компанией Redis использовался как основной кеш. Когда я копался в статистике производительности и просто начинал тестирование, Redis был с точки зрения производительности сопоставимым или минимальнымslower чем MySQL.

Memcached, хотя и упрощенно, взорвал Redis из водыtotally, Масштабируется намного лучше:

for bigger values (required change in slab size, but worked) for multiple concurrent requests

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

Некоторые тесты показали, что Redis в нашем случае работает очень плохо. Я считаю, что это связано со многими переменными:

type of hardware you run Redis on types of data you store amount of gets and sets how concurrent your app is do you need data structure storage

Personally, I don't share the view Redis authors have on concurrency and multithreading.<,/p>

 20 мар. 2018 г., 09:35
Правда, мне сказали, что у меня нет этих данных для тестирования, но в этом конкретном случае было много операций чтения / записи
 18 мар. 2018 г., 18:23
объясните, пожалуйста, "как минимум, медленнее, чем MySQL".

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

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

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

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

 24 апр. 2014 г., 21:27
но это веб-масштаб, mongodb будет бегать по кругу, пока вы пишете. В настоящее время я пишу только в / dev / null, потому что это быстрее всего.
 05 июл. 2012 г., 19:40
Интересный ответ, но не уверен, поможет ли это ОП
 Sagiv Ofek05 июл. 2012 г., 14:46
кэширование было медленнее, чем запросы в БД? звучит странно..
 06 июл. 2012 г., 11:59
Вставка в Redis и использование его в качестве кэша происходило медленнее, чем при использовании APC + PHP + MongoDB. Но только вставка в Redis была НАМНОГО медленнее, чем вставка непосредственно в MongoDB. Без APC я думаю, что они довольно равны.
 24 апр. 2014 г., 09:01
Это потому, что Mongo не дает вам никаких гарантий того, что вы вставилиever будет записан на диск ...

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

И ни одна ссылка на эталон не является полной, не путая вещи немного, так что также проверьте некоторые противоречивые тесты наЖЖ Дормондо а такжеAntirez Weblog.

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

 30 дек. 2012 г., 08:37
 18 сент. 2015 г., 15:23
Более 2010 года, устаревший блог
 03 янв. 2013 г., 01:59
Вы не шутили о грубости.

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

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

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

You require selectively deleting/expiring items in the cache. (You need this)

You require the ability to query keys of a particular type. eq. 'blog1:posts:*', 'blog2:categories:xyz:posts:*'. oh yeah! this is very important. Use this to invalidate certain types of cached items selectively. You can also use this to invalidate fragment cache, page cache, only AR objects of a given type, etc.

Persistence (You will need this too, unless you are okay with your cache having to warm up after every restart. Very essential for objects that seldom change)

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

Memcached gives you headached! umm... clustering? meh. if you gonna go that far, use Varnish and Redis for caching fragments and AR Objects.

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

 31 июл. 2013 г., 10:42
Headached это шутка, верно? :-) Я погуглилmemcached headached но ничего разумного не нашел. (Я новичок в Memcached и Redis)
 29 апр. 2017 г., 03:33
Спасибо @KajMagnus за мой день .. возможно всю мою неделю
 01 нояб. 2012 г., 08:44
В документации Redis говорится, что для использования шаблонов требуется сканирование таблицы. blog1: posts: * может потребоваться сканирование таблицы O (N). Конечно, он все еще быстр для наборов данных разумного размера, так как Redis быстр. Это должно быть хорошо для тестирования или администратора.
 30 июл. 2015 г., 15:24
проголосовавшийdown по той же причине, что и @pellucide. Redis может быть лучше, чем Memcached, но Memcached тривиально использовать. У меня никогда не было с этим проблем, и это легко настроить.

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

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

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

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

 29 июн. 2012 г., 09:28
IMO тип данных Redis Hash имеет гораздо больше смысла для хранения переменных сеанса, чем для их сериализации в строку memcached.
 22 мар. 2013 г., 05:17
Если вам небезразличен пользовательский опыт, не помещайте свои сессии в кеш.dormando.livejournal.com/495593.html
 09 июл. 2014 г., 06:38
& quot; Не помещайте свои сеансы в кэш & quot; вводит в заблуждение. Вы имеете в виду & quot; не только хранить свои сессии в кэше & quot ;. Любой, кто хранит важные данные только в memcache, должен быть немедленно уволен.
 14 нояб. 2013 г., 20:04
@sebleblanc Теоретически это не должно быть проблемой с Redis, поскольку также существует стойкость диска.
 09 дек. 2013 г., 02:51
@sebleblanc memcache по-прежнему хорош в хранении сессий, плохо это реализовано или нет. да, выселение - это проблема, но она ни в коем случае не является непреодолимой, и это также не проблема memcache, если вы не беспокоитесь о выселении. Я полагаю, что большинство решений сессий memcache используют куки в качестве резервной копии.

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

Redis

Time taken to store 100000 values is = 18954ms

Time taken to load 100000 values is = 18328ms

Memcached

Time taken to store 100000 values is = 797ms

Time taken to retrieve 100000 values is = 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");
 30 мая 2018 г., 21:17
Поскольку вы, очевидно, использовали Java для измерения ... Вы "прогревались"? ваши тесты? Это очень важно для измерения за такое короткое время ... что JIT скомпилировал горячие точки.

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

 26 июл. 2015 г., 19:42
это хороший ответ - Laravel использует Redis в качестве кэша и в качестве механизма хранения данных

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 - это система типов кэша значений ключа в памяти.

No support for various data type storages like lists , sets as in redis. The major con is Memcache has no disk persistence .

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

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

 12 апр. 2018 г., 15:10
но вы все равно можете запустить $ core_count экземпляров Redis
 09 апр. 2018 г., 19:15
@siliconrockstar - уверен, что Redis 3 по-прежнему одноядерный; по крайней мере AWS Redis (который использует 3.2.6 или 3.2.10) предупреждает, чтобы принять это во внимание, например,EngineCpuUtilization Metrics
 10 апр. 2018 г., 22:07
Похоже, вы правы, я думаю, что когда я сделал этот комментарий, я основывал его на неполных источниках. Удаленный комментарий.
 01 мар. 2015 г., 00:47
Сайты с большим трафиком, которые вложили значительные средства в memcached и имеют узкие места в db по «нереляционным данным» профиля пользователя, должны оценитьcouchbase параллельно с обычным монго, редис
 05 нояб. 2018 г., 03:01
Redis чрезвычайно сосредоточен на эффективности - поэтому вам нужно спросить себя, почему кучка умных разработчиков решила оставить его однопоточным? Из документов Redis «Не очень часто ЦП становится вашим узким местом с Redis, так как обычно Redis связан либо с памятью, либо с сетью». Если бы вы использовали сервер grunty, который был связан с процессором, то у вас, вероятно, много пользователей, и в любом случае у вас должно быть несколько избыточных серверов. Если вы хотите максимально использовать несколько процессоров на одном сервере, используйте разделы. Читать:redis.io/topics/…

Ваш ответ на вопрос