There's a lot of buzz surrounding the whole NoSQL buzzword, and I've recently been able to give both Memcached and Redis a quick try and look over. And here are my initial findings follow some tests and poking around. Note that I'm by no means have very in depth experience of both these systems, I'm just recording my findings down so I can look back at it in the future to see if I still think of them the same way next time.
Memcached is the simpler one to explain, it's essentially an in memory store of key/value pairs. Which basically means it you're essentially storing values in the form of usersession.xyz="some session data" in it. This usually leads to questions about why one would need to use an external service to cache simple key/value pairs in memory when your platform might already have something similar (ie. the Cache collection in ASP.Net) but the nifty thing about Memcached is that you can configure it to be redundant and highly available spanning across multiple servers among other tricks.
Redis like Memcached is also about to store key/value pairs as well, but it is also able to store structured data, lists and weighted lists. Which you can then manipulate and perform some simple operations on them like sorting, joining, calculating. Conceptually I'm more inclined to just call Redis a simple In Memory Database, but I think that's complicating it a bit much! But not only is Redis an In Memory Database, you can configure it to persists it's memory contents to disk ensuring that data can be preserved between server restarts and applications crashes. But wouldn't that make it behave just like a traditional database then, not quite I'd say.
Both Memcached and Redis excel in the fact that retrieval and storage of data is LIGHTNING fast compared to a traditional database, and why wouldn't they be considering that all the data is held in memory instead of on disk. So what kind of problem would arise from using them? Why, memory usage of course! Since the 2 systems will just keep writing to memory, if you don't keep an eye on them they WILL take everything if you just keep stuffing them full of data.
I'll say that it's easier to handle Memcached's memory usage, since it's main role is to cache data. If it reaches the memory limit, it'll just drop older values to make way for any new values. After all the whole idea of a cache is that while it exists to speed up data access, it can easily be discarded and rebuilt from the original source.
But with Redis it's a different, as mentioned Redis is cooler than Memcache in the sense that you can perform data aggregation on it, in fact you might be tempted to just run your website ENTIRELY off Redis, but then there are a few caveats about it. The first being the fact that Redis doesn't support the concept of ACID very well, so you can't use it for anything where data atomicity is a must. The other more important caveat is that Redis is an In Memory database, the WHOLE database needs to be in memory at the same time so if you want to speed up the look up of that 6GB customer DB file with Redis? Sure you can do that, but you're gonna have to dedicate 6GB of memory to hosting that database and that's not something you might be able to do.
UPDATE 7th March 2014 : Just figured out that in Redis you can ALSO set it so that when it approaches a memory limit, it can auto discard elements and thus it can also work like a cached store as well instead of having to define everything to expire explicitly.
The way I look at it is that Redis is great for caching datasets which require constantly manipulation but you don't want to burden the database with the queries. And it'll work great as long as you can give it the memory to work with. Such as... an item listing database which you want to allow users to sort according to different criterias.
And that was my quick look at Memcached and Redis, interesting stuff and I can't wait to work with them some more... ok, not so much on Memcached probably, it's features are a bit too specialized. :P