Live data from Hacker News

Upgrading Uber's MySQL Fleet

uber.com

51–60 of 215 posts

Re: Upgrading Uber's MySQL Fleet

#51

Earlier quoted context omitted.

everyone is praising postgres and shitting on mysql, until performance matters. then, when all these big tech companies turn to mysql, the postgres fanboys cry in unison.

There'd be less of that if there weren't a feeling that MySQL is the high-grade free hit that Oracle uses to get you hooked on their low-grade crap.

It's been 15 years since oracle acquired MySQL. I agree that you should always be prudent with Oracle but that's a long time...

Re: Upgrading Uber's MySQL Fleet

#53
post #13

So satisfying to do a huge upgrade like this and then see the actual proof in the pudding with all the reduced latencies and query times.

Yeah some numbers caught my attention like ~94% reduction in overall database lock time. And to think they never have to worry about VACUUM. Ahh the peace.

There are always tradeoffs.

Re: Upgrading Uber's MySQL Fleet

#54
post #39

Earlier quoted context omitted.

As somebody who has always used MySQL, but always been told that I should be using Postgres, I'd love to understand what the issues with VACUUM are, and what I should be aware of when potentially switching databases?

VACUUM and VACUUM FULL (and/or with ANALYZE) can lock tables for a very long time, especially when the table is large. Incantation may also require 2x the space for the table being operated on. In short: it's slow.

`VACUUM` (with or without `ANALYZE`) on its own neither locks tables nor requires additional disk space. This is what the autovacuumdvaemon is doing. `VACUUM FULL` does both, as it's doing a tuple-by-tuple rewrite of the entire table.

Re: Upgrading Uber's MySQL Fleet

#55

yall should prioritize your focus so you can do better at vetting drivers who don't almost kill me

Their focus is prioritized according to what returns maximum value to their shareholders.

beep boop i'm a capitalist robot

pretty sure safe travels is critical to maximum value to their shareholders (aka stfu or tell me how this blog post has anything to do with maximize shareholder value https://www.uber.com/en-JO/blog/upgrading-ubers-mysql-fleet/... ... shareholder value is a dumb ass thing to prioritize over human life)

Re: Upgrading Uber's MySQL Fleet

#56

Earlier quoted context omitted.

Yeah, until vacuum is gone, i'm not touching postgres. So many bad experiences with our use cases over the decades. I guess most people don't have our uses, but i'm thinking Uber does.

Maybe just vacuum much more aggressively? Also there have been a lot of changes to the vacuuming and auto vacuuming process these last few years, you can pretty much forget about it.

Not in our experience; for our cases it is still a resource hog. We discussed it even less than a year ago with core devs and with a large postgres consultancy place; they said postgres doesn't fit our use case which was already our conclusion, no matter how much we want it to be. Mysql is smooth as butter. I have nothing to win from picking mysql just that it works; I rather use postgres as features / not oracle but...

Edit; also, as can be seen here in responses, and elsewhere on the web when discussing this, the fans say it's no problem, but many less religious users feel it's a massive design flaw (perfectly logical at the time, not so logical now) that sometimes will stop users from using it, which is a shame

Re: Upgrading Uber's MySQL Fleet

#57
post #5

3 million queries/second across 16k nodes seems pretty heavy on redundancy?

I was going to say, that's absolutely nothing. They state 2.1K clusters and 16K nodes; if you divide those, assuming even distribution, you get 7.6 instances/cluster. Round down because they probably rounded up for the article, so 1 primary and 6 replicas per cluster. That's still only ~1400 QPS / cluster, which isn't much at all.

I'd be interested to hear if my assumptions were wrong, or if their schema and/or queries make this more intense than it seems.

Re: Upgrading Uber's MySQL Fleet

#59

I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. "This distinction played a crucial role in our upgrade planning and execution strategy." "Navigating Challenges in the MySQL Upgrade Journey" "Finally, minimizing manual intervention during the upgrade process was crucial."

> I can tell from a mile away that this is written by ChatGPT / Claude, at least partially. Whilst it may smell of ChatGPT/Claude, I think the answer is actually simpler. Look at the authors of the blog, search LinkedIn. They are all based in India, mostly Bangalore. It is therefore more likely to be Indian English. To be absolutely clear, for absolute avoidance of doubt: This is NOT intended a racist comment. Indian…

Can you elaborate on the last part? What are some stylistic patterns that are different when something is written by a US author v/s Indian?
Post reply on HN