Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL at Facebook

highscalability.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: MySQL at Facebook

#31

Post by jonnathanson »

lenn0x wrote: post #30
jonnathanson wrote: post #25

Earlier quoted context omitted.

There is some social psychology and operations research around this -- not necessarily as it relates to human/machine interactions, but certainly as it relates to such quasi-analogous situations as call centers, lines, speed vs. variability of service at McDonald's, and so forth. The premise being practiced by Facebook takes a lot of cues from behavioral science data that is generalizable to many different domains. M…

Do you have a link to this research or study from McDonalds?

Alas, no, it was from an analytics consulting engagement a buddy of mine did a few years ago. But I am reasonably sure the outcome of the data is public knowledge and available somewhere. I wish I knew where.

Re: MySQL at Facebook

#32

Post by kmavm »

davnola wrote: post #22
kmavm wrote: post #12

Earlier quoted context omitted.

For what it's worth, Jeff Dean of Google has famously emphasized 95th and 99th percentile performance in preference to average or median performance over the years. The realization that edge cases more powerfully determine user perception of performance than average cases is a deep one, and is not original to Facebook or Google; Dean and colleagues were making some of the same points when they were at DEC's CRC pre-G…

Do you know of any research supporting that? It sounds plausible to me but a quick search turned up nothing.

Alas, my understanding of this point is entirely folkloric. Self-experimentation, and working on improving real interactive systems, agrees with it. Please update if you find anything more comprehensive.

Re: MySQL at Facebook

#34

Post by mobileed »

I can't understand why anyone who is in the know would sign up for this. I work at a fortune-5 corp where Oracle was once king and is being replaced with Microsoft SQL simply due to the outrageous price gouging. It's as if Oracle is trying to squeeze every last penny out of it's aging database as OSS solutions chip away at its profits. PostgreSQL is, in my opinion, poised to do this. MySQL just pales in comparison to Postgres and Oracle is kitchen sink and then some -- even at a fortune 5 we barely use all the "features" in Oracle.

I'm just astonished that a company like Oracle being around as long as they are could be so dumb. At the fortune-5, Oracle has a similar practice of gouging us on Peoplesoft licenses due to, in my opinion, lost DB sales.

Charging a customer a license by CPU core is just unethical.

It's a no wonder... Go riddance

Re: MySQL at Facebook

#35

Post by nl »

thevivekpandey wrote: post #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)

I'm sorry, but your interpretation here is completely wrong.

Facebook (and Google!) cares about performance variance because it has more of an impact on overall site performance than average performance does. Variable performance has huge impact on downstream systems, and you can quickly end up with cascading performance problems.

I think that quote is slightly misleading without more context. They prioritize optimizing variable-performing queries higher than others. They aren't going to be using slow queries on the Facebook home page.

Re: MySQL at Facebook

#36

Post by kamechan »

nphase wrote: post #29
catshirt wrote: post #7

Earlier quoted context omitted.

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.

Maybe boring isn't the right word. Vague is probably better. "MySQL at Facebook" is a facebook page, a launchpad user, a twitter user, a O'Reilly MySQLConf talk, etc.

not a conspiracy theorist by any stretch, but i found it a bit humorous this came out just when oracle offered a pricing plan for mysql and, especially, innoDB.

Re: MySQL at Facebook

#37

Post by mmavnn »

ora600 wrote: post #19
qjz wrote: post #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 th…

I believe that Facebook subscribe to this methodology because MySQL makes this easy and other methods of finding issues very difficult. When all you have is a hammer...

Alternatively, they might have come across Six Sigma ( http://en.wikipedia.org/wiki/Six_Sigma ) and decided it was relevant.

Re: MySQL at Facebook

#38

Post by mzl »

MichaelGG wrote: post #23
ora600 wrote: post #20

Earlier quoted context omitted.

Everyone is using MySQL. But I attended a talk by one of their DBAs where he said that they large OLTP server, the one that processes the payments is Oracle. Single-instance, because Oracle RAC can't give them the low latency they needed. They switch the the biggest machine IBM can give them every few month.

>They switch the the biggest machine IBM can give them every few month. Yea, almost all this "web scale" scalability can achieve those numbers because they can partition, relax transactional requirements, and scale out. For system-wide true transactions, scaling up is still the only option, it seems. Although, H-Store/VoltDB claims some impressive numbers if your OLTP app fits the requirements.

Just curious, do you have any good examples of very large scale systems that need system-wide transactions? I might miss something obvious (I'm not actually in the database area), but I couldn't come up with a good example.

Re: MySQL at Facebook

#39

Post by smackfu »

catshirt wrote: post #7
ecaron wrote: post #2

I 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.

"How Facebook optimizes MySQL" would be a better title.

Re: MySQL at Facebook

#40

Post by skorgu »

mzl wrote: post #38
MichaelGG wrote: post #23

Earlier quoted context omitted.

>They switch the the biggest machine IBM can give them every few month. Yea, almost all this "web scale" scalability can achieve those numbers because they can partition, relax transactional requirements, and scale out. For system-wide true transactions, scaling up is still the only option, it seems. Although, H-Store/VoltDB claims some impressive numbers if your OLTP app fits the requirements.

Just curious, do you have any good examples of very large scale systems that need system-wide transactions? I might miss something obvious (I'm not actually in the database area), but I couldn't come up with a good example.

It depends on your definition of 'very large scale'. Certainly any large financial/insurance company is going to be churning through great gobs of data that really does have to be universally consistent. This is basically the niche that keeps IBM's mainframe division in business.

I'd suspect that if those don't qualify as 'very large scale' to your definition (which would be entirely justifiable) that such systems don't exist because they're not currently possible. For example I don't think it's possible to implement Facebook with SERIALIZABLE no matter how much money you throw at the problem.

(I'd love to be proven wrong of course)

Post reply on HN