←back to thread

234 points benocodes | 1 comments | | HN request time: 0s | source
Show context
remon ◴[] No.41838059[source]
Impressive numbers at a glance but that boils down to ~140qps which is between one and two orders of magnitude below what you'd expect a normal MySQL node typically would serve. Obviously average execution time is mostly a function of the complexity of the query but based on Uber's business I can't really see what sort of non-normative queries they'd run at volume (e.g. for their customer facing apps). Uber's infra runs on Amazon AWS afaik and even taking some level of volume discount into account they're burning many millions of USD on some combination of overcapacity or suboptimal querying/caching strategies.
replies(5): >>41838139 #>>41838199 #>>41838202 #>>41839045 #>>41839409 #
Jgrubb ◴[] No.41838139[source]
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.
replies(1): >>41839066 #
bushbaba ◴[] No.41839066[source]
Hardware is cheap relative to salaries. It might take 1 engineer 1 quarter to optimize. Compare that to a few thousand per server.
replies(3): >>41839204 #>>41840085 #>>41840375 #
1. sgarland ◴[] No.41839204{3}[source]
It might take an engineer with no prior RDBMS knowledge a quarter to be able to optimize a DB for their use case, but then it’s effectively free. You found the optimal parameters to use for writer nodes? Great, roll that out to the fleet.