Мы используем веб-приложение Ruby с Redis для кэширования. Есть ли смысл тестировать Memcached вместо этого?
Что даст нам лучшую производительность? Любые плюсы или минусы между Redis и Memcached?
Вопросы для рассмотрения:
Обновлено 3 июня 2017 года
Redis более мощный, более популярный и лучше поддерживается, чем memcached. Memcached может сделать лишь небольшую часть вещей, которые может сделать Redis. Redis лучше даже там, где их функции перекрываются.
Для чего-нибудь нового используйте Redis.
Оба инструмента - это мощные, быстрые хранилища данных в памяти, которые полезны в качестве кеша. Оба могут помочь ускорить ваше приложение путем кэширования результатов базы данных, фрагментов HTML или чего-то еще, что может быть дорого сгенерировано.
При использовании для одной и той же вещи, вот как они сравнивают, используя исходный вопрос "Очки для рассмотрения":
Memcached - это простой волатильный сервер кеша. Он позволяет хранить пары ключ/значение, где значение ограничено строкой до 1 МБ.
Хорошо, но это все. Вы можете получить доступ к этим значениям по их ключу с чрезвычайно высокой скоростью, часто насыщая доступную сеть или даже пропускную способность памяти.
При перезапуске memcached ваши данные исчезли. Это нормально для кеша. Вы не должны хранить ничего важного там.
Если вам нужна высокая производительность или высокая доступность, доступны сторонние инструменты, продукты и услуги.
Redis может выполнять те же задания, что и memcached, и может сделать их лучше.
Redis может действовать как кеш. Он также может хранить пары ключ/значение. В redis они могут быть даже до 512 МБ.
Вы можете отключить настойчивость, и он тоже будет потерять ваши данные при перезагрузке. Если вы хотите, чтобы ваш кеш пережил перезагрузки, он также позволяет вам это делать. Фактически, это значение по умолчанию.
Он очень быстрый, часто ограниченный сетью или пропускной способностью памяти.
Если один экземпляр redis/memcached недостаточно для вашей рабочей нагрузки, redis - это четкий выбор. Redis включает поддержку кластера и поставляется с инструментами высокой доступности (redis-sentinel) справа "в поле". За последние несколько лет redis также стал явным лидером в сторонних инструментах. Такие компании, как Redis Labs, Amazon и другие, предлагают множество полезных инструментов и услуг redis. Экосистема вокруг redis намного больше. Число широкомасштабных развертываний теперь, вероятно, больше, чем для memcached.
Redis - это больше, чем кеш. Это сервер структуры данных в памяти. Ниже вы найдете краткий обзор вещей, которые Redis может сделать за пределами простого кеша ключ/значение, такого как memcached. Большинство функций redis - вещи, которые memcached не может сделать.
Redis лучше документирован, чем memcached. Хотя это может быть субъективным, все это кажется все более и более истинным.
redis.ioявляется фантастическим легко перемещаемым ресурсом. Он позволяет попробовать redis в браузере и даже дает вам живые интерактивные примеры с каждой командой в документах.
В настоящее время существует 2x столько же результатов stackoverflow для redis, что и memcached. 2x столько же результатов Google. Более доступные примеры на других языках. Более активное развитие. Более активное развитие клиентов. Эти измерения могут не означать много индивидуально, но в комбинации они рисуют четкую картину, что поддержка и документация для redis больше и намного более актуальны.
По умолчанию redis сохраняет ваши данные на диск с помощью механизма snapshotting. Если у вас достаточно доступной оперативной памяти, она может записывать все ваши данные на диск, практически не ухудшая производительность. Это почти бесплатно!
В режиме моментального снимка есть вероятность, что внезапный сбой может привести к небольшому количеству потерянных данных. Если вам абсолютно необходимо убедиться, что данные не потеряны, не волнуйтесь, redis также имеет вашу спину с режимом AOF (Append Only File). В этом режиме сохранения данные могут быть синхронизированы с диском по мере его записи. Это может снизить максимальную пропускную способность записи, однако скорость вашего диска может быть записана, но должна быть довольно быстрой.
Есть много вариантов конфигурации, чтобы точно настроить сохранение, если вам нужно, но значения по умолчанию очень разумные. Эти параметры упрощают настройку redis как безопасного, избыточного места для хранения данных. Это реальная база данных.
Memcached ограничивается строками, но Redis - это сервер структуры данных, который может обслуживать множество разных типов данных. Он также предоставляет команды, необходимые для максимального использования этих типов данных.
Простые текстовые или двоичные значения, размер которых может быть до 512 МБ. Это единственный тип данных redis и memcached, хотя memcached-строки ограничены 1MB.
Redis предоставляет вам больше инструментов для использования этого типа данных, предлагая команды для побитовых операций, манипуляции на уровне бит, поддержки приращения/уменьшения с плавающей запятой, запросов диапазона и операций с несколькими ключами. Memcached не поддерживает это.
Строки полезны для всех видов прецедентов, поэтому memcached довольно полезен только для этого типа данных.
Хеши вроде хранилища значений ключей в хранилище значений ключей. Они отображают между строковыми полями и строковыми значениями. Карты Field- > value с использованием хэша немного более эффективны по площади, чем карты key- > value, используя регулярные строки.
Хэши полезны в качестве пространства имен или когда вы хотите логически группировать многие ключи. С помощью хэша вы можете эффективно использовать всех членов, истечь всех членов вместе, удалить всех членов вместе и т.д. Отлично подходит для любого варианта использования, когда у вас есть несколько пар ключ/значение, которые необходимо сгруппировать.
Одним из примеров использования хэша является сохранение пользовательских профилей между приложениями. Хэши redis хранятся с идентификатором пользователя, так как ключ позволит вам хранить как можно больше бит данных о пользователе, сохраняя при этом их хранение под одним ключом. Преимущество использования хэша вместо сериализации профиля в строке состоит в том, что вы можете иметь разные приложения для чтения/записи разных полей в профиле пользователя, не беспокоясь о том, что одно приложение переопределяет изменения, сделанные другими (что может произойти, если вы сериализуете устаревшие данные).
Списки Redis представляют собой упорядоченные коллекции строк. Они оптимизированы для вставки, чтения или удаления значений из верхнего или нижнего (aka: left или right) списка.
Redis предоставляет много commands для использования списков, включая команды для push/pop items, push/pop между списками, обрезание списков, выполнение диапазон запросов и т.д.
Списки делают большие прочные, атомные очереди. Они отлично подходят для очередей заданий, журналов, буферов и многих других случаев использования.
Установки представляют собой неупорядоченные коллекции уникальных значений. Они оптимизированы, чтобы вы могли быстро проверить, установлено ли значение в наборе, быстро добавлять/удалять значения и измерять перекрытие с другими наборами.
Они отлично подходят для таких вещей, как списки контроля доступа, уникальные трекеры посетителей и многое другое. Большинство языков программирования имеют нечто похожее (обычно называемое Set). Это похоже на то, что распространяется только.
Redis предоставляет несколько commands для управления наборами. Очевидны такие, как добавление, удаление и проверка набора. Таким образом, менее очевидные команды, такие как выскакивание/чтение случайного элемента и команды для выполнения объединений и пересечений с другими наборами.
Сортированные наборы также являются коллекциями уникальных значений. Эти, как следует из названия, упорядочены. Они упорядочиваются по счету, затем лексикографически.
Этот тип данных оптимизирован для быстрого поиска по счету. Получение наивысшего, самого низкого или любого диапазона значений между ними происходит очень быстро.
Если вы добавите пользователей в отсортированный набор вместе с их высоким счетом, у вас будет идеальная доска лидеров. Когда появятся новые высокие результаты, просто добавьте их в набор снова с их высоким счетом, и он будет переупорядочивать ваш лидирующий борт. Также отлично подходит для отслеживания последнего посещения пользователями и активного пользователя в вашем приложении.
Сохранение значений с одинаковой оценкой заставляет их упорядочиваться лексикографически (мыслить в алфавитном порядке). Это может быть полезно для таких функций, как функции автозаполнения.
Многие из отсортированного набора commands похожи на команды для наборов, иногда с дополнительным параметром оценки. Также включены команды для управления оценками и запросов по результату.
Redis имеет несколько commands для хранения, извлечения и измерения географических данных. Это включает в себя радиус-запросы и измерение расстояний между точками.
Технически географические данные в redis хранятся в отсортированных наборах, поэтому это не действительно отдельный тип данных. Это больше расширение на вершине отсортированных множеств.
Подобно geo, это не полностью отдельные типы данных. Это команды, которые позволяют обрабатывать строковые данные, как если бы они были либо растровыми, либо гиперлогами.
Растровые изображения - это то, к чему относятся операторы уровня бит, на которые я ссылаюсь в Strings. Этот тип данных был основным строительным блоком для недавнего совместного арт-проекта reddit: r/Place.
HyperLogLog позволяет использовать постоянное чрезвычайно малое количество пространства для подсчета почти неограниченных уникальных значений с потрясающей точностью. Используя только ~ 16 КБ, вы можете эффективно подсчитывать количество уникальных посетителей на вашем сайте, даже если это число в миллионах.
Команды redis являются атомарными, что означает, что вы можете быть уверены, что как только вы напишете значение для redis, это значение будет видимым для всех клиентов, подключенных к redis. Нет никакого ожидания распространения этого значения. Технически memcached также является атомарным, но с redis, добавляющим всю эту функциональность за пределы memcached, стоит отметить и несколько впечатляюще, что все эти дополнительные типы данных и функции также являются атомарными.
Несмотря на то, что в реляционных базах данных не совсем то же самое, что и транзакции в реляционных базах данных, redis также имеет transactions, которые используют "оптимистичную блокировку" (WATCH/MULTI/EXEC).
Redis предоставляет функцию, называемую pipelining '. Если у вас есть много команд redis, которые вы хотите выполнить, вы можете использовать конвейерную обработку для отправки их для повторного использования "все-в-одном" вместо одного раза в день.
Обычно, когда вы выполняете команду для redis или memcached, каждая команда представляет собой отдельный цикл запроса/ответа. При конвейерной обработке redis может буферизовать несколько команд и выполнять их все сразу, отвечая на все ответы на все ваши команды за один ответ.
Это может позволить вам достичь еще большей пропускной способности при массовом импорте или других действиях, которые включают в себя множество команд.
Redis имеет commands, посвященный pub/sub function, что позволяет redis выступать в качестве высокоскоростного вещательного вещателя. Это позволяет одному клиенту публиковать сообщения для многих других клиентов, подключенных к каналу.
Redis делает pub/sub, а также практически любой инструмент. Выделенные брокеры сообщений, такие как RabbitMQ, могут иметь преимущества в определенных областях, но тот факт, что тот же сервер может также предоставить вам постоянные долговременные очереди и другие данные структура вашей паба/вспомогательной нагрузки, вероятно, потребуется, Redis часто оказывается лучшим и самым простым инструментом для работы.
Вы можете подумать о сценариях lua, например redis собственный SQL или хранимые процедуры. Это и больше, и меньше, но аналогия в основном работает.
Возможно, у вас есть сложные вычисления, которые вы хотите выполнить redis. Возможно, вы не можете позволить себе вернуть свои транзакции и нуждаться в гарантиях, каждый шаг сложного процесса будет происходить атомарно. Эти проблемы и многие другие могут быть решены с помощью сценариев lua.
Весь script выполняется атомарно, поэтому, если вы можете поместить свою логику в lua script, вы часто можете избежать беспорядка с оптимистичными транзакциями блокировки.
Как упоминалось выше, redis включает встроенную поддержку кластеризации и в комплекте с его собственным инструментом высокой доступности под названием redis-sentinel.
Без колебаний я бы рекомендовал redis над memcached для любых новых проектов или существующих проектов, которые еще не используют memcached.
Вышеприведенное может звучать так, как будто мне не нравится memcached. Напротив, это мощный, простой, стабильный, зрелый и закаленный инструмент. Есть даже некоторые варианты использования, где это немного быстрее, чем redis. Я люблю memcached. Я просто не думаю, что это имеет смысл для будущего развития.
Redis делает все memcached, часто лучше. Любое преимущество производительности для memcached является незначительным и зависит от нагрузки. Есть также рабочие нагрузки, для которых redis будет быстрее, и многие другие рабочие нагрузки, которые redis могут делать, которые memcached просто не могут. Крошечные отличия в производительности кажутся незначительными перед лицом гигантского залива в функциональности, и тот факт, что оба инструмента настолько быстры и эффективны, что они могут быть последним элементом вашей инфраструктуры, вам когда-либо придется беспокоиться о масштабировании.
Существует только один сценарий, в котором memcached имеет больше смысла: где memcached уже используется в качестве кеша. Если вы уже кэшируете memcached, продолжайте использовать его, если он соответствует вашим потребностям. Скорее всего, не стоит пытаться переходить на redis, и если вы собираетесь использовать redis только для кеширования, это может не принести достаточно пользы, чтобы стоить вашего времени. Если memcached не отвечает вашим потребностям, вы, вероятно, должны перейти к redis. Это верно, нужно ли масштабировать за пределы memcached или вам нужны дополнительные функции.
Использовать Redis, если
Вам нужно выборочно удалять/истекать элементы в кеше. (Вам это нужно)
Вам нужна возможность запрашивать ключи определенного типа. э. 'blog1: posts: *', 'blog2: categories: xyz: posts: *'. о, да! это очень важно. Используйте это для выборочного исключения некоторых типов кэшированных элементов. Вы также можете использовать это, чтобы аннулировать кеш фрагмента, кеш страниц, только объекты AR данного типа и т.д.
Стойкость (вам также понадобится это, если только вы не будете готовы к тому, что ваш кеш должен прогреться после каждого перезапуска. Очень важно для объектов, которые редко меняются)
Использовать memcached, если
По моему опыту у меня была намного лучшая стабильность с Redis, чем у Memcached
Memcached является многопоточным и быстрым.
Redis имеет множество функций и очень быстро, но полностью ограничен одним ядром, поскольку он основан на цикле событий.
Мы используем оба. Memcached используется для кэширования объектов, в основном уменьшая нагрузку на чтение в базах данных. Redis используется для таких вещей, как отсортированные наборы, которые удобны для свертывания данных временных рядов.
Это слишком долго, чтобы быть отправленным как комментарий к уже принятому ответу, поэтому я поместил его как отдельный ответ
Следует также рассмотреть вопрос о том, ожидаете ли вы иметь жесткий верхний предел памяти в своем кеше.
Поскольку redis - это база данных nosql с множеством функций, а кэширование - это только один вариант, для которого он может быть использован, он выделяет память по мере необходимости - чем больше объектов вы вставляете в нее, тем больше памяти она использует. Опция maxmemory не обеспечивает строгое ограничение использования верхней памяти. Когда вы работаете с кешем, ключи выселяются и истек; вероятность того, что ваши ключи не имеют одинакового размера, поэтому происходит фрагментация внутренней памяти.
По умолчанию redis использует jemalloc распределитель памяти, который изо всех сил пытается быть как компактным, так и быстрым, но является общим и он не может справиться с большим количеством распределений и очистки объектов, происходящих с высокой скоростью. Из-за этого на некоторых моделях нагрузки процесс redis может, по-видимому, течь из-за внутренней фрагментации. Например, если у вас есть сервер с ОЗУ 7 Гб, и вы хотите использовать redis как ненастоящий LRU-кеш, вы можете обнаружить, что процесс redis с maxmemory, установленным на 5 Гбит с течением времени, будет использовать все больше и больше памяти, Ограничение RAM до тех пор, пока не удастся избежать убийцы из памяти.
memcached лучше подходит для сценария, описанного выше, поскольку он управляет своей памятью совершенно по-другому. memcached выделяет один большой кусок памяти - все, что ему когда-либо понадобится, - и затем управляет этой памятью самостоятельно, используя собственный реализованный slab allocator. Более того, memcached пытается усложнить внутреннюю фрагментацию, так как на самом деле использует алгоритм LRU на основе slab, когда выселение LRU выполняется с учетом размера объекта.
С учетом сказанного, memcached все еще имеет сильную позицию в средах, где использование памяти должно быть принудительно и/или быть предсказуемым. Мы попытались использовать последний стабильный redis (2.8.19) в качестве неактивной заменой memcached на основе LRU с рабочей нагрузкой в 10-15 тыс. Операционных систем и утечкой памяти A LOT; одна и та же рабочая нагрузка приводила к сбоям экземпляров Amazon ElastiCache redis через день или около того по тем же причинам.
Memcached хорош в простом хранилище ключей/значений и хорош в выполнении клавиши = > STRING. Это делает его действительно полезным для хранения сеансов.
Redis хорошо делает ключ = > SOME_OBJECT.
На самом деле это зависит от того, что вы собираетесь там положить. Я понимаю, что с точки зрения производительности они довольно ровные.
Также удачи в поиске каких-либо объективных тестов, если вы действительно найдете их, отправьте им свой путь.
Если вы не против сложного стиля письма, Redis vs Memcached в блоге Systoilet стоит прочитать с точки зрения удобства использования, но обязательно прочитайте комментарии и комментарии в комментариях, прежде чем делать какие-либо выводы о производительности; есть некоторые методологические проблемы (однопоточные тесты с занятой петлей), и Redis сделал некоторые улучшения, так как статья была написана также.
И никакая эталонная ссылка не будет заполнена, не запутав некоторые вещи, поэтому также проверьте некоторые противоречивые критерии в Dormondo LiveJournal и веб-журнал Antirez.
Изменить - как указывает Антирез, анализ Systoilet довольно плохо продуман. Даже за пределами однопоточного дефицита большая часть несоответствия производительности в этих тестах может быть отнесена к клиентским библиотекам, а не к пропускной способности сервера. В тестах веб-журнал Antirez действительно присутствует гораздо больше сравнения яблок с яблоками (с одним и тем же ртом).
У меня появилась возможность использовать memcached и redis вместе в кэширующем прокси, с которым я работал, позвольте мне поделиться вами, где именно я использовал то, что и причина того же....
Redis >
1) Используется для индексирования содержимого кеша по кластеру. У меня более миллиарда ключей в распределении по кланам redis, время ответа redis довольно мало и стабильно.
2) В принципе, это хранилище ключей/значений, поэтому, когда бы вы ни находились в своем приложении, у вас есть что-то подобное, можно использовать redis с большим трудом.
3) Настойчивость Redis, резервное копирование и резервное копирование (AOF) облегчат вашу работу.
Memcache >
1) да, оптимизированная память, которая может использоваться как кеш. Я использовал его для хранения доступа к кешу очень часто (с 50 ударами в секунду) с размером менее 1 МБ.
2) Я выделил только 2 ГБ из 16 ГБ для memcached, что тоже, когда мой размер одного контента был > 1 МБ.
3) Поскольку содержание растет вблизи пределов, иногда я наблюдал более высокие времена отклика в статистике (не в случае redis).
Если вы просите об общем опыте, Redis очень зеленый, так как он легко настраивается, очень гибкий со стабильными надежными функциями.
Кроме того, на этой странице 
Надеюсь, это поможет!
Еще один бонус заключается в том, что может быть очень ясно, как memcache будет вести себя в сценарии кэширования, в то время как redis обычно используется в качестве постоянного хранилища данных, хотя он может быть настроен так, чтобы вести себя так же, как memcached aka evicting Least Recent Used items when он достигает максимальной емкости.
Некоторые приложения, над которыми я работал, используют как просто для того, чтобы дать понять, как мы намерены вести данные - материал в memcache, мы пишем код для обработки случаев, когда его нет - в redis, мы полагаемся на он был там.
Кроме того, Redis обычно считается превосходным, поскольку большинство случаев использования более функциональны и, следовательно, гибки.
Test. Запустите несколько простых тестов. Долгое время я считал себя старым школьным носорогом, так как я использовал в основном memcached и считал Redis новым ребенком.
С моей нынешней компанией Redis использовался в качестве основного кеша. Когда я врывался в статистику производительности и просто начал тестировать, Redis был с точки зрения производительности сопоставимым или минимальным медленнее, чем MySQL.
Memcached, хотя и упрощен, вывел Redis из воды полностью. Он значительно улучшился:
Кроме того, на мой взгляд, намного лучше реализована политика выселения memcached, что приводит к более стабильному среднему времени отклика при обработке большего количества данных, чем может обрабатывать кеш.
Некоторые бенчмаркинга показали, что Redis, в нашем случае, работает очень плохо. Я считаю, что это связано со многими переменными:
Лично я не разделяю мнение авторов Redis на concurrency и многопоточности.
Было бы ошибкой, если мы скажем, что redis - это комбинация (структура кэша + данных), а memcached - только кеш.
Одно существенное отличие, которое не было указано здесь, это то, что Memcache всегда имеет верхний предел памяти, а Redis по умолчанию (но может быть настроен). Если вы всегда хотели бы хранить ключ/значение за определенное количество времени (и никогда не выселяли его из-за низкой памяти), вы хотите пойти с Redis. Конечно, вы также рискуете проблемой нехватки памяти...
Очень простой тест для установки и получения уникальных ключей и значений 100k против redis-2.2.2 и memcached. Оба выполняются на виртуальной машине Linux (CentOS), а мой клиентский код (вставленный ниже) работает на рабочем столе Windows.
Redis
Время, затраченное на сохранение 100000 значений, составляет = 18954 мс
Время загрузки 100000 значений = 18328мс
Memcached
Время, затраченное на сохранение 100000 значений, равно 797 мс
Время, необходимое для извлечения 100000 значений, составляет = 38984мс
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-тестом мы оказались неверными.
Возможно, модуль был плохим или наш макет, но это была очень простая задача, и было даже быстрее брать данные с php, а затем вносить в MongoDB. Мы используем APC в качестве кэширующей системы и с этим php и MongoDB. Это было намного быстрее, чем модуль nginx Redis.
Мой совет - проверить его самостоятельно, при этом он покажет вам результаты для вашей среды. Мы решили, что использование Redis было ненужным в нашем проекте, так как это не имеет никакого смысла.
Самая большая оставшаяся причина - специализация.
Redis может делать много разных вещей, и один побочный эффект от этого - разработчики могут начать использовать множество этих различных наборов функций в одном экземпляре. Если вы используете функцию LRU для Redis для кеша на стороне жесткого хранилища данных, которая НЕ является LRU, вполне возможно, что у вас закончилась нехватка памяти.
Если вы собираетесь настроить выделенный экземпляр Redis, который будет использоваться ТОЛЬКО как экземпляр LRU, чтобы избежать этого конкретного сценария, тогда нет действительно веских оснований для использования Redis над Memcached.
Если вам нужен надежный "никогда не снижающийся" кеш LRU... Memcached будет соответствовать законопроекту, поскольку он не может закончиться нехваткой памяти по дизайну, а специализированная функциональность не позволяет разработчикам пытаться сделать так, чтобы угрожать этому. Простое разделение проблем.
Memcached будет работать быстрее, если вы заинтересованы в производительности, даже потому, что Redis использует сетевые соединения (вызовы TCP). Также внутренне Memcache работает быстрее.
Redis имеет больше возможностей, как было отмечено в других ответах.
Redis лучше.
Плюсы Redis являются,
LUA скриптинг) Принимая во внимание, что Memcache - это система типов кэша значений ключа в памяти.
Я бы сказал redis, так как он намного быстрее, чем memcached, хотя он работает на одном ядре машины, а memcached можно запускать параллельно, потребуется большая обработка, чтобы нанести верхний предел redis, если правильно настроен
Ну, я в основном использовал как свои приложения, так и Memcache для кеширования сессий и redis для объектов doctrine/orm query. С точки зрения производительности они почти одинаковы.