11–20 of 21 posts
There's another easier way built into memcached: When you issue a delete you can specify "the amount of time the client wishes the server to refuse 'add' and 'replace' commands" Maybe they couldn't afford to increase the read load so much but this seems easier than rewriting mysql's replication engine.
note to self: don't start companies that require multiple synchronized data centers. :-)
Actually, these are really interesting problems. Multi-homing isn't an issue for most startups though (not that this is true multi-homing since their second DC is read-only, meaning that they can't really survive the loss of the primary).
But yes, I suppose it wouldn't be considered true multi-homing.
note to self: don't start companies that require multiple synchronized data centers. :-)
While there's a ton of talk about scaling on here, it isn't needed by the vast majority of people and even Facebook's way isn't that complicated when you get down to it. Basically, the only change that needs to be done is that you have MySQL trigger the delete from memcached on replication. All your slave database gets an updated record for you, saves it in its tables and then hits memcached with a delete command for…
But then I realized I was imagining a single MySQL DB at each datacenter. In reality they must have pretty big clusters at each.
note to self: don't start companies that require multiple synchronized data centers. :-)
While there's a ton of talk about scaling on here, it isn't needed by the vast majority of people and even Facebook's way isn't that complicated when you get down to it. Basically, the only change that needs to be done is that you have MySQL trigger the delete from memcached on replication. All your slave database gets an updated record for you, saves it in its tables and then hits memcached with a delete command for…
That being said we are rapidly moving towards a world with more and more data being stored and queried. Scalability will therefore be something you increasingly need to know about in order to build a significant application -- regardless of your entrepreneurial ambitions.
There's another easier way built into memcached: When you issue a delete you can specify "the amount of time the client wishes the server to refuse 'add' and 'replace' commands" Maybe they couldn't afford to increase the read load so much but this seems easier than rewriting mysql's replication engine.
Just seems hacky to me. Opening a whole data center to shave off 70ms? Now I see why they need 500+ million.
Just seems hacky to me. Opening a whole data center to shave off 70ms? Now I see why they need 500+ million.
70ms can really affect the time people spend on a site.
All the js/css/other stuff facebook includes on their homepage (one server round trip each).
Before they spent the millions it takes to bring up another data center they should have read this:
http://developer.yahoo.com/yslow/help/#guidelines
Also, I disagree that 70ms makes that big of a difference. People are more used to slow sites then people realize - anything less then 200+ ms improvement in the aggregate and I wouldn't spend a dime (not to mention millions of dollars).
Earlier quoted context omitted.
Actually, these are really interesting problems. Multi-homing isn't an issue for most startups though (not that this is true multi-homing since their second DC is read-only, meaning that they can't really survive the loss of the primary).
Presumably if there was a major failure at the primarily data center they could quickly switch over the secondary one to be the master. But yes, I suppose it wouldn't be considered true multi-homing.
note to self: don't start companies that require multiple synchronized data centers. :-)
While there's a ton of talk about scaling on here, it isn't needed by the vast majority of people and even Facebook's way isn't that complicated when you get down to it. Basically, the only change that needs to be done is that you have MySQL trigger the delete from memcached on replication. All your slave database gets an updated record for you, saves it in its tables and then hits memcached with a delete command for…