The PyCon live stream we did was a pretty good case study. We pretty much hacked together a pub/sub system on top on BLPOP, so it'd be even easier going forward. Hopefully we'll open source it :/ (we've been meaning to for a while now...)
I don't have any numbers, but during Guido's keynote (which was twitter powered) tweetfall was too far behind live, so they switched to using our feed. We frequently got comments that we were updating faster than twitter.com was :)
StudiVZ and Craigslist are using multiple Redis nodes as a fast meta-data store. The Boxcar push notifications app for iPhone is Redis-based. Engine Yard is using Redis in multiple ways. Github as messaging system. I'm also aware of many other istalls in a lot of companies, what I'm loving about how things are going with Redis is that's considered more and more like a facility you use every time you need it so it's a tool in many companies. It's a bit hard to track the usages often.
This is a good example of Redis forcing you to denormalise your data - each item that is tagged gets a set of tags, while each tag gets a set of item IDs.
Simon, not sure what you meant by "denormalise" here but what you've described sounds fully normal to me.
It's up to you to manually maintain both of those sets, which means the information about what is tagged with what ends up stored twice and there's a risk that it could get out of sync.
Writes are saved to an in-memory table first and are burst to disk asynchronously. But, when the burst happens, the writes to disk are sequential - this is key. No reads to the disk are done before writes (which occurs in MySQL).
Writes can be faster if you don't have to write through to a slower media; also it would be faster if you can append to the end rather than seek to a specific location. Seeking takes up the majority of the time spent doing disk IO (not talking about SSDs).
