In all seriousness, Facebook's requirements are for high availability, with data integrity only mattering to the point at which it affects the usability of Facebook.
In other words, Facebook can tolerate a high degree of shit in the system before it becomes a problem. That isn't bad in and of itself, but you need to investigate your own needs before using something because Facebook/Google use it.
MySQL is at its roots an SQL-like database specializing in content management. The sorts of data integrity problems that can occur in MySQL are entirely tolerable in a content management environment for the most part. It was designed to be a fast backend for web sites with an SQL interface. A lot of the issues it has are entirely due to that legacy, but those issues don't matter at all when you are using MySQL for content management.
Every single one of those examples are probably using MySQL for some sort of content management.
So it isn't just whether they can tolerate some crap in their systems. It is what sort of crap they can tolerate. If the MySQL gotchas don't result in intolerable crap, then it doesn't matter.
Now, personally I wouldn't run an accounting system on MySQL particularly if I was expecting many apps to access the same db. This is because the sorts of issues that MySQL has are real show-stoppers in these environments. But content management? Why not? Heck many of these data integrity problems may be features in these environments.
For example, suppose MySQL@Twitter truncates your tweets to the maximum length silently without issuing an error. Bug or feature? Suppose it truncates numbers in your accounting software? Those are two completely different cases and while they may in theory be comparable, in practice they are not.
It is powering the core function of the sites i.e. it is the primary databases in all cases.
I am sorry but are you that deluded as to think so many of the world's leading IT companies are going to choose a database that silently loses data ? Do you really think they are that stupid ? I mean come on.
> MyISAM was the default storage engine for the MySQL relational database management system versions prior to 5.5
This is what the anti-MySQL crowd is talking about - the dark days when MySQL lacked transactions, referential integrity, and concurrency. It was basically the SQLite of its day.
There's nothing wrong with all that if you just want a key-value store, which is what most web apps are.
And it generally doesn't "silently lose data" unless you are touching that data. It tends to just silently do stuff that doesn't quite make sense. Like if you post in a thread, and your "post count" goes up but your post itself fails, it's not a huge problem. Unlike in an accounting app, where you really don't want a transaction to partially work (e.g. money falling through the cracks).
When MySQL broke on a website, I think most people just assumed it was internet gremlins.
It's not just MyISAM though. The fact is that these things actually make sense when you think about MySQL as being a content-management backend for the web. The problem actually has to do with SQL modes, the fact that MySQL will silently substitute table backends for you, and much more. Again in some environments this is ok, and if you have total control and tight control over a small number (preferably only 1) of applications hitting your db it isn't the end of the world.
But PostgreSQL folks look at MySQL from a different perspective. It's a db-centric rather than app-centric perspective. In this perspective your db needs to guarantee that declarative constraints will be followed. In this perspective the db is the center of the environment, not the bottom tier of the app stack. In this perspective you could potentially have dozens of apps using a single db.
It isn't a matter of MySQL having grown up a bit (and it has). It is a matter of it not having outgrown the content management and/or single app per db environment in which it arose.
Are you sure? Do we have evidence that the accounting end of the advertisement network, etc. is handled on MySQL? Or is it the backend for the public side only?
Let me give you an example. I have a customer that uses MySQL for some processing on their web site and all data gets batched up nightly and entered into the PostgreSQL-based accounting system. The MySQL db is accessed only by the app which does the processing and the connectors to the PostgreSQL db. The PostgreSQL db has a lot more logic in it and is a lot more complex.
In their case, their environment is not subject to any of the MySQL gotchas. They can make sure the credit card processing software runs in an acceptable SQL mode, and if something goes wrong between the PostgreSQL export of reports and the MySQL public side (which has happened for reasons other than MySQL's fault), they can track down and fix the problem. That's what loosely coupled systems are about.
IT in this case is about risk management. How can you guarantee that specific important data will not be lost. You can do this with MySQL for some set of environments (either because the data truncation isn't a big deal, regarding your tweets, or because it can be retrieved from another source, or because there is only one app accessing the database so you don't have to worry about apps turning off strict mode), but you can do it with PostgreSQL for a much larger set of environments and that's what the complaint is.
How much do you think Craigslist really cares if your ad to sell a futon goes missing at 2am? They'll apologize and help you create a new ad. They're not going to migrate databases over it.
For every one of those sites, I suspect the database integrity plan is "meh, restore from a backup."
So what you're saying is that all of the engineers at DBAs are sitting around going "Oh we just lost another user's Facebook page. No worries. They can just create another one." Do you not think they would've switched databases already if the couldn't fulfil the primary purpose of their business i.e. managing data.
That's what replication is for. :) Really, mysql makes a fine key value store. "Mostly ACID" is good enough for lots of purposes, but what people complain about is its "serious business" sql failures.
Look, I used to have to support mysql. Every couple months we had to increment our minimum required version because we found yet another query that didn't work right.
In all seriousness, Facebook's requirements are for high availability, with data integrity only mattering to the point at which it affects the usability of Facebook.
In other words, Facebook can tolerate a high degree of shit in the system before it becomes a problem. That isn't bad in and of itself, but you need to investigate your own needs before using something because Facebook/Google use it.