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.
Upgrading Uber's MySQL Fleet
51–60 of 215 posts
Re: Upgrading Uber's MySQL Fleet
#52Re: Upgrading Uber's MySQL Fleet
#53So 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.
Re: Upgrading Uber's MySQL Fleet
#54Earlier 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.
Re: Upgrading Uber's MySQL Fleet
#55yall 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.
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
#56Earlier 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.
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
#573 million queries/second across 16k nodes seems pretty heavy on redundancy?
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
#58Re: Upgrading Uber's MySQL Fleet
#59I 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…