I worked on Staircar so maybe I can answer a couple of questions.
Machine failures: failures we'll likely address in a future post but basically each redis instance can have a slave which can be failed over to.
Performance: Staircar isn't nearly as fast as redis, but the primary project goal was making the redis infrastructure opaque to any clients. The secondary goal was performance, which is still quite good.
Early Optimization: In a large infrastructure (thousands of machines, multiple data centers, etc) you have locality issues, slow clients, machine failures and other operational considerations. Again, redis performance is fine and we weren't concerned with that. We were interested in creating a high performance proxy to a pool of redis instances. Also, with Staircar we can make online changes to the redis pool without needing to notify clients of those changes.
Is the code open source or do you have plans to open source it. I am actually pretty interested in this and would love to be able to read the code for it.
-Steve
Neat technology, but at first I thought I was going to read an article about some sort of messaging/event system. It's not; Staircar is basically a way to deal with high write to read ratio data. It's not for subscribing to or publishing events.
This looks pretty cool. I'm curious how they deal with machine failure though - does Staircar coordinate some kind of redundancy, or when you lose a redis machine do you need to manually fix it and bring it back up with whatever the last checkpoint data was?
I'm curious as to the speed difference between redis current protocol and a resty-json loving http redis server, as the speed was more than enough for tumblr and going the http route has the benefit that any http client becomes a full blown redis client.
Possibly early optimization syndrome? Redis is awesome, but the main problem here seems to be the amount of data (in the hundreds of gigs) and not scaling writes... The stated requirements are 7500 notifications per second but a single instance of redis can do 50k/sec updates on my mac...
[+] [-] bmatheny|14 years ago|reply
Machine failures: failures we'll likely address in a future post but basically each redis instance can have a slave which can be failed over to.
Performance: Staircar isn't nearly as fast as redis, but the primary project goal was making the redis infrastructure opaque to any clients. The secondary goal was performance, which is still quite good.
Early Optimization: In a large infrastructure (thousands of machines, multiple data centers, etc) you have locality issues, slow clients, machine failures and other operational considerations. Again, redis performance is fine and we weren't concerned with that. We were interested in creating a high performance proxy to a pool of redis instances. Also, with Staircar we can make online changes to the redis pool without needing to notify clients of those changes.
[+] [-] SteveMorin|14 years ago|reply
[+] [-] a-priori|14 years ago|reply
[+] [-] rdoherty|14 years ago|reply
[+] [-] mkjones|14 years ago|reply
[+] [-] troyk|14 years ago|reply
[+] [-] aaronbrethorst|14 years ago|reply
edit: no arrested development fans, i see...
[+] [-] stephth|14 years ago|reply
Looking forward for steveholt, featherbottom, annyong and nevernude.
[+] [-] ozataman|14 years ago|reply
[+] [-] owyn|14 years ago|reply