Основната причина, поради която виждам днес като случай на използване на memcached над Redis, е превъзходната ефективност на паметта, която трябва да можете да получите с обикновен Кеширане на HTML фрагменти (или подобни приложения). Ако трябва да съхранявате различни полета на вашите обекти в различни memcached ключове, тогава хешовете на Redis ще бъдат по-ефективни от паметта, но когато имате голям брой двойки ключ -> simple_string, memcached трябва да може да ви даде повече елементи на мегабайт.
Други неща, които са добри точки за memcached:
- Това е много проста част от кода, така че ако имате нужда само от функционалността, която предоставя, предполагам, че е разумна алтернатива, но никога не съм я използвал в производството.
- Той е многонишков, така че ако трябва да мащабирате в настройка с една кутия, това е нещо добро и трябва да говорите само с един екземпляр.
Вярвам, че Redis като кеш има все по-голям смисъл, когато хората се движат към интелигентно кеширане или когато се опитват да запазят структурата на кешираните данни чрез структури от данни на Redis.
Сравнение между Redis LRU и memcached LRU.
Както memcached, така и Redis не извършват реални изгонвания на LRU, а само приблизително.
Изхвърлянето на Memcache е клас по размер и зависи от подробностите за внедряването на неговия разпределител на плочи. Например, ако искате да добавите елемент, който се вписва в даден клас размер, memcached ще се опита да премахне изтекли/неизползвани елементи в този клас, вместо да опита глобален опит да разбере какъв е обектът, независимо от неговия размер, който е най-добрият кандидат.
Вместо това Redis се опитва да избере добър обект като кандидат за изгонване, когато maxmemory лимитът е достигнат, разглеждайки всички обекти, независимо от класа на размера, но е в състояние да предостави само приблизително добър обект, а не най-добрия обект с по-голямо време на престой.
Начинът, по който Redis прави това, е като взема проби от няколко обекта, избирайки този, който е неактивен (без достъп) за най-дълго време. След Redis 3.0 (в момента в бета версия) алгоритъмът беше подобрен и също така събира добри кандидати при изгонвания, така че приближението беше подобрено. В документацията на Redis можете да намерите описание и графики с подробности за това как работи.
Защо memcached има по-добър отпечатък на паметта от Redis за обикновен низ -> карти на низове.
Redis е по-сложен софтуер, така че стойностите в Redis се съхраняват по начин, по-подобен на обектите в език за програмиране на високо ниво:те имат асоцииран тип, кодиране, преброяване на референции за управление на паметта. Това прави вътрешната структура на Redis добра и управляема, но има допълнителни разходи в сравнение с memcached, който се занимава само с низове.
Когато Redis започне да работи по-ефективно с паметта
Redis е в състояние да съхранява малки обобщени типове данни по специален начин за пестене на памет. Например малък Redis Hash, представляващ обект, се съхранява вътрешно не с хеш таблица, а като двоичен уникален blob. Така че задаването на множество полета на обект в хеш е по-ефективно от съхраняването на N отделни ключа в memcached.
Всъщност можете да съхранявате обект в memcached като един JSON (или двоично кодиран) blob, но за разлика от Redis, това няма да ви позволи да извличате или актуализирате независими полета.
Предимството на Redis в контекста на интелигентното кеширане.
Поради структурите от данни на Redis, обичайният модел, използван с memcached за унищожаване на обекти, когато кешът е невалиден, за да го пресъздаде по-късно от DB, е примитивен начин за използване на Redis.
Например, представете си, че трябва да кеширате последните N новини, публикувани в Hacker News, за да попълните секцията „Най-нови“ на сайта. Това, което правите с Redis, е да вземете списък (ограничен до M елементи) с вмъкнати най-новите новини. Ако използвате друго хранилище за вашите данни и Redis като кеш, това, което правите, е да попълните и двете изгледите (Redis и DB), когато е публикуван нов елемент. Няма анулиране на кеша.
Въпреки това приложението винаги може да има логика, така че ако списъкът Redis е празен, например след стартиране, първоначалният изглед може да бъде създаден отново от DB.
Чрез използването на интелигентно кеширане е възможно да се извърши кеширане с Redis по по-ефективен начин в сравнение с memcached, но не всички проблеми са подходящи за този модел. Например кеширането на HTML фрагменти може да не се възползва от тази техника.
