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

181–190 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#181

Post by danpalmer »

ericyan wrote: post #169
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.

Easy to operate, perhaps? With MySQL group replication, it is pretty easy to set up a HA cluster that allows you to sleep soundly. It can also handle thousands of connections without the need of a connection pooler.

Sure, but MariaDB is the more obvious choice surely?

Re: Migrating Facebook to MySQL 8.0

#182

Post by astrange »

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…

That would be an ORM or something similar, I think. It's not realistic unless you're always testing with two databases from the start, because their implementation details leak through.

It can be useful if your program is simple enough to work with both MySQL and SQLite, but often you should just stick with one DB and get to use all its features.

Re: Migrating Facebook to MySQL 8.0

#183

Post by danpalmer »

threeseed wrote: post #159
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.

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

So MariaDB then.

Re: Migrating Facebook to MySQL 8.0

#184

Post by danpalmer »

abledon wrote: post #100
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.

didn't the new basecamp "Hey" email product choose to use MySQL?

I think so, but they have been operating MySQL at scale for many products for about 20 years, so I can understand why they might not choose MariaDB (or Postgres, Oracle, etc).

Re: Migrating Facebook to MySQL 8.0

#185

Post by HarrisonFisk »

schuyler2d wrote: post #113

I'd be interested more in what features were in their (3): > Non-MyRocks Server: Features in the mysqld server that were not related to our MyRocks storage engine were ported. i.e. things that they haven't shared with the MySQL community but aren't related to the storage layer. Why would/should they keep those private? Considering that RocksDB is open-source, clearly it's unlikely it's because they're 'trade secrets'…

The code is open source:

https://github.com/facebook/mysql-5.6

Re: Migrating Facebook to MySQL 8.0

#186

Post by redis_mlc »

danpalmer wrote: post #85
BossingAround wrote: post #40

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.

> I think you either want it to have more functionality and you choose Postgres

False. MySQL and Postgres are comparable feature-wise.

@danpalmer: you're making an ass of yourself. It's clear from your comments that you're around 10 years out of date.

Re: Migrating Facebook to MySQL 8.0

#187

Post by HarrisonFisk »

gigatexal wrote: post #146

Where can I read more about the custom things FB added to MySQL 5.6? Their work on replication and the DDL work seems fascinating. Are there scholarly papers, white-papers, blogs? Are they storing the friend graph in MySQL?

Direct source is available at:

https://github.com/facebook/mysql-5.6

The social graph is indeed stored in MySQL via TAO. A recent white paper about MyRocks is:

https://research.fb.com/publications/myrocks-lsm-tree-databa...

Re: Migrating Facebook to MySQL 8.0

#188

Post by evanelias »

danpalmer wrote: post #181
ericyan wrote: post #169

Earlier quoted context omitted.

Easy to operate, perhaps? With MySQL group replication, it is pretty easy to set up a HA cluster that allows you to sleep soundly. It can also handle thousands of connections without the need of a connection pooler.

Sure, but MariaDB is the more obvious choice surely?

No, why do you think so?

Among the largest users, MySQL (or Percona Server) is chosen far more frequently than MariaDB.

GP mentioned Group Replication, which isn't even available in MariaDB.

Re: Migrating Facebook to MySQL 8.0

#189

Post by beachy »

myohmy wrote: post #164
beachy wrote: post #101

Earlier quoted context omitted.

I'm no fan of oracle's audit approach but it sounds like you were expecting special leniency to not pay for their stuff - for decades - because you are a govt agency/ live in a low income place. Not how business works. If you're playing by the rules, no one can force you into any long term contracts you don't need.

I'm also a government Oracle dev. I have no way of knowing what I'm licensed for and they don't disable the features we're not licensed for. I literally have to talk to my director to talk to our account rep to figure out that I'm not allowed to use table partitioning.

Agreed that Oracle licensing is byzantine, probably deliberately. But devil's advocate says that any organization should be aware of what they are actually licensed for, even if that means contracting a third party to ensure compliance.

Re: Migrating Facebook to MySQL 8.0

#190

Post by paulddraper »

twic wrote: post #124
munk-a wrote: 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!

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

Post reply on HN