Facebook trapped in MySQL 'fate worse than death' | Hacker News Reader

Facebook trapped in MySQL 'fate worse than death'

gigaom.com

46 pointscarbonica10 comments

I'm skeptical when the main source for this article is working on a database meant to replace MySQL, as stated at the end. I'm sure MySQL isn't perfect, but it's a bit hyperbolic to call it 'worse than death'.

What Facebook has demonstrated is that it doesn't matter what technology is initially chosen since pretty much anything can be scaled with a modicum of persistence and ingenuity. So pick what you're most comfortable with, don't worry about scaling until you need to (a great problem to have) and get going.

Not really, don't you think that there is cost factor involved here? Imagine you need to run lets say 5000 machines for you uber big app, instead of 12000, you save money, you save environment, and its usually easier to manage everything when you have less machines to care about. Costs are important. And i'm not saying that one cant make mistakes, but you don't grow facebook size in one day, but when you do grow, it's a good idea to refactor your architecture into something scalable AND FAST, before you reach the point of no return ;-) or you will end up writing your own flavour of php....

Except that by almost any measure Facebook runs one of the leanest engineering and tech ops organizations in existence.

And don't forget that the author's main thrust was that Facebook faces a "fate worse than death". Adapting a technical architecture to keep up with growth doesn't really seem worse than death, imo.

9000 memcached servers, I'm surprised its not more than that. I wonder what their aggregate in-memory cache size is. Terabytes? Petabytes?

The article raises an interesting question for aspiring tech entrepreneurs and web application developers. What is the <strike>best</strike> right database technology for my web application? It probably depends, but I'm interested to hear what technologies people are using, for what purpose, and the decision process. Any takers?

We just had this thread; it got 40 points and then [dead].

This guy doesn't really get it. I assume he's talking about "high transaction volume" when he's talking about scalability. Anyone who knows anything about scaling to high transaction volumes knows that it's not SQL that gets in the way, it's ACID. Transactions don't scale regardless of whether they're implemented in a SQL database or a NoSQL database. This guy's VoltDB project is still shackled by ACID properties, and I don't really see the advantage of it over using MySQL with the in-memory storage engine.

tl;dr -- a lot of NoSQL ("NewSQL!?") information is FUD.

There may be FUD here, but I don't know if you understood Stonebraker's argument.

The whole point of VoltDB is that it is (supposed to be) dramatically faster than in-memory MySQL. That's not too hard to imagine, considering that MySQL uses one machine and VoltDB uses a cluster.

In fact, the whole point of NewSQL in general is that it is possible to implement SQL and ACID on a cluster and be dramatically faster than MySQL. While NoSQL is high-performance non-ACID non-SQL on a cluster, NewSQL is high-performance ACID SQL on a cluster; they're not the same thing.

To nitpick, Stonebraker is actually arguing that VoltDB is faster and better than both legacy RDBMS's and NoSQL:

http://highscalability.com/blog/2010/6/28/voltdb-decapitates...

Reply on news.ycombinator.com