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

Upgrading Uber's MySQL Fleet

uber.com

Post reply on HN
Print view View original

181–190 of 215 posts

Re: Upgrading Uber's MySQL Fleet

#181

Post by aorth »

evanelias wrote: post #142
denysonique wrote: post #69

Why didn't they move to MariaDB instead? A faster than MySQL 8 drop-in replacement.

While it is indeed often faster, it isn't drop-in. MySQL and MariaDB have diverged over the years, and each has some interesting features that the other lacks. I wrote a summary of the DDL / table design differences between MySQL and MariaDB, and that topic alone is fairly long: https://www.skeema.io/blog/2023/05/10/mysql-vs-mariadb-schem... Another area with major differences is replication, especially when moving b…

Wow, I hadn't realized that MySQL and MariaDB diverged so much! In the last year I've started seeing some prominent applications like Apache Superset and Apache AirFlow claiming they don't support—or even test on—MariaDB at all.

Re: Upgrading Uber's MySQL Fleet

#182

Post by JackSlateur »

bushbaba wrote: post #155
Jgrubb wrote: post #102

Earlier quoted context omitted.

See, the problem is that the people who care about cost performance and the people who care about UX performance are rarely the same people, and often neither side is empowered with the data or experience they need to bridge the gap.

Hardware is cheap relative to salaries. It might take 1 engineer 1 quarter to optimize. Compare that to a few thousand per server.

A couple of years ago, I optimize some shit and reduced the annual billing of 150k€/y, for a 3 days of work

I might say, "hardware" is expensive compared to (my) salary :)

Re: Upgrading Uber's MySQL Fleet

#183

Post by sroussey »

maeil wrote: post #132
jdbdndj wrote: post #113

Earlier quoted context omitted.

It reads like any of those tech blogs, using big words where not strictly necessary but also not wrong Don't know about your LLM feeling

This [1] is a good piece on it. Here's [2] anorher good one. We don't just carry out a MySQL upgrade, oh no. We embark on a significant journey . We don't have reasons, but compelling factors . And then, we use compelling again soon after when describing how "MySQL v8.0 offered a compelling proposition with its promise of substantial performance enhancements", just as any human meatbag would. [1] https://www.latimes.…

If the meatbag was a salesperson though… very believable! ;)

Re: Upgrading Uber's MySQL Fleet

#184

Post by bityard »

fs0c13ty00 wrote: post #129
aprilthird2021 wrote: post #109

Earlier quoted context omitted.

Let's delve into why you think that

It's simple. Human writing is short and to the point (either because they're lazy or want to save the reader's time), yet still manages to capture your attention. AI writing tends to be too elaborate and lacks a sense of "self". I feel like this article challenges my patience and attention too much, there is really no need to focus on the pros of upgrading here. We reader just want to know how they managed to upgrade…

My hypothesis is that long form content generated by LLMs tend to sound like blogspam and press releases because those are exactly the kinds of things they were trained on. Most content generated by humans for public consumption is ANYTHING but succinct.

Their style is much more direct if you just ask them a question or to summarize something. (Although whether the answer is accurate or not is another matter.)

Re: Upgrading Uber's MySQL Fleet

#185

Post by notyourwork »

JackSlateur wrote: post #182
bushbaba wrote: post #155

Earlier quoted context omitted.

Hardware is cheap relative to salaries. It might take 1 engineer 1 quarter to optimize. Compare that to a few thousand per server.

A couple of years ago, I optimize some shit and reduced the annual billing of 150k€/y, for a 3 days of work I might say, "hardware" is expensive compared to (my) salary :)

There isn’t always low hanging fruit. And when there is, it likely requires engineering knowledge to know it exists.

Re: Upgrading Uber's MySQL Fleet

#186

Post by greenchair »

mannyv wrote: post #162
paradite wrote: post #24

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

Once ChatGPT puts in "we did the needful" we're all doomed.

Dear sir, we are having a P1 incident, Prashant please revert.

Re: Upgrading Uber's MySQL Fleet

#187

Post by anonzzzies »

dhoe wrote: post #151
anonzzzies wrote: post #100

Earlier quoted context omitted.

We have 100000s tables per database (1000s of those) (think sensor/iot data with some magic sauce that 0 of our competitors offer) that are heavy on the changes. And yes, maybe it's the wrong tool (is it though if it works without hickups?) for the job (but migrating would be severe so we would only attempt that if we are 100% sure it will work and if the endresult would be cheaper; remember; we are talking decades h…

I'd generally call this amount of tables an antipattern - doing this basically implies that there's information stored in the table names that should be in rows instead, like IDs etc. -- But I'll admit that sensor related use cases have a tendency to stress the system in unusual ways, which may have forced this design.

Especially back when we started. Now we would've done it differently, but still think postgres wouldn't really work. Guess we will never now as even far smaller data sets do not work in the way we need them.

Re: Upgrading Uber's MySQL Fleet

#188

Post by anonzzzies »

sgarland wrote: post #147
wongarsu wrote: post #111

Earlier quoted context omitted.

You run VACUUM often enough that you never need a VACUUM FULL. A normal VACUUM doesn't require any exclusive locks or a lot of disk space, so usually you can just run it in the background. Normally autovacuum does that for you, but at scale you transition to running it manually at low traffic times; or if you update rows a lot you throw more CPUs at the database server and run it frequently. Vacuuming indices is a bi…

People not realizing you can tune autovacuum on a per-table basis is the big one. Autovacuum can get a lot done if you have enough workers and enough spare RAM to throw at them. For indices, as you mentioned, doing either a REINDEX CONCURRENTLY (requires >= PG12), or a INDEX CONCURRENTLY / DROP CONCURRENTLY (and a rename if you’d like) is the way to go. In general, there is a lot more manual maintenance needed to kee…

We make good money 'saving' people from Aurora; you can throw traffic at it and pay more. We often migrate companies who then end up with a fraction of the price.

Re: Upgrading Uber's MySQL Fleet

#190

Post by cheema33 »

remon wrote: post #103

It's sort of funny how can you immediately tell it's LLM sanitized/rewritten.

> it's LLM sanitized/rewritten

LLM is the new spellchecker. Soon we'll we will wonder why some people don't use it to sanity check blog posts or any other writing.

And let's be honest, some writings would greatly benefit from a sanity check.

Post reply on HN