Facebook Trapped in MySQL 'Fate Worse Than Death'
1–10 of 30 posts
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#2when web startups decide they need to build a product in a hurry, MySQL is natural choice. But then they hit that hockey-stick-like growth rate like Facebook did
An awesome problem I'm still waiting to have.
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#3I'm always confused by people suggesting that the options are to have either MySQL or NoSQL. (Or, as this article suggests, "NewSQL", which I'm desperately hoping will be clarified by its proponents.) Is Pg not an appropriate suggestion for people looking to improve their SQL-based backends?
Edit: The article includes this gem: "The widely accepted problem with MySQL is that it wasn’t built for webscale applications..." Every time I see "webscale", I get the feeling that the author doesn't actually have a great grasp of what's going on. However, this guy did mention ACID, which confuses me. Did we define "webscale" when I wasn't looking?
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#4I'm always confused by people suggesting that the options are to have either MySQL or NoSQL. (Or, as this article suggests, "NewSQL", which I'm desperately hoping will be clarified by its proponents.) Is Pg not an appropriate suggestion for people looking to improve their SQL-based backends? Edit: The article includes this gem: "The widely accepted problem with MySQL is that it wasn’t built for webscale applications.…
Stonebraker has a new DB (VoltDB), so his claims and criticisms should be read in that light.
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#5In Stonebraker’s opinion, “old SQL (as he calls it) is good for nothing” and needs to be “sent to the home for retired software.” After all, he explained, SQL was created decades ago before the web, mobile devices and sensors forever changed how and how often databases are accessed.
He lost me here.
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#6FWIW, as an end user completely unaware of FB internals, facebook.com is as fast as I need it to be.
It’s called NewSQL [..] Pushed by companies such as Xeround, Clustrix, NimbusDB, GenieDB and Stonebraker’s own VoltDB,
It would be easy to accuse Stonebraker of tooting his own horn, but NewSQL vendors have been garnering lots of attention, investment and customers over the past year.
Hmm...
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#7The false dichotomy between MySQL and NoSQL is really irritating. Just because MySQL isn't solving the problem, doesn't mean that you have to completely change the database structure.
There are more grown-up SQL servers out there that can handle way more than MySQL, and not one of these "NewSQL" things that the author talks about.
Sure, let's bet the whole site on a really new database. Worked really well for Digg!
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#8Linkbait. One person's opinion, and the article doesn't even attempt to validate it against other experts or people with real knowledge of what Facebook's architecture and current concerns are.
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#9With all due respect to Stonebraker, I consider FB's MySQL use a success story. They're successfully scaled it to truly crazy traffic loads. It might be a pain, and sharding schemes are always a pain in the ass, but they're scaled it to levels unheard of for any of the NewSQL solutions being proposed as silver bullets ..
Re: Facebook Trapped in MySQL 'Fate Worse Than Death'
#10I'm always confused by people suggesting that the options are to have either MySQL or NoSQL. (Or, as this article suggests, "NewSQL", which I'm desperately hoping will be clarified by its proponents.) Is Pg not an appropriate suggestion for people looking to improve their SQL-based backends? Edit: The article includes this gem: "The widely accepted problem with MySQL is that it wasn’t built for webscale applications.…
The question for most isn't really "MySQL or NoSQL", but "ACID or not." For most people, ACID means MySQL because PostgreSQL (despite my own affection for it) is a major, major pain in the ass to work with on a smaller scale (edit: and Oracle costs more than most programmers' houses, so that tends to rule it out in a lot of cases). PostgreSQL tooling is considerably worse than MySQL (phpMyAdmin is damn near ubiquitous and has no reasonable pgsql competitor). Documentation expects you to already be a guru. And there's often just no really compelling performance reason to pick it over MySQL.
And then, when you get to Facebook's scale--though as a coworker just pointed out, Facebook probably isn't particularly ACID-compliant--Postgres is going to have problems that are pretty much the same as those you see in MySQL.
PostgreSQL isn't really "better than" or "an improvement over" MySQL. Different tools, different tasks--though they do have considerable overlap.