You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Why Not Memcached ?

0.00 avg. rating (0% score) - 0 votes
Memcached or Redis ? It’s a question that nearly always arises in any discussion about squeezing more performance out of a modern, database-driven Web application . We too faced this question, while deciding the cache system for our application, but Redis proved to be the more powerful and flexible one.
Both are in memory, key value data stores and are remarkably fast cache management systems. But Redis does whatever memcached can do and more. Let us look at some of these features :-
1. First and foremost is the extra data types, memcached key value pairs can only be in a string format while there is no such constraint in redis. In Fact, this is one of the main reasons, which inspired us to cache the static php array in redis; we were able to store the whole array as a hash and fetch only the values which were needed on the page saving  a lot of CPU memory. Hashes are a very good candidate for caching large objects for efficient cache management. Let’s understand it better by an example:
Let us say we have a class User {UserId, UserName, UserAge, UserAddress} and we wish to     cache its objects (the UserId being the key) 
In memcached our cache will look like,
1001 -> “Object User {UserId:1001, UserName:ABC ,UserAge:34 ,UserAddress:123 Street}”
Now in case, a user changes his/her address we need to delete the cache entry corresponding to  that user due to the string data type or even if one wants to access the UserId he/she will have to retrieve the whole object. 
Redis offers a lot of flexibility in such scenarios,.
We could have stored all the objects of the User class in a single hash and changed every attribute of the object independently.
HSET User:1 UserId 1001 Name ABC Age 34 Address 123 Street
Now for updating the Address of User1, a simple HSET User1 Address 789 Street will do it for you .
Thus we see, we can actually play with objects at attribute level in Redis. 
2. Another powerful feature of Redis is persistence. Redis actually syncs data to the disk every 2 seconds or so. This feature permits the usage of redis as a real database rather than just a volatile cache. 
Redis uses memory for storage support but disk for persistence, therefore in case of planned shut downs or unplanned failures there are very short cache warm up periods in Redis while the whole cache needs to be repopulated in case of memcached. Redis also supports master slave replication of data across servers, thus provides a highly available cache setup.
3. Also the data stored in Redis is not opaque as in case of memcached , it can be be operated upon. A considerable 160 plus commands like INCR ,INCRBY, APPEND etc are devoted to data processing operations in Redis .
Refer to learn about more commands.
4. Another Important advantage of Redis over memcached is that the Keys can be accessed selectively allowing selective flush/update of data using MATCH / KEYS commands. We have used the KEYS function to delete the cache (job details and footer details) of the deleted jobs by matching the key to the job Id.
5. Redis provides 6 data eviction policies (noeviction, allkeys-lru, volatile-lru, allkeys-random, volatile-random and volatile-ttl) as opposed to only LRU policy supported by memcached. We used the volatile-lru eviction policy which removes the keys which have an expire set to make room for new data if max memory limit is reached.
Refer for cache eviction policies.
6. Memcached limits key names to 250 bytes, limits values to 1MB, and works only with plain strings, Redis allows key names and values to be as large as 512MB each, and they are binary safe
Posted in General