SoylentNews is people
SoylentNews
[redacted] Coward writes:
https://eng.uber.com/mysql-migration/
The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL. In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL.
[...] We encountered many Postgres limitations:
Inefficient architecture for writes
Inefficient data replication
Issues with table corruption
Poor replica MVCC support
Difficulty upgrading to newer releases
(Score: 4, Interesting) by VLM on Thursday July 28 2016, @02:23PM
The "real" difference between mysql and postgresql is merely philosophical. With about 95% accuracy you can predict the design and architectural and implementation differences using philosophy. Seriously.
Almost always mysql is cub scout "try your best". If thats not perfect, well, at least we tried our reasonable best. At least 99% of our users are really happy and if you're in that 1% well really sorry, but at least we're fast.
Almost always postgresql is perfectionist or bust. If thats not perfect, crash out with error and return failure codes and stuff. We might even give you an error message that is not misleading and written in Klingon, or maybe not, and we might be slower than molasses in January but at least we're perfect.
Needless to say one outlook on life is enormously faster, another is more "trustworthy" by accuracy metrics (although much worse by uptime and ship date metrics)
So the story is their app went from monolithic where you gotta choose one or the other whichever fits the best, however poorly, to microservices where you can always pick the "best" tool for the philosophical job. Unsurprisingly that lead to a mix. I'll take a wild guess that something like marketing survey stuff uses lightning fast mysql and something reliability oriented like financial charging register probably uses postgresql.
I've tried stuff like this at work (not uber) and its an ungodly pain in the ass that somehow Great Cthulhu's Flipper magically inspires non-technical users to demand a business critical report like five minutes after I implement the separate servers that could have been done in a minute with a simple JOIN but now they're separate servers and separate architectures its gonna be a survivable PITA... Like most problems there are multiple solutions and after much heavy drinking I have played with things like a mysql "sorta mirror" of the postgres server accessed from the real mysql server as a federated engine. Mostly because I'd never done anything interesting with federated engines on mysql and after using it I'm pretty comfortable never peering into that abyss again. Although it was weirdly fun.
Something interesting to point out about "slow" and "fast" from an old timer, is unless you're the worlds biggest whatever, everything is fast on commodity hardware. Also everything thats "slow" today on commodity hardware is "fast" on commodity hardware in about five years, so unless you're in a hurry it don't matter. So murphy's law naturally is if you can't find your business process bottlenecks, just use a slow DB or whatever and the users and trouble tickets will isolate it for you "for free".