

Facebook trapped in MySQL 'fate worse than death' - carbonica
http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/

======
jsharpe
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'.

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

~~~
ergo14
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....

~~~
pbreit
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.

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

------
hoona
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?

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

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

~~~
wmf
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.

~~~
SkyMarshal
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...](http://highscalability.com/blog/2010/6/28/voltdb-decapitates-
six-sql-urban-myths-and-delivers-internet.html)

