Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

151–160 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#151
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.

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 is less need to do so... Or do you go all in vendor lock in? Or some middle ground?

Re: Migrating Facebook to MySQL 8.0

#152
post #124
post #96

Earlier quoted context omitted.

I carried out a (quite ill-advised in retrospect) migration from MySQL to Postgres on a mature codebase with absolutely no automated test coverage and it went pretty smoothly. We had some bumpy performance directly after the production migration but we were able to reach parity after about two months of observing and adding targeted indices. I absolutely adore Postgres's tweaks to the SQL language, that dialect is am…

> 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!

Re: Migrating Facebook to MySQL 8.0

#153
So first sentence is:

"MySQL, an open source database developed by Oracle, powers some of Facebook’s most important workloads. "

Oracle didn't develop MySQL, they bought it... Am I nit-picky here, opinions?

Otherwise, congrats on shipping!

Re: Migrating Facebook to MySQL 8.0

#154
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.

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…

sounds like their java strategy until recently

Re: Migrating Facebook to MySQL 8.0

#155
post #137
post #44

Earlier quoted context omitted.

> Oracle has a very complete and much cheaper cloud solution relative to AWS Tell us more. Ignore the haters please. I'd love to have your insights.

It's all on their site - https://www.oracle.com/cloud/ Their price list is at https://www.oracle.com/cloud/price-list.html and the egress is under the "networking" section. Basically they give you 10TB outbound data transfer for free and charge as little as $0.0085 per GB after that. That's a savings of 90% (or 100% if you use less than 10TB transfer, which most apps do) Additionally their cloud servers (and most oth…

Yeah, AWS (and Azure, and GCP) really has notoriously expensive bandwidth, and it's the one thing they will never budge on in negotiations, since they know it's where they have nearly 100% profit margin; you can avoid using most services, or use compute etc more efficiently, but it's hard to consume less bandwidth!

It sounds like Oracle is actually pricing bandwidth at a reasonable price. This is quite a shock, coming from a historical perspective!

Re: Migrating Facebook to MySQL 8.0

#156

So first sentence is: "MySQL, an open source database developed by Oracle, powers some of Facebook’s most important workloads. " Oracle didn't develop MySQL, they bought it... Am I nit-picky here, opinions? Otherwise, congrats on shipping!

I would have had problems too if this was early 2010s, but I mean Oracle has been developing MySQL for more than a decade now, so I think it is fair to say "developed by Oracle".

Re: Migrating Facebook to MySQL 8.0

#157
post #78

Earlier quoted context omitted.

I can't read pass "developed by Oracle". It is factually not true. Unless there's so much code change after the acquisition that there's no single trace of the original open source version of MySQL left in there.

MySQL always was primarily developed by an commercial entity. And always gave an license out under GPL (i believe very first used some other license as GPL wasn't known back then ...) Oracle took over the development team (lots of pre-acquisition staff included) and legal rights to all of that. (Disclaimer: I started at independent MySQL AB more than ten years ago and now wear an Oracle badge, after wearing Sun for a…

Maybe it's legal talk that I don't understand, but the fact that Oracle owns the majority of the dev team today, doesn't mean Oracle developed MySQL. Because at the time MySQL was "developed", Oracle didn't own MySQL, nor did Oracle "own" the developers.

Re: Migrating Facebook to MySQL 8.0

#158

Earlier quoted context omitted.

MySQL always was primarily developed by an commercial entity. And always gave an license out under GPL (i believe very first used some other license as GPL wasn't known back then ...) Oracle took over the development team (lots of pre-acquisition staff included) and legal rights to all of that. (Disclaimer: I started at independent MySQL AB more than ten years ago and now wear an Oracle badge, after wearing Sun for a…

Maybe it's legal talk that I don't understand, but the fact that Oracle owns the majority of the dev team today , doesn't mean Oracle developed MySQL. Because at the time MySQL was "developed", Oracle didn't own MySQL, nor did Oracle "own" the developers.

Oracle still develops and to a notable number the same people. Also Oracle steered 8.0 which was a big change to internals. Anyways won't argue about single words.

Re: Migrating Facebook to MySQL 8.0

#159

Earlier quoted context omitted.

And yet MySQL is very much alive..? Java has fully opensource implementations too, and has had innovations like GraalVM and Jakarta EE. I think I'm too young to hate Oracle with a burning passion. I would be very scared of their sales/corporate team, but I mean, even having large contracts with Google or Amazon is difficult to say the least.

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.

> have more functionality and you choose Postgres

PostgreSQL still after all these years has a terrible story when it comes to HA and horizontal scalability. Nothing is built in or supported. And one of the only companies to provide something half decent i.e. Citus is now owned by Microsoft and so that project is now at risk.

At least MySQL has something built-in.

Re: Migrating Facebook to MySQL 8.0

#160
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…

It is practically essential for any RDBMS to provide non-standard statements and features. For example, even CREATE INDEX isn't in the SQL standard, since the SQL standard deliberately avoids talking about what it considers to be implementation details. This is probably a good goal in many ways. But what counts as an implementation detail is open to interpretation.

You could say the same thing about the isolation levels. They are supposed to be platonic ideals, free from any implementation baggage. But the reality is that you can tell that the people that originally defined how they work were mostly (perhaps entirely) thinking about old school two-phase locking.

I'm not a critic of the standard -- it's imperfections (which are arguably contradictions) reflect real world differences that are hard or impossible to resolve. Just pointing out that this is how it is.

Post reply on HN