Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Uber Engineering Switched from Postgres to MySQL

eng.uber.com

Post reply on HN
Print view View original

291–300 of 306 posts

Re: Why Uber Engineering Switched from Postgres to MySQL

#291

Post by philliphaydon »

pluma wrote: post #283
philliphaydon wrote: post #249

Earlier quoted context omitted.

There was a great talk from a FB engineer who talked about using MySQL as a key-value store, then another engineer posted a blog about how they use MySQL and queries and joins etc, I asked about the video and he got super defensive and said it was wrong and the guy had no idea what hes talking about. It really put me off ever wanting to even consider working at Facebook. Digging around I can't find either the blog or…

I've talked to several Facebook devs who confirmed to me that FB primarily uses MySQL as a key-value store (e.g. this is why GraphQL makes so much sense for them). They were quick to point out however that of course they don't know everything FB does. The problem with making absolute statements about what FB does is that it seems to be structured as a large number of mostly independent teams that are free to choose a…

Ahh yeah good point. FB's scale is very interesting, it's like we solved scalability then FB came along and was like, ah crap we need to resolve scalability. And different teams are solving their own problems different ways.

Re: Why Uber Engineering Switched from Postgres to MySQL

#292

Post by fadzlan »

swasheck wrote: post #73
coldtea wrote: post #56

Earlier quoted context omitted.

> so you're pulling one line from the article to tell me that i'm wrong? Better than telling them that they are wrong while not only not pulling even one line from their article, but misattributing it to be something very different from what it is. In what world does the response to the concerns and analysis in the article can ever be: "data corruption: everyone has bugs"...

the same world where mysql lets you corrupt your own data. did you just stop reading? in what world does a data corruption event prompt you to change platforms to another platform that has a history of data corruption?

They do address other stuff. They have huge writes and needs better writes performance. Maybe not what you and I need, but hey, I suppose they know Uber needs better?

MySQL handles it differently than Postgres, and gives them better performance for their purpose (based on their experience/test). They were explaining it in the parlance of the terms that MySQL and Postgres. If those are buzzwords, then MySQL and Postgres are both created using buzzwords?

Their explanation is not perfect (for me, why do their datamodel needs massive updates?). But I wouldn't write it off as buzzwords and dismissing Postgres because of data corruption. There are a lot of other things they were trying to explain there.

Re: Why Uber Engineering Switched from Postgres to MySQL

#293

Post by chucky_z »

tracker1 wrote: post #287
chucky_z wrote: post #140

Earlier quoted context omitted.

What replication issues are you referring too? I never once had a problem with pgsql's replication across 8.1->9.5. It would randomly die, but that was always either my fault or the applications fault, never pgsql itself. The lack of master-master seems to be the big thing everyone mentions, but PostgresXL is currently in a usable-in-production state.

But, what is the current replication setup that comes with postgres that is well documented with the PostgreSQL (current-version) documentation... the past, when I've looked there's mention of 2-3 solutions (none in-the-box) and others that require at least a 5-figure support contract. Compare to MongoDB, RethinkDB, MS-SQL and others where the tooling for replication comes in the box. Yes, to of the examples are "no-…

Did you read this?

https://www.postgresql.org/docs/current/static/high-availabi...

I'm not sure what more you can ask from documentation.

Does MySQL document Vitess, Galera, MaxScale, etc...?

Re: Why Uber Engineering Switched from Postgres to MySQL

#295

Post by leblancfg »

bonesmoses wrote: post #214
leblancfg wrote: post #166

Earlier quoted context omitted.

My big question here is why they decided to move over to MySQL instead of using the Citus (also open source) Postgres extension. They don't mention it, so we don't know whether it was considered, and if so, why it was not selected. Postgres' rapid feature growth in the past years is interesting in itself.

Citus currently has major problems joining non-distributed tables with distributed tables, and it doesn't fully support schemas yet. It's almost there, but not quite.

Thank you!

Re: Why Uber Engineering Switched from Postgres to MySQL

#296

Post by ComodoHacker »

ledjon wrote: post #51

I would argue that most of these Postgres "flaws" are actually advantages over MySQL when you look at them holistically rather than the very specific Uber use-case. Postgres's MVCC is superior (can rollback DDL, can add indexes online, can have open read transactions for a VERY long time without impacting other parts of the system) Postgres supports many types of indexes, not just b-tree. One thing it doesn't have is…

>can have open read transactions for a VERY long time without impacting other parts of the system

Unless you're on a replica.

Re: Why Uber Engineering Switched from Postgres to MySQL

#297

Post by [deleted] »

chucky_z wrote: post #293
tracker1 wrote: post #287

Earlier quoted context omitted.

But, what is the current replication setup that comes with postgres that is well documented with the PostgreSQL (current-version) documentation... the past, when I've looked there's mention of 2-3 solutions (none in-the-box) and others that require at least a 5-figure support contract. Compare to MongoDB, RethinkDB, MS-SQL and others where the tooling for replication comes in the box. Yes, to of the examples are "no-…

Did you read this? https://www.postgresql.org/docs/current/static/high-availabi... I'm not sure what more you can ask from documentation. Does MySQL document Vitess, Galera, MaxScale, etc...?

[deleted]

Re: Why Uber Engineering Switched from Postgres to MySQL

#298

Post by je42 »

quicksilver03 wrote: post #180
je42 wrote: post #161

Earlier quoted context omitted.

Oracle ??? Let's start: - No transactions for DDL changes. - Oldschool commandline client. auto commit disabled by default. no history. - Weird sql syntax + semantics. f.e. null == empty string.

I'm with you on all of your points except auto-commit: having it off by default is much better, it forces you to explicitly commit when you change data and thus think if you really want to persist the changes.

yes. except that all other clients have auto commit on. thus if you transition from that to auto-commit off. You face two issues: 1. you don't know. and you thing you commited something but actually you didn't 2. you forgot and you committed something. but transaction keeps an row lock open and you bring down the server... :)

Re: Why Uber Engineering Switched from Postgres to MySQL

#299

Post by ngrilly »

nickpsecurity wrote: post #147
smoodles wrote: post #114

Earlier quoted context omitted.

Operating Cassandra at the scale that Uber is going to require is going to be painful and as operationally draining as MySQL if not more. There are really not a large number of options here anymore with the departure of FoundationDB from the market. CockroachDB might be an option in a few years, though I'm still confused why they are moving towards a SQL-ish vs key-value interface...

"departure of FoundationDB from the market" Pissed me off so much. Only thing close to Google's F0 RDBMS on the market, at a reasonable rate, and the beginning of a good offer to enterprises. Then, "poof!" It's a good example of why I tell companies to not put anything critical into something from a startup. If they do, better have a synchronized, backup option tested and ready to go. "why they are moving towards a S…

> Only thing close to Google's F0 RDBMS

Did you mean F1 (instead of F0)?

Re: Why Uber Engineering Switched from Postgres to MySQL

#300

Post by nickpsecurity »

ngrilly wrote: post #299
nickpsecurity wrote: post #147

Earlier quoted context omitted.

"departure of FoundationDB from the market" Pissed me off so much. Only thing close to Google's F0 RDBMS on the market, at a reasonable rate, and the beginning of a good offer to enterprises. Then, "poof!" It's a good example of why I tell companies to not put anything critical into something from a startup. If they do, better have a synchronized, backup option tested and ready to go. "why they are moving towards a S…

> Only thing close to Google's F0 RDBMS Did you mean F1 (instead of F0)?

Yeah, yeah. I keep getting the 0 and 1 mixed up. Thank you.
Post reply on HN