←back to thread

Upgrading Uber's MySQL Fleet

(www.uber.com)
234 points benocodes | 1 comments | 14 Oct 24 12:08 UTC | HN request time: 0s | source
Show context
whalesalad ◴[14 Oct 24 12:39 UTC] No.41836959[source]▶
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.
replies(1): >>41837062 #
hu3 ◴[14 Oct 24 12:52 UTC] No.41837062[source]▶
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.

replies(4): >>41837227 #>>41837317 #>>41837626 #>>41838255 #
InsideOutSanta ◴[14 Oct 24 13:22 UTC] No.41837317[source]▶
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?
replies(5): >>41837435 #>>41838160 #>>41838537 #>>41839012 #>>41845775 #
djbusby ◴[14 Oct 24 13:40 UTC] No.41837435[source]▶
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.
replies(4): >>41837649 #>>41837883 #>>41838660 #>>41838834 #
1. cooljacob204 ◴[14 Oct 24 15:50 UTC] No.41838660[source]▶
This is sorta mitigated by partitioning or sharding though right?

Too bad it's sorta annoying to do on plain old pg.