Live data from Hacker News

Facebook trapped in MySQL ‘fate worse than death’ (2011)

gigaom.com

1–10 of 22 posts

Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)

#7
Best figures I could find in a quick search was http://news.cnet.com/8301-1023_3-57566550-93/facebook-by-the...

618 million Daily Active Users.

4000 shards, 9000 memcache instances.

Simple math, 618m/4000 is 154000 users per database (this is a horrible metric but illustrates my point) and 618m/9000 = 68666 and a bit users per memcache intances.

I hardly think this is a "fate worse than death", When you have a billion users with 600,000,000 DAU's whatever technology you use is going to have snags as you are pushing the envelope in just about every way.

This article reads like a Microsoft Whitepaper about why only a Microsoft technology running on a Microsoft platform will solve all your problems.

Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)

#9

It's funny because Facebook is actually where Cassandra was born. Now under the Apache umbrella, it's odd that they didn't even mention it in that article. It's got by far the most momentum in the distributed database league.

"Facebook, for example, created Cassandra for certain tasks and also uses the Hadoop-based HBase heavily, but it’s still a MySQL shop for much of its core needs."

Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)

#10

Anytime an engineer tells me that the only solution to something is to "bite the bullet and rewrite everything," I lose all respect for them.

Then it seems likely you're either correct and working with very poor engineers or making very poor and potentially incorrect assumptions based on your own lack of understanding of the code. I've been brought on to several projects over the years that simply could not move forward due to totally unsalvageable development failures; that's definitely not the case in every instance, but it absolutely does happen.
Post reply on HN