Redis или Memcached: простое чтение даёт одному преимущество в 2,5 раза

В опубликованном кластерном испытании при 90% чтений и 10% записей Memcached достиг 40,6 тыс. операций в секунду против примерно 14,9 тыс. у Redis — преимущество превысило 2,5 раза. Для веб-приложения, которое часто получает готовые значения по ключу, это довод в пользу Memcached, но результат относится к конкретному стенду и профилю нагрузки.

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

Что именно измерили

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

В кластерном испытании использовали три машины в одном центре обработки данных, соединённые гигабитной сетью. Набор данных составлял около 8 ГБ, обращения к записям распределялись равномерно. У веб-приложения нагрузка часто устроена иначе: несколько популярных ключей получают большую долю запросов, ответы различаются по размеру, а промах кеша запускает обращение к основной базе. Эти различия способны изменить и задержку, и предел пропускной способности.

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

Когда достаточно Memcached

Документация Memcached описывает распределённый кеш в памяти для результатов запросов к базе, ответов внешнего API и сформированных страниц. Сервер хранит значение по ключу, но не разбирает структуру переданного объекта: сложные данные приложение сериализует само. Такой подход удобен, когда значение получают целиком, а после изменения исходных данных заменяют или пересчитывают.

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

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

Когда функции Redis меняют расчёт

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

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

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

Четыре сценария выбора

• Готовые ответы при частых попаданиях. Для фрагментов страниц и результатов запросов, которые можно пересчитать, Memcached соответствует простой операции «записать и получить». Его преимущество в исследовании ближе всего к этому случаю, если чтения действительно преобладают. Размер значений, распределение популярных ключей и доля промахов всё равно будут влиять на результат.
• Частое обновление целого объекта. Здесь ориентир на победителя при чтении может ошибочно направить выбор: в испытании с преобладанием записей впереди оказался Redis. Если приложение постоянно заменяет сериализованные объекты, имеют значение доля записей, параллельность и затраты на подготовку объекта до отправки в кеш.
• Частичное изменение данных и рейтинг. Redis уместнее, когда запросы работают с полями хеша, членами множества или частью упорядоченной коллекции. Хранение такой коллекции одним значением в Memcached переносит изменение и согласование данных в приложение. Сравнивать в этом случае только скорость получения значения по ключу недостаточно.
• Состояние, которое трудно восстановить. Если потеря содержимого нарушит работу приложения, важны источник истины и допустимая потеря изменений. Memcached обычно используют для восстанавливаемых значений. Redis предлагает режимы записи на диск, но их настройку следует оценивать вместе с задержкой записи и процедурой восстановления.

Как задержка дополняет показатель скорости

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

Для веб-приложения существенна также задержка медленных запросов во время пиков. Опубликованные измерения дают средние значения со стороны клиента, но не позволяют оценить такую задержку для конкретного приложения. Если основная работа — параллельное чтение простых восстанавливаемых значений, Memcached остаётся разумным первым кандидатом. Когда запросы используют структуры данных Redis или требуется настроить сохранение состояния, эти требования могут перевесить преимущество, полученное в тесте простого чтения.

Читайте также:

• Канадская мать подала в суд на OpenAI: «ChatGPT сказал моей дочери — возможно, это просто конец»
• Маркетолог не просто запускает рекламу: его работа начинается с данных
• Как проверить домен на занятость – самый простой способ