Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

251–260 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#251

Earlier quoted context omitted.

Their scale is enormous. I first heard the phrase "thundering herds" in a Facebook MySQL talk. (Thundering herds refers to what happens to your infra when something big happens in real life that lights up social networking/search/etc.)

Let's try to put a guess in numbers. > With roughly 2.85 billion monthly active users as of the first quarter of 2021 > 1.8 billion of Facebook users (66%) use the app on a daily basis Say 1 database could store the data + handle the reads/writes for 100,000 users (literally just guessing) 2.85 billion monthly active users / 100k users per server = 28,500 servers/"instances" for MySQL That's not even counting Kuberne…

Kubernetes, no. Twine (aka "Don't call it Tupperware"), yes

https://engineering.fb.com/2019/06/06/data-center-engineerin...

Also, that "30,000 servers" number is off by... a lot. No comment on by how many orders of magnitude. :-)

Re: Migrating Facebook to MySQL 8.0

#252

Earlier quoted context omitted.

In semantic versioning parlance those would all be considered "patch" releases, not a "minor" release. The minor version segment in a semantic version is the 2nd number, so most people would consider the next "minor release" for MySQL to be 8.1.0. If following the guidance set out at https://semver.org , a patch release wouldn't add any new functionality, it would just address bugs in a backwards compatible way. A mi…

MySQL does not follow semantic version and there have been features introduced in minor released including some incompatible changes as you can see for example https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24....

That's still a patch release not a minor release.

Re: Migrating Facebook to MySQL 8.0

#253
post #170

Earlier quoted context omitted.

That was the expectation but the Oracle camp surprised everyone by actually giving it some attention, and meanwhile MariaDB's promise of being a "100% compatible drop-in replacement" came with more and more caveats with each release (as is to be entirely expected with any fork). When you consider the network effect of all the stacks already heavily invested in MySQL, all Oracle really needed to do was put in a modicu…

> meanwhile MariaDB's promise of being a "100% compatible drop-in replacement" came with more and more caveats with each release Anecdata: I've been using mariadb as a drop in mysql replacement for over 5 years in production, and it's been working seamlessly. I'm no DB expert, and perhaps my use case isn't complex enough or written in a highly mysql dependent way - but I felt like someone should chime in since there'…

We migrated a high-traffic, complex site with a huge amount of data to MariaDB about 5 years ago as well, and it's been solid so far. We use Galera as well, which has performed and scaled really admirably.

Re: Migrating Facebook to MySQL 8.0

#254
post #205

Earlier quoted context omitted.

> as far as i know, i am sticking to standard SQL PostgreSQL documentation is very good about comparing each feature to the standard. For example, the SQL standard specifies that triggers fire in the historical order they are added to the table. PostgreSQL chose to fire them alphabetically. Technically nonconformant, but in practical terms, far better.

Why would alphabetically be better? Wouldn't you want first in first out?

Alphabetical makes it so two databases with the same triggers have the same behavior. FIFO breaks that, because now it depends on trigger construction order (eg when dump/restoring) and is totally invisible to the user.

Additionally, modifying a trigger by drop/creating it would change behavior, unless you also drop/create every trigger (in the original order)

Re: Migrating Facebook to MySQL 8.0

#256

Earlier quoted context omitted.

Anyone on the in-crowd who can share a bit about Oracle's motivations here? I recall a Bryan Cantrill talk about how Oracle is this completely amoral machine that just wants to make money, and how that drives their every decision [0]. Is this no longer the case? Or is it, and if so, how does improving MySQL and giving it away for free making Oracle money? Or was it always hyperbole and Oracle is improving MySQL becau…

Oracle paid a lot of money to buy Sun, and basically ended up with two products- selling support for Java and MySQL. Letting MySQL rot would have been pretty bad for their pocket book (especially as others have noted that postgres has been cutting into their market heavily). In Bryan's defense, the lawnmower rant is pretty true- they are a simple company. They focus heavily on making money and abandoning things they…

> Experimenting on or converting small projects into new markets?

Bringing MaximeVM out of research labs into the market as GraalVM.

First RDMS to support Perl and Java as stored procedures.

Join venture with Sun for Network Computer thin clients.

> Fleshing out OpenSolaris into a product that could rival linux?

Every OpenSolaris sales is one sale less from Unbreakable Linux, so in a day and age where UNIX === Linux, a company like Oracle has chosen what makes more sense monetarly.

I doubt that IBM is getting lots of new AIX customers.

And in the end, except for a timid offer from IBM, no one cared to rescue Sun.

Re: Migrating Facebook to MySQL 8.0

#257

Earlier quoted context omitted.

Anyone on the in-crowd who can share a bit about Oracle's motivations here? I recall a Bryan Cantrill talk about how Oracle is this completely amoral machine that just wants to make money, and how that drives their every decision [0]. Is this no longer the case? Or is it, and if so, how does improving MySQL and giving it away for free making Oracle money? Or was it always hyperbole and Oracle is improving MySQL becau…

Mr. Cantrill might be engaging in hyperbole. Big companies are big though- lots of people in charge of lots of things, and often they wander off in different directions. It doesn't make sense to model their behavior as if directed by a single hive mind.

Companies do have a culture though, the reason Amazon warehouse employees have to piss in a bottle can be traced back to Bezos and his laser like focus on controlling costs.

Re: Migrating Facebook to MySQL 8.0

#258
post #61

Perhaps it's due to me being in the PostgreSQL camp, but what happened to MariaDB? I was convinced that's where MySQL developers went and that's where development proceeded, while MySQL was just half dead, because Oracle did not care about it.

What happened to MariaDB? Not much, but unlike Netbeans (which is a complete disaster under Apache... a dying project maintained by a skeleton crew), it still has a commercial entity behind it, so it's trucking along relatively nicely. I mean, it's not like Oracle is investing tremendous amounts of time and money into MySQL either... there are still many, many things in the MySQL ecosystem that are second class citiz…

Well, when everyone and their dog is buying InteliJ licenses, most people that still care about doing FOSS work for Java IDE end up contributing to Eclipse instead.

Which is a pity, Netbeans is my favourite IDE and still has features hardly replicated in other Java IDEs, including the InteliJ Ultimate edition.

JetBrains would rather sell two licenses than allow for integrated development and debugging of native methods.

Re: Migrating Facebook to MySQL 8.0

#259
post #250

Earlier quoted context omitted.

No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.

> Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl

In practice, this is rarely a problem unless you're a cloud vendor with a DBaaS product; the most common concern there tends to be bugs that cause server crashes. But even that is fairly rare, and those platforms (AWS, GCP, Azure, Alibaba, etc) generally maintain custom patch sets anyway.

As far as I can recall, the vast majority of modern MySQL CVEs have been low severity and/or require the attacker to already be in your private network.

For sake of comparison -- does Postgres backport every security patch to every major.minor tree? And aren't HA Postgres upgrades generally more difficult than MySQL ones since logical replication is less widespread in the PG landscape?

Re: Migrating Facebook to MySQL 8.0

#260
post #256

Earlier quoted context omitted.

Oracle paid a lot of money to buy Sun, and basically ended up with two products- selling support for Java and MySQL. Letting MySQL rot would have been pretty bad for their pocket book (especially as others have noted that postgres has been cutting into their market heavily). In Bryan's defense, the lawnmower rant is pretty true- they are a simple company. They focus heavily on making money and abandoning things they…

> Experimenting on or converting small projects into new markets? Bringing MaximeVM out of research labs into the market as GraalVM. First RDMS to support Perl and Java as stored procedures. Join venture with Sun for Network Computer thin clients. > Fleshing out OpenSolaris into a product that could rival linux? Every OpenSolaris sales is one sale less from Unbreakable Linux, so in a day and age where UNIX === Linux,…

FANG would buy them if they had somehow managed to stumble forward to the mid-2010s.
Post reply on HN