Stonebraker is known for posting ridiculous things like this in the SQL/NoSQL community. Look at the marketing hype for VoltDB for an idea. He also loves to rag on Riak, which is a pretty solid KV store. This is ridiculous
Facebook trapped in MySQL ‘fate worse than death’ (2011)
11–20 of 22 posts
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#12Article is two years old, FB apocalypse hasn't happened.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#13It'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.
Except that they have dumped Cassandra and continue to use and grow MySQL and HBase.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#14Anytime an engineer tells me that the only solution to something is to "bite the bullet and rewrite everything," I lose all respect for them.
> "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"
Pretty closed minded approach. Just because it is usually not a good idea to do a rewrite, does not mean it is always true.
Here is an example which indicates you are probably wrong with that type of thinking:
What happens if a shop decides to store all their data in flat text files initially because it was easier and they were not expecting it to scale much. Later on and after huge expansion they realize that flat text files really is not the best solution, in fact it is pretty much the worst solution and decide that a rewrite with better technology is needed.
At this point you say you lose all respect for them? Does that attitude make sense?
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#15Anytime an engineer tells me that the only solution to something is to "bite the bullet and rewrite everything," I lose all respect for them.
"Everything" in the context of the quote only refers (as far as I can tell) to code that accesses the database and it does not imply that the entirety of facebook needs to be transitioned simultaneously. It's a far cry from the naive "we'll rewrite the app and everything will be better" mentality that you seem to be referring to.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#16The sheer fact that FB was able to scale MySQL for their use till now proves that there is nothing wrong with MySQL. There are few apps of FB scale ever created. This would mean for most apps, MySQL is more than enough. This is another snake oil vendor peddling his unproven oil.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#17Anytime an engineer tells me that the only solution to something is to "bite the bullet and rewrite everything," I lose all respect for them.
> "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" Pretty closed minded approach. Just because it is usually not a good idea to do a rewrite, does not mean it is always true. Here is an example which indicates you are probably wrong with that type of thinking: What happens if a shop decides to store all their data in flat te…
There's a huge difference between "our web site slow, so let's throw it out and rewrite the whole thing" and "our web site is slow. after profiling it seems our main bottleneck is the procedure that writes to these text file. I did a quick proof of concept where I replaced the text files with postgresql and I got a 2500% speed up. I'd like to try to implement this on our production site and see if it solves our performance problems".
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#18Anytime 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.
You're right, but don't forget to be nice too.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#19Stonebraker is known for posting ridiculous things like this in the SQL/NoSQL community. Look at the marketing hype for VoltDB for an idea. He also loves to rag on Riak, which is a pretty solid KV store. This is ridiculous
According to this paper: http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf VoltDB does not scale anywhere near even MySQL, let alone Cassandra.
Also, full ACID is overrated. Banks do well without it for years.
Re: Facebook trapped in MySQL ‘fate worse than death’ (2011)
#20Clarke's 1st law comes to mind :
When a distinguished but elderly scientist states that something is possible,
he is almost certainly right.
When he states that something is impossible, he is very probably wrong.
2.The only way of discovering the limits of the possible
is to venture a little way past them into the impossible.
3.Any sufficiently advanced technology is indistinguishable from magic.