Основною причиною, яку я сьогодні бачу як варіант використання memcached через Redis, є чудова ефективність пам'яті, яку ви могли б отримати за допомогою простого кешування фрагментів HTML (або подібних додатків). Якщо вам потрібно зберігати різні поля ваших об'єктів у різних клавішах, які зберігаються в пам’яті, тоді хеші Redis стануть більш ефективними в пам’яті, але коли у вас велика кількість пар ключів -> simple_string, memcached повинен мати можливість надавати вам більше елементів на мегабайт.
Інші речі, які є корисними щодо memcached:
- Це дуже простий шматок коду, тому, якщо вам просто потрібна функціональність, яку він надає, я думаю, це розумна альтернатива, але я ніколи не використовував його у виробництві.
- Він є багатопотоковим, тому, якщо вам потрібно масштабувати в одній коробці, це гарна річ, і вам потрібно поговорити лише з одним екземпляром.
Я вважаю, що Redis як кеш має все більше сенсу, коли люди рухаються до інтелектуального кешування або коли вони намагаються зберегти структуру кешованих даних за допомогою структур даних Redis.
Порівняння між Redis LRU та memcached LRU.
І memcached, і Redis не виконують реальних виселень LRU, а лише наближення цього.
Виселення пам’яті здійснюється за класом за розміром і залежить від деталей реалізації розподільника плит. Наприклад, якщо ви хочете додати елемент, який відповідає певному класу розміру, memcached спробує видалити елементи, що минули / нещодавно використовувались у цьому класі, замість того, щоб спробувати глобальну спробу зрозуміти, що таке об’єкт, незалежно від його розмір, що є найкращим кандидатом.
Натомість Редіс намагається вибрати хороший об'єкт як кандидата на виселення, коли досягнуто maxmemoryобмеження, дивлячись на всі об'єкти, незалежно від класу розміру, але здатний надати лише приблизно хороший об'єкт, не найкращий об'єкт з більшим простоєм час.
Редіс робить це шляхом вибірки кількох об’єктів, вибираючи той, який найдовше не працював (не був доступний). Починаючи з Redis 3.0 (на даний час у бета-версії) алгоритм був вдосконалений, а також приймає хороші пули кандидатів для виселення, тому наближення було покращено. У документації Redis ви можете знайти опис та графіки з подробицями того, як це працює .
Чому memcached має кращий розмір пам'яті, ніж Redis, для простих рядків -> рядкові карти.
Redis є більш складною частиною програмного забезпечення, тому значення в Redis зберігаються більш схожим чином на об'єкти мовою програмування високого рівня: вони мають пов'язаний тип, кодування, підрахунок посилань для управління пам'яттю. Це робить внутрішню структуру Redis гарною та керованою, але має накладні витрати порівняно з memcached, який має справу лише з рядками.
Коли Redis починає ефективніше використовувати пам’ять
Redis здатний зберігати невеликі сукупні типи даних спеціальним способом економії пам'яті. Наприклад, невеликий хеш Redis, що представляє об'єкт, зберігається всередині не з хеш-таблицею, а як двійковий унікальний BLOB-об'єкт. Отже, встановлення декількох полів для кожного об’єкта в хеш ефективніше, ніж зберігання N розділених ключів у memcached.
Ви можете, власне, зберегти об'єкт у memcached як єдину величину BLOB-коду JSON (або в двійковому кодуванні), але на відміну від Redis, це не дозволить вам отримати або оновити незалежні поля.
Перевага Redis в контексті інтелектуального кешування.
Через структури даних Redis, звичайний шаблон, що використовується з memcached знищення об'єктів, коли кеш недійсний, щоб відтворити його з БД пізніше, є примітивним способом використання Redis.
Наприклад, уявіть, що вам потрібно кешувати останні новини N, розміщені в Hacker News, щоб заповнити розділ "Найновіші" на сайті. Що ви робите з Redis, це складаєте список (обмежений до M елементів) із введеними найновішими новинами. Якщо ви використовуєте інше сховище для своїх даних, а Redis - як кеш, потрібно лише заповнити обидва подання (Redis і БД), коли буде опубліковано новий елемент. Немає можливості скасувати кеш.
Однак програма завжди може мати логіку, так що якщо список Redis виявляється порожнім, наприклад після запуску, початковий вигляд можна створити заново з БД.
Використовуючи інтелектуальне кешування, можна виконати кешування за допомогою Redis більш ефективно, ніж memcached, але не всі проблеми підходять для цього шаблону. Наприклад, кешування фрагментів HTML може не отримати вигоди від цієї техніки.