MySQL at Facebook
highscalability.com
MySQL at Facebook
1–10 of 42 posts
Re: MySQL at Facebook
#2I doubt this HN post could have a more boring title. The actual article is very interesting. Basically Facebook's DB developers talk about what it takes to perform 13 million queries per second, and a lot of the useful tips they've learned along the way to make scaling simpler.
There's a full video of the talk available at http://www.livestream.com/facebookevents/video?clipId=flv_cc...
Re: MySQL at Facebook
#3I doubt this HN post could have a more boring title. The actual article is very interesting. Basically Facebook's DB developers talk about what it takes to perform 13 million queries per second, and a lot of the useful tips they've learned along the way to make scaling simpler. There's a full video of the talk available at http://www.livestream.com/facebookevents/video?clipId=flv_cc...
[deleted]
Re: MySQL at Facebook
#4[deleted]
Re: MySQL at Facebook
#5"They figure out why the response time for the worst query is bad and then fix it."
This can reap huge benefits and doesn't need to be difficult. Just enable the slow query log in MySQL, use the EXPLAIN command to analyze the results, then add indexes where appropriate. I was able to fix poorly indexed tables in a vendor's application with dramatic results. In one case, a twenty-minute(!) query was reduced to less than a second.
Re: MySQL at Facebook
#6"It is OK if a query is slow as long as it is always slow"
I find this enlightening.
I think it is just one instance of difference in emphasis between Google and Facebook. Google, a technology oriented company, would minimize the average response time, while Facebook, a people oriented company would minimize the unpredictability (by minimizing the variance)
Re: MySQL at Facebook
#7I doubt this HN post could have a more boring title. The actual article is very interesting. Basically Facebook's DB developers talk about what it takes to perform 13 million queries per second, and a lot of the useful tips they've learned along the way to make scaling simpler. There's a full video of the talk available at http://www.livestream.com/facebookevents/video?clipId=flv_cc...
How is the title boring? What could be more telling? Having "Facebook" in the title makes it clear we're going to be talking about astronomical amounts of data. "[insert any db] at Facebook" would be an interesting title in my opinion.
The fact that it's MySQL makes it even more interesting, given the shift of scalability interest to MongoDB, etc.
Re: MySQL at Facebook
#8"It is OK if a query is slow as long as it is always slow" I find this enlightening. I think it is just one instance of difference in emphasis between Google and Facebook. Google, a technology oriented company, would minimize the average response time, while Facebook, a people oriented company would minimize the unpredictability (by minimizing the variance)
I think the more compelling reason for "queries must be fast or slow, never 'both, depending'" is that it prevents engineers from accidentally using code originally built for reporting purposes (which might well have no latency requirements, or very relaxed ones) and putting it in a widget which gets slapped on people's home pages. You'd notice on your local, test, or staging instance "Hmm, my home page is taking 10 seconds to load -- that's bad" prior to pushing it live and, whoopsie, there's now 50 million people hitting a very scarily expensive query all at once.
Re: MySQL at Facebook
#9Does PayPal use MySQL?
Re: MySQL at Facebook
#10"It is OK if a query is slow as long as it is always slow" I find this enlightening. I think it is just one instance of difference in emphasis between Google and Facebook. Google, a technology oriented company, would minimize the average response time, while Facebook, a people oriented company would minimize the unpredictability (by minimizing the variance)
I beg to differ with "Google doesn't care about variances, because it's a tech company and not a people company."
From what I hear, Google/Bing do track response latencies at 99+ percentile.