

Slides and notes from my three hour Redis tutorial - simonw
http://simonwillison.net/static/2010/redis-tutorial/

======
simonw
Anyone got any good Redis use cases or success stories I could add to a future
version of the presentation?

~~~
kingkilr
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...)

~~~
simonw
Awesome, I'll keep an eye out for that. Don't suppose you have any interesting
numbers on traffic / performance etc?

~~~
kingkilr
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 :)

------
davidmathers
_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.

~~~
simonw
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.

------
rubyrescue
can someone explain how writes are faster than reads?

~~~
tptacek
I don't know, but remember that redis writes aren't hitting the disk
synchronously.

~~~
thegoleffect
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).

~~~
timf
Same idea in Cassandra:
<http://wiki.apache.org/cassandra/FAQ#reads_slower_writes>

