Почему Redis превосходит Memcached для кеширования

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

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

Redis против Memcached для кеширования

Начнем с сходства. И Memcached, и Redis служат хранилищами данных «ключ-значение» в памяти, хотя Redis более точно описывается как хранилище структур данных. И Memcached, и Redis принадлежат к семейству решений для управления данными NoSQL, и оба основаны на модели данных «ключ-значение». Оба они хранят все данные в ОЗУ, что, конечно же, делает их чрезвычайно полезными в качестве уровня кэширования. С точки зрения производительности два хранилища данных также очень похожи, демонстрируя почти идентичные характеристики (и показатели) в отношении пропускной способности и задержки.

И Memcached, и Redis - зрелые и очень популярные проекты с открытым исходным кодом. Memcached был первоначально разработан Брэдом Фитцпатриком в 2003 году для веб-сайта LiveJournal. С тех пор Memcached был переписан на C (исходная реализация была на Perl) и помещен в общественное достояние, где он стал краеугольным камнем современных веб-приложений. Текущая разработка Memcached ориентирована на стабильность и оптимизацию, а не на добавление новых функций.

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

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

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

Когда использовать Memcached

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

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

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

Когда использовать Redis

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

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

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

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

Redis для сохранения данных

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

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

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

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

Репликация данных в памяти Redis 

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

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

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

Redis для анализа данных

На ум сразу приходят три сценария аналитики. В первом сценарии при использовании чего-то вроде Apache Spark для итеративной обработки больших наборов данных вы можете использовать Redis в качестве обслуживающего слоя для данных, ранее рассчитанных Spark. Во втором сценарии использование Redis в качестве общего распределенного хранилища данных в памяти может повысить скорость обработки Spark в 45–100 раз. Наконец, слишком распространенным сценарием является сценарий, в котором отчеты и аналитика должны быть настроены с помощью пользователя, но получение данных из изначально пакетных хранилищ данных (таких как Hadoop или СУБД) занимает слишком много времени. В этом случае хранилище структур данных в памяти, такое как Redis, является единственным практическим способом получить субмиллисекундное время подкачки и ответа.

При использовании очень больших наборов операционных данных или рабочих нагрузок аналитики запуск всего в памяти может оказаться нерентабельным. Чтобы достичь производительности менее миллисекунды при меньших затратах, Redis Labs создала версию Redis, которая работает с комбинацией RAM и flash, с возможностью настройки соотношения RAM и Flash. Хотя это открывает несколько новых возможностей для ускорения обработки рабочих нагрузок, это также дает разработчикам возможность просто запускать свой «кэш на флэш-памяти».

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

---

Итамар Хабер (@itamarhaber) - главный защитник разработчиков в Redis Labs, которая предлагает Memcached и Redis в качестве полностью управляемых облачных сервисов для разработчиков. Его разнообразный опыт включает в себя разработку и управление программными продуктами, а также руководящие должности в Xeround, Etagon, Amicada и MNS Ltd. Итамар имеет степень магистра делового администрирования по совместной программе Kellogg-Recanati Северо-Западного и Тель-Авивского университетов, а также степень бакалавра. наук в области компьютерных наук.

Форум новых технологий предоставляет площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубины и широты. Выбор является субъективным, основанным на нашем выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей. не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы отправляйте на [email protected]