Clarifications about Redis and Memcached
antirez.com
Clarifications about Redis and Memcached
1–10 of 43 posts
Re: Clarifications about Redis and Memcached
#2I'm curious about the "threaded redis" reference. Back a couple of years ago I built a Collaborative Filtering recommendation system that used Redis for graph storage and relied heavily on sorted sets to compute the recommendation right in Redis.
I really needed some kind of a parallelism and so I hacked together http://thredis.org/ (and then mostly for fun added SQL operations to it by linking it with SQLite).
Since then I've kind of abandoned this project and moved on to other things, but I still think that there is a valid case for some form parallelism in Redis. I had learned some tough lessons while hacking on Thredis such as importance of ordering locks, having retry strategies, and there are still bugs that can cause it to crash AFAIK, but the take away was that it's doable - I was a newbie at it, today I'd probably do a much better job. In my (not so scientific) testing Thredis was only slightly slower than Redis.
Re: Clarifications about Redis and Memcached
#3you know that "memcached is designed for caching" was meant as "memcached is ONLY designed for caching"... that is the draw. there is no "Disk I/O" flag to turn off, and then trust the code to check for that flag in all the places it should, and pay the costs for those checks. can redis say it was ONLY designed for caching? no. your dismissal was ignorant.
then you get into the threaded data, and things become "basically" this an that. memcached is better at caching. basically, period.
Re: Clarifications about Redis and Memcached
#4Some minor points
> Redis in its special case of memcached replacement, may be addressed executing multiple processes
This is always less optimal to a single process. Simpler is better.
> Redis is very very observable
This has a cost...trashing your phenomenal read and write performance. Running a concurrent redis, just for monitoring, is a hack that I have used to continue leveraging the observability.
Re: Clarifications about Redis and Memcached
#5This is a really good blog post. I find it very neutral even when the author happens to be the one who created Redis.
What I really like about both pieces of software is that they are dead simple to set up. If I were to make a decision today for new projects who are just starting to scale I'd probably take a good hard look at redis and see if you don't need any of the extra features. I could see a lot of projects eventually needing those features and leveraging redis. I really like the pub/sub feature in particular. Persistence is always nice if you don't have to pay too much for it.
Does anyone know if amazon has a redis/memcache service? I can never remember what they name things.
Re: Clarifications about Redis and Memcached
#6I'm curious about the "threaded redis" reference. Back a couple of years ago I built a Collaborative Filtering recommendation system that used Redis for graph storage and relied heavily on sorted sets to compute the recommendation right in Redis. I really needed some kind of a parallelism and so I hacked together http://thredis.org/ (and then mostly for fun added SQL operations to it by linking it with SQLite). Since…
I remember thredis very well! But it's different compared to what memcached does and Redis has plans for: memcached just threads the I/O part, not the access to the key space which is serialized via a mutex. However what you had in mind is also in our long term plans... and was addressed in another blog post here: http://antirez.com/news/93
Re: Clarifications about Redis and Memcached
#7This is a really good blog post. I find it very neutral even when the author happens to be the one who created Redis. What I really like about both pieces of software is that they are dead simple to set up. If I were to make a decision today for new projects who are just starting to scale I'd probably take a good hard look at redis and see if you don't need any of the extra features. I could see a lot of projects eve…
Re: Clarifications about Redis and Memcached
#8This is a really good blog post. I find it very neutral even when the author happens to be the one who created Redis. What I really like about both pieces of software is that they are dead simple to set up. If I were to make a decision today for new projects who are just starting to scale I'd probably take a good hard look at redis and see if you don't need any of the extra features. I could see a lot of projects eve…
They do - ElastiCache. And as it happens, you can choose either Redis or Memcached!
Re: Clarifications about Redis and Memcached
#9Some minor points > Redis in its special case of memcached replacement, may be addressed executing multiple processes This is always less optimal to a single process. Simpler is better. > Redis is very very observable This has a cost...trashing your phenomenal read and write performance. Running a concurrent redis, just for monitoring, is a hack that I have used to continue leveraging the observability.
I agree that simpler is often better, but running multiple cache processes may be a requirement for either memcached or redis if you want to get consistent latency from them. I have observed a significant improvement in performance (at large scale) when binding memcached to a single NUMA zone.
NUMA lets you address non-local memory, but memcached and redis don't utilize libnuma so they don't know whether the memory is local or not. The entire system's memory is available as one contiguous blob, but some of it is a lot slower than the other (depending on which CPU core you're running on). To get around this, on most servers you'll need to run two processes (and two different ports) and bind them to appropriate CPU core sets and memory.
Re: Clarifications about Redis and Memcached
#10For a post that attempts to compare Redis to memcached for caching, it's amazing how few actual numbers appear in the post.