Re:Slides and notes from my three hour Redis tutorial
by kingkilr on Sunday April 25, 2010 @06:51PM
(#1293679)
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...)
Re:Slides and notes from my three hour Redis tutorial
by kingkilr on Sunday April 25, 2010 @07:03PM
(#1293691)
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 :)
Re:Slides and notes from my three hour Redis tutorial
by antirez on Monday April 26, 2010 @07:16AM
(#1294585)
Hey, a few uses I'm aware of:
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.
Re:Slides and notes from my three hour Redis tutorial
by davidmathers on Monday April 26, 2010 @05:17AM
(#1294463)
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.
Re:Slides and notes from my three hour Redis tutorial
by simonw on Monday April 26, 2010 @05:38AM
(#1294485)
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.
Re:Slides and notes from my three hour Redis tutorial
by thegoleffect on Sunday April 25, 2010 @08:55PM
(#1293851)
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).
Re:Slides and notes from my three hour Redis tutorial
by echaozh on Monday April 26, 2010 @01:35AM
(#1294198)
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).
The ruby, python, and node.js clients support non-BLPOP pubsub. We are starting to see some layers added atop this (e.g. NodeRed).
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.
Simon, not sure what you meant by "denormalise" here but what you've described sounds fully normal to me.