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

281–290 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#281

Post by hans_castorp »

unknownOrigin wrote: post #103
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.

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…

> but unlike Netbeans (which is a complete disaster under Apache

I disagree with this

Re: Migrating Facebook to MySQL 8.0

#282

Post by cerved »

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…

likely support and keeping customers from migrating to postgres

and yes, Oracle is 110% focused on the bottom line. Preferably this quarter

Re: Migrating Facebook to MySQL 8.0

#283

Post by danpalmer »

VintageCool wrote: post #278
danpalmer wrote: post #85

Earlier quoted context omitted.

MySQL is alive for companies already using MySQL, but would well informed companies be choosing it today? I'm not so sure. I think you either want it to have more functionality and you choose Postgres, you want a particular performance profile and you pick MariaDB, or you want the enterprise support and you pick Oracle's database. Why you would pick Oracle-supported MySQL today I'm not sure.

Most people seem to be using the Percona Server branch of MySQL.

Good point, again this seems like another alternative that makes "stock" MySQL an option that there seems to be no good reason to choose.

Re: Migrating Facebook to MySQL 8.0

#284

Post by lclarkmichalek »

simonw wrote: post #51
jjeaff wrote: post #32

Earlier quoted context omitted.

I always see people asking about this. But why? Are you making schema changes that frequently?

It's my opinion that schema changes should be cheap, fast and unexciting. Unfortunately, in my experience once you are operating at scale they are expensive, slow and fraught with peril. The result is that engineering teams often chose to build poorly designed schemas and take on technical debt rather than make a schema change to a core table. This is a terrible anti-pattern! I'm massively in favour of anything that…

https://github.com/facebookincubator/OnlineSchemaChange

Re: Migrating Facebook to MySQL 8.0

#285

Post by skrebbel »

kaba0 wrote: post #271
skrebbel wrote: post #135

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, 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?

Re: Migrating Facebook to MySQL 8.0

#286

Post by Pamar »

ipaddr wrote: post #205
paulddraper wrote: post #190

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?

Not only what @setr answered but consider also that by having a consistent ruling you can actually design or alter the order of triggers just by naming them according to a specific scheme.

It just makes easier to understand what happens when triggers are invoked, without having to actually force specific cases by direct experimentation.

I did not even know that the standard prescribed a FIFO order, looks like a pretty bad idea to me, actually.

Re: Migrating Facebook to MySQL 8.0

#287

Post by neop1x »

suyash wrote: post #88

Go MySQL - solid open source database rocking for the last almost 3 decades!

I love MariaDB/MySQL. I had only like 2 crashes and 1 broken migration over the decade of it in production. It very powerful if you design tables and indices right. Postgres may be great too but I started with MySQL and I don't want to work with more DBs in parallel as there are quite a lot of differences for some queries. And I don't have capacity to write all queries in two forms. :D ORM is universal but doesn't always do queries optimally. And fulltext works completely differently between the two, for example.

Re: Migrating Facebook to MySQL 8.0

#288

Post by kaba0 »

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'm not familiar with the internal stucture of Oracle, just tired of the imo unfair bashing of them (at least compared to all other companies).

But I guess they must have had at least sane management that tried to keep the existing mindshare of acquired projects (as far as I know many people went from Sun to Oracle directly for example), as well as finding new talent. And also, the acquisitions made sense and were done at a comparatively good price so I guess they are good lawnmowers with long-term plans (but terrible PR)?

Re: Migrating Facebook to MySQL 8.0

#289

Post by hans_castorp »

jjeaff wrote: post #32
pmarreck wrote: post #5

can it do DDL commands in a transaction yet?

I always see people asking about this. But why? Are you making schema changes that frequently?

> But why? Are you making schema changes that frequently?

Because it makes the migrations much more robust and way easier to develop & test.

If something goes wrong in a migration script, everything is rolled back. You edit the part that caused the error and simply run the whole script again.

And despite of thorough testing, there is always the possibility that it fails when applied in production. You want that migration to be completely successful or not at all.

Think e.g. splitting a table into two (which also includes DML) or moving columns around while creating new foreign keys.

You might not need to put the whole migration into a single transaction, but at least combine some steps into one - but this is only possible if the DDL statements are transactional.

Post reply on HN