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

321–330 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#321

Post by zaphirplane »

setr wrote: post #254
ipaddr wrote: post #205

Earlier quoted context omitted.

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)

What is an example where the order of execution is required, not contrived or bad practise. Looking for a good use case

Re: Migrating Facebook to MySQL 8.0

#322

Post by zaphirplane »

skrebbel wrote: post #285
kaba0 wrote: post #271

Earlier quoted context omitted.

Oracle, compared to their image is quite technically adept — they did a splendid job with OpenJDK and they have plenty of long-term R&D projects like GraalVM.

Yeah so, all of that seemed to happen after that Cantrill talk. How did Oracle suddenly turn from a pure license contract squeezing company into a tech leader again? I mean, they had to hire great engineering talent to do all this. And convince them to work for Oracle . What's the narrative I'm missing?

I heard they were poaching whole teams with a massive pay bump

Re: Migrating Facebook to MySQL 8.0

#323

Post by setr »

zaphirplane wrote: post #321
setr wrote: post #254

Earlier quoted context omitted.

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)

What is an example where the order of execution is required, not contrived or bad practise. Looking for a good use case

Easiest I can imagine is a user-facing id that gets incremented by trigger (e.g. select max(col)+1 — autoincrement/serial doesn’t guarantee contiguity, or even reasonable increments…).

And then any second trigger that relies on that value

Re: Migrating Facebook to MySQL 8.0

#324

Post by ris »

z3t4 wrote: post #151
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…

When I started working with databases about 20 years ago talking to peers it was common to have a layer in-front of the database so that you could easily replace the database. It felt stupid until I actually had to do a database migration... So do you still put a layer infront of the database so that you can for example easily change from mySQL to Postgress? Given there are so many open source database I think there…

You can indeed have that and many people do, but the problem with going that route is you can only use the lowest common denominator of features of any of the target databases, which wipes out a lot of the performance or convenience features you'd get from either.

(arguably SQL itself is/was supposed to be that common layer in the first place, but db vendors always want to be able to present users with new features that are not yet standardized)

Re: Migrating Facebook to MySQL 8.0

#325

Post by paulddraper »

zaphirplane wrote: post #321
setr wrote: post #254

Earlier quoted context omitted.

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)

What is an example where the order of execution is required, not contrived or bad practise. Looking for a good use case

Oh, I think it's probably bad practice to knowingly depend on that.

But I also think that it's unnecessarily problematic to make the order non-deterministic.

Re: Migrating Facebook to MySQL 8.0

#326

Post by paulddraper »

marcosdumay wrote: post #240
paulddraper wrote: post #237

Earlier quoted context omitted.

The problem is that it doesn't leave you a great way to adjust order. It's just kinda weird. (To be fair, table columns share this characteristic.)

> To be fair, table columns share this characteristic. The table columns order is meaningless, but the triggers order is very relevant.

Table column order is not meaningless.

``` INSERT INTO foo SELECT * FROM bar ```

The harder problem however, is order in composite types.

Re: Migrating Facebook to MySQL 8.0

#327

Post by JohnL4 »

dheera wrote: post #39
cmrdporcupine wrote: post #4

My old-man brain still can't compute this statement: "MySQL, an open source database developed by Oracle" . I know this is now factually true, but late-90s me keeps looking over my shoulder and freaking out.

I just configured a new router and had to set up my dynamic DNS updating service on it. Went to dyn.com and the goddamn website is gone, redirects to some corporate Oracle bullshit and PR, and I can't login to that Oracle crap with my dyn.com account and password. In case any confused people googling for this stumble upon this comment you need to go to: account.dyn.com which they don't tell you on the Oracle page. Yo…

Not relevant to the original topic, but yeah. I'm still an individual, private user of dyn, and when oracle bought them, what they charge me jumped significantly. Moving to another provider is just low enough on my priority list that it has happened yet, but I'm not happy about it.

Re: Migrating Facebook to MySQL 8.0

#328

Post by marcosdumay »

paulddraper wrote: post #326
marcosdumay wrote: post #240

Earlier quoted context omitted.

> To be fair, table columns share this characteristic. The table columns order is meaningless, but the triggers order is very relevant.

Table column order is not meaningless. ``` INSERT INTO foo SELECT * FROM bar ``` The harder problem however, is order in composite types.

Yeah, I do really recommend people not to do that sort of thing when they ask me.

Re: Migrating Facebook to MySQL 8.0

#329

Post by hodgesrm »

dijit wrote: post #200
hodgesrm wrote: post #127

Earlier quoted context omitted.

Well...I love MySQL but there was a time when it was anything but rock solid. It was pretty painful until InnoDB replaced MyISAM in 2010 as the default storage engine. After that it became rare to lose data.

Except in cases where the constraints may be violated and it just inserts the next nearest thing. Or the times where the transaction isolation just abruptly ends and commits your transaction midway; leaving no chance of a rollback. Or when you alter a column to a new type and the cast doesn’t work in a few cases and just leaves corrupted garbage on every row. Or when the replication misses a few transactions and your…

Don't get me wrong, there are still occasional problems. Most of those I've encountered have been applications misusing MySQL. We can debate whose fault that is.

But at least people stopped doing REPAIR TABLE after hard restarts of MySQL. It's been a long time since I last had to do that.

Re: Migrating Facebook to MySQL 8.0

#330

Post by dweekly »

MuffinFlavored wrote: post #312
dweekly wrote: post #273

Earlier quoted context omitted.

Yep. Here's how I'd napkin math it. Facebook has purchased 6GW of renewable energy to power its datacenters [1]. Its datacenters have a PUE of about 1.06 last they published (they unfortunately seem to have taken their dashboards down) so that's about 5.6GW of electricity actually powering real load. Some of that will power the networking fabric so we could conservatively estimate 5GW of compute load. The OCP Yosemit…

5 Gigawatts to Kilowatts = 5000000 5000000 kilowatts / 1kW per machine = 5,000,000 machines internationally?

Yes, and that's a conservative lower bound (their web application servers likely draw much less than a kilowatt each and constitute a healthy portion of the fleet).
Post reply on HN