MySQL at Uber(uber.com) |
MySQL at Uber(uber.com) |
* Why Uber Engineering Switched from Postgres to MySQL (2016) https://news.ycombinator.com/item?id=26283348
* Upgrading Uber's MySQL Fleet https://news.ycombinator.com/item?id=41836748
I think its interesting to attach any company prominently to a database technology since theoretically there would be varied use cases across an org like uber which would likely want different technologies depending on those use cases. Of course they might just have 50 other articles like this for all the other tech they use.
> The [Odin] platform supports 23 technologies, ranging from traditional online databases such as MySQL® and Cassandra® to advanced data platform technologies, including HDFS™, Presto™, and Kafka®.
Back when I was exploring migrating from TokuDB to MyRocks the only problem with it was that it didn't have a file per partition, meaning if you were doing retention you couldn't just drop old daily partitions cheaply.
One part of it is the constant talk of high level abstract infrastructural pieces, and the other is bad product or concept naming.
Odin, “the controller,” the constant obsession with certain engineering orgs to use words like “plane,” and likewise, “fabric” was used at a previous org I worked for.
I’m sure Uber is doing Real™ Work, but this kind of crap sets off all my wank and bullshit alarms.
It’s just clients talking to servers talking to servers talking to proxies talking to servers talking to databases talking to replicas. Can you please stop with the false high engineering bullshit?
It reads like a standard corporate blog post. You can find plenty of those on AWS blogs that were written before LLMs were publicly available.
It's not written like a "fable" as most technical blog articles that do well on HN tend to be. There is no great philosophical life-insight that the authors stumbled upon while doing this mundane technical thing.
The cover image is however:
> Cover Photo Attribution: The cover photo was generated using OpenAI ChatGPT Enterprise.
- Single Write Leader per partition
- Backup Write Leader that is setup with synchronous replication (so WL -> WLB and waits for commit)
- Read Followers all connected asynchronously using either binlog replication (not recommended anymore) or GTID-based row replication (recommended)
In the above scenario, the odds of loss are pretty small since the Write Leader has a direct backup, and any of the Read Followers can be promoted to a Write Leader/Backup. DDIA calls the above semi-synchronous replication, although MySQL now supports a similar-but-slightly different version out of the box: https://dev.mysql.com/doc/refman/8.4/en/replication-semisync...
Edit: yeah those images have their src attribute in the form of “lh7-rt.googleusercontent.com/docsz/[VERY LONG SLUGS]” and a quick look at the dev console shows that Google returns “429 Too Many Requests” for all of them.
I guess they just copy-pasted the URLs from some Google Doc and tried to hotlink them here? Interestingly if you access these directly (instead of embedded into Uber's blog) then they display fine and Google doesn't complain with a 429.
The new version is called Docstore though - https://www.uber.com/en-PE/blog/how-uber-serves-over-40-mill...
Even as a consumer, I've stopped using Uber due to, of all things "biz 101", incompetent billing.
You simply cannot take 70% from the revenue coming from an employee-like agent, yet report that to the government as being that person's income. Not only would that be blatant fraud, but depending on the exact percentages and absolute amount, the employee might have to give all their pay to the government to covert the tax, and even owe some more after that.
In what country are they doing this?
Among AWS users, "binlog replication" is often contrasted against Aurora's system, which uses physical replication instead of logical.
When using binlog replication, you are correct that GTID positioning and row-based replication are strongly recommended and widely used.
Regarding semi-sync replication: that's been a MySQL feature for over a decade now, and there are some indications from Oracle that it may become deprecated in the future. (which is surprising, since many large MySQL users do leverage it to ensure writes cannot be lost. But it seems Group Replication is promoted more by Oracle.)
MySQL semi-sync doesn't necessarily involve the setup you've described as "standard" above. In my experience it's more common to see 2 replicas doing semi-sync ack'ing, not 1. And sometimes these are just binlog servers rather than full MySQL replicas; that's the setup Facebook adopted in 2015, although more recently they've moved to a home-grown Raft-based replication system.
Today it just seems odd that anybody is still using MySQL. Postgres? Sure. SQLlite? Hell yeah! DuckDB? Of course. MySQL? Not so much.
Where I am in Canada, tax deductions are shitty because they come off the bottom of your income, so to speak. That is to say, the eligible expenses are added up and the lowest tax bracket rate is applied to them. You then get that as a tax credit. That's shitty because you paid for those expenses with your post-tax dollars at your full tax rate, but the credit is for a low tax rate.
Whereas a write-off comes off your income pre-tax, and so the benefit effectively operates at the marginal tax rate, and can knock you into a lower bracket.
I mean sure, it's a lot easier nowadays - but that's mostly down to cloud providers replacing half of the server-side challenge with a big bill and fiber making the last mile easier too.
You're massively underestimating the challenge of transferring these vast amounts of data without interrupting service for buffing etc that they had to solve back then
"...making the average engagement time per visit 9 minutes and 40 seconds"