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

221–230 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#221

Post by 1propionyl »

dkersten wrote: post #172
gunapologist99 wrote: post #152

Earlier quoted context omitted.

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

I absolutely love Postgres' JSON and array support. Its saved me from needing a document database in a few cases, which drastically simplified the overall deployment (one DB instead of two, or trying to represent relational stuff in a document DB). I really like JSON for stuff that is user defined, that I don't need to query into, but postgres' support means I still can should I ever need to. Which has happened once…

100%. I've dealt with many small-to-medium sized projects where the usual approach would have been some form of EAV mess.

Just using a BSON column for such attributes hits the Pareto 80/20 sweet spot, _and_ I can query against them much more easily than in an EAV schema (far fewer joins).

They're great for when the schema is mostly normalized, but there's just a little bit of denormalized stuff that doesn't warrant completely architecting the schema around it.

Re: Migrating Facebook to MySQL 8.0

#222

Post by daniel_iversen »

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…

We used MySQL at Dropbox too, and they probably still do.

Re: Migrating Facebook to MySQL 8.0

#223

Post by cat199 »

1024core wrote: post #219

> MySQL, an open source database developed by Oracle This makes it sound like Oracle created it, when it fact the reality is the opposite: Oracle fought it, and bought Sun just so they could get their hands on MySQL. How did regulators let that happen is beyond me.

sun had plenty of valuable assets in addition to mysql - don't think one can reasonably claim they bought sun just for mysql without inside knowledge

Re: Migrating Facebook to MySQL 8.0

#224

Post by cubano »

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…

I believe you are talking about the Microsoft ODBC API which was language and platform agnostic data acquisition layer. Early versions of it had pretty bad performance issues if I remember correctly, but eventually it became somewhat useful.

I believe that developers back in the 90's wanted a way to "drop in" various low and higher cost DBMS systems to their client-server based apps without the need of hiring full-time database sysops.

Re: Migrating Facebook to MySQL 8.0

#225

Post by jahewson »

1024core wrote: post #219

> MySQL, an open source database developed by Oracle This makes it sound like Oracle created it, when it fact the reality is the opposite: Oracle fought it, and bought Sun just so they could get their hands on MySQL. How did regulators let that happen is beyond me.

No. The most valuable part of sun at the time was arguably the SPARC chip architecture and Solaris which gave Oracle a vertical compute platform to compete with IBM Db2 on POWER running AIX. In our new cloud world this is now quaint and irrelevant but it was a big deal when on-prem was the only way.

There was also Java.

Re: Migrating Facebook to MySQL 8.0

#226

Post by rtsil »

101011 wrote: post #218
School-Cotton wrote: post #195

Earlier quoted context omitted.

SemVer is a relatively recent proposal that the vast majority of software does not follow. Calling the three parts of a three-part version “major”, “minor” and “patch” is a SemVer thing, not a universal standard.

Worth calling out here that SemVer has been around for a decade now, so "recent" is relative

For some of us, that is recent.

Re: Migrating Facebook to MySQL 8.0

#227

Post by JimDabell »

School-Cotton wrote: post #195
taywrobel wrote: post #129

Earlier quoted context omitted.

In semantic versioning parlance those would all be considered "patch" releases, not a "minor" release. The minor version segment in a semantic version is the 2nd number, so most people would consider the next "minor release" for MySQL to be 8.1.0. If following the guidance set out at https://semver.org , a patch release wouldn't add any new functionality, it would just address bugs in a backwards compatible way. A mi…

SemVer is a relatively recent proposal that the vast majority of software does not follow. Calling the three parts of a three-part version “major”, “minor” and “patch” is a SemVer thing, not a universal standard.

SemVer did not introduce major / minor / patch, that was standard usage in free and open source software for decades beforehand.

Example from 20 years ago:

> The most popular version numbering scheme stems from the .. scheme

— https://ask.slashdot.org/story/01/01/05/0054230/version-numb...

Example from 1997:

> Python versions are numbered A.B.C or A.B. A is the major version number -- it is only incremented for major changes in functionality or source structure. B is the minor version number, incremented for less earth-shattering changes to a release. C is the patchlevel -- it is incremented for each new patch release.

— https://web.archive.org/web/19970501012343/http://www.python...

Re: Migrating Facebook to MySQL 8.0

#228

Post by brianwawok »

pyrophane wrote: post #140
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…

I like Postgres but still turn to MySQL for production use most of the time for a few reasons: * Permission management on Postgres is much more painful. * The need for an external connection pooler makes postgres more annoying to set up. * Better quality docs on performance tuning MySQL.

Do you really need a connection pooler for most PG installs? I run a SaaS company with a lot going on, and haven’t had to touch a pooler. Average about 500 open connections. That’s a few, but on a DB server with 200GB of memory it’s nots really breaking anything.

Re: Migrating Facebook to MySQL 8.0

#229

Post by brianwawok »

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…

No it’s 100% still correct.

Re: Migrating Facebook to MySQL 8.0

#230

Post by haimez »

annexrichmond wrote: post #175
gresrun wrote: post #57

Earlier quoted context omitted.

YouTube used to use a MySQL-based system called Vitess[0]. It no longer uses it and has migrated to Spanner. [0]: https://vitess.io/

was that migration a technical decision or a political one?

This is one of those scenarios where the answer is likely to be “both”, but I doubt you’ll get anyone discussing YouTube internal architecture in enough detail to be satisfying. Just look up what Vitesse is and compare what that implies in terms of operational complexity to using something like spanner if you want a straw man technical rationale.
Post reply on HN