Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

Post reply on HN
Print view View original

241–250 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#241

Post by zdragnar »

skrebbel wrote: post #135
lucideer wrote: post #74

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…

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 aren't in a good position to do so from.

Selling per-cpu-core licenses and support contracts, great! Experimenting on or converting small projects into new markets? Not great. Fleshing out OpenSolaris into a product that could rival linux? Dead end.

Maybe it could have worked out, but the lawnmower didn't care about a product that had too few users to make money from. OTOH, even Facebook uses MySQL... All they need to do is invest enough to maintain market share to get support contracts.

Re: Migrating Facebook to MySQL 8.0

#242

Post by dmitryminkovsky »

felixfbecker wrote: post #136
twic wrote: post #124

Earlier quoted context omitted.

> I absolutely adore Postgres's tweaks to the SQL language Do you mean additions to the SQL standard, or bits of the standard that MySQL doesn't implement, or something else? The reason i ask is that i also enjoy writing SQL for PostgreSQL, but as far as i know, i am sticking to standard SQL. Perhaps there are things i'm missing, or things i like which i haven't realised are nonstandard!

There is definitely stuff that is non-standard, like the casting with :: in addition to CAST AS. But it's true that PSQL sticks very closely to the standard or only adds on top of it, while MySQL is very uncomformant. Funnily enough, I actually first used Postgres over MySQL a long time ago when I moved from PHP to NodeJS, and was annoyed that MySQL uses backticks for identifiers while PSQL uses SQL standard double q…

You don't think the backticks lend a nice old school vibe?

Re: Migrating Facebook to MySQL 8.0

#243

Post by mdaniel »

gunapologist99 wrote: post #152
twic wrote: post #124

Earlier quoted context omitted.

> I absolutely adore Postgres's tweaks to the SQL language Do you mean additions to the SQL standard, or bits of the standard that MySQL doesn't implement, or something else? The reason i ask is that i also enjoy writing SQL for PostgreSQL, but as far as i know, i am sticking to standard SQL. Perhaps there are things i'm missing, or things i like which i haven't realised are nonstandard!

If you use any of the really amazing JSON or Array stuff, you're stepping outside of the standard.. but it's worth it!

The word "any" there is mildly misleading about the JSON things, since there is now SQL/JSON which PG supports: https://www.postgresql.org/docs/13/functions-json.html#FUNCT...

It would be horribly painful to stick to _just_ SQL/JSON for manipulations, and I have absolutely zero idea what the coverage is in other platforms, but portability isn't completely off the table like it used to be

Re: Migrating Facebook to MySQL 8.0

#244

Post by hodgesrm »

MuffinFlavored wrote: post #178
ksec wrote: post #6

MySQL 5.6 was released on 5 February 2013 . MySQL 8.0 was released on 19 April 2018 . >The 8.0 migration has taken a few years so far. We have converted many of our InnoDB replica sets to running entirely on 8.0. At the scale of Facebook I wonder if they are the largest MySQL user on the planet. And I take this opportunity to ask, does anyone know how does the MySQL roadmap works? What sort of features are coming or…

> At the scale of Facebook I wonder if they are the largest MySQL user on the planet I have to imagine they use other databases as well, right? We're much smaller than Facebook and we have some Mongo and some Postgres and a mix of Go/Rust/Scala/node.js. I wonder how many boxes they have dedicated to be being MySQL machines. I wonder how big their tables are and how many writes per second they see during the day.

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

Re: Migrating Facebook to MySQL 8.0

#245

Post by pbreit »

ksec wrote: post #6

MySQL 5.6 was released on 5 February 2013 . MySQL 8.0 was released on 19 April 2018 . >The 8.0 migration has taken a few years so far. We have converted many of our InnoDB replica sets to running entirely on 8.0. At the scale of Facebook I wonder if they are the largest MySQL user on the planet. And I take this opportunity to ask, does anyone know how does the MySQL roadmap works? What sort of features are coming or…

Any idea what Facebooks stores in MySQL? Core user database?

Re: Migrating Facebook to MySQL 8.0

#246

Post by tpetry »

zepearl wrote: post #174
PeterZaitsev wrote: post #82

Earlier quoted context omitted.

I think MySQL Engineering team does great job with Engineering, Do not want to deal with Oracle Sales ? I would invite you to talk to Percona for Commercial Support and Services Options Full disclosure - I'm CEO at Percona :)

I got sad when I read that TokuDB in Percona & MariaDB was being dropped :( Replaced TokuDB with MyRocks but it's totally different => now finally managed to have good ~constant performance insert&deletes (had to test & tune a lot), but "updates" remain a problem (they write a lot as I understand that any update always has to rewrite the entire row). Using InnoDb instead of MyRocks is NOK for me (problems with delete…

You can enforce how to execute parts of your PostgreSQL with pg_hintplan. And it has more options than mysql‘s approach ;)

Re: Migrating Facebook to MySQL 8.0

#247

Post by thayne »

takeda wrote: 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.

MariaDB isn't even the only alternative. There's also Percona. From what I can tell all three have pretty decent followings and are actively developed, with some cross pollination.

Re: Migrating Facebook to MySQL 8.0

#248

Post by MuffinFlavored »

hodgesrm wrote: post #244
MuffinFlavored wrote: post #178

Earlier quoted context omitted.

> At the scale of Facebook I wonder if they are the largest MySQL user on the planet I have to imagine they use other databases as well, right? We're much smaller than Facebook and we have some Mongo and some Postgres and a mix of Go/Rust/Scala/node.js. I wonder how many boxes they have dedicated to be being MySQL machines. I wonder how big their tables are and how many writes per second they see during the day.

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 Kubernetes pods (if they use that) running Docker containers (if they use that) for their API / content serving.

I wonder what their average transactions per second looks like.

For Twitter:

> Every second, on average, around 6,000 tweets are tweeted on Twitter, which corresponds to over 350,000 tweets sent per minute, 500 million tweets per day and around 200 billion tweets per year.

> As of the first quarter of 2019, Twitter averaged 330 million monthly active users

Twitter has 11.5% the MAU of Facebook (330m of 2.85b)? I don't know if 1 tweet can be extrapolated to 1 Facebook like/comment/share/post but if it did, 6k tweets per sec * 8.7x the user base = 52.2k writes per second?

Found this:

> Facebook now has about 30,000 servers supporting its operations, hosts 80 billion photos, and serves up more than 600,000 photos to its users every second.

Re: Migrating Facebook to MySQL 8.0

#249

Post by thayne »

> A few applications hit repeatable-read transaction deadlocks involving insert … on duplicate key queries on InnoDB. 5.6 had a bug which was corrected in 8.0, but the fix increased the likelihood of transaction deadlocks.

Interesting, I've run into a bug in MySQL 5.6 involving select for update where it deadlocked when it shouldn't. I wonder if the two were related.

Re: Migrating Facebook to MySQL 8.0

#250

Post by thayne »

evanelias wrote: post #199
dijit wrote: post #198

Earlier quoted context omitted.

That’s pretty scary, isn’t it?

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

Post reply on HN