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: 5, Insightful) by stormreaver on Thursday July 28 2016, @02:02PM
I stopped reading at this point:
The bug we ran into only affected certain releases of Postgres 9.2 and has been fixed for a long time now. However, we still find it worrisome that this class of bug can happen at all. A new version of Postgres could be released at any time that has a bug of this nature, and because of the way replication works, this issue has the potential to spread into all of the databases in a replication hierarchy.
This is where the author lost all credibility for impartiality. He is clearly a MySQL fan, and is taking the long road to pretending to not be so. The reasons I make this conclusion are two-fold:
1) Bugs appear everywhere, even on usually rock-solid platforms such as PostgreSQL. Re-architecting your entire system due to a long-since-fixed bug is absurd.
2) MySQL is the king of data-destroying bugs (and data-destroying mis-features), so it is disingenuous at best to use the possibility of data corruption as a reason for using MySQL over PostgreSQL. With MySQL, you will corrupt your database. It's just a matter of time. And in the case of MySQL's data-destroying mis-features, there will be no way to fix it retroactively.
(Score: 2) by edIII on Thursday July 28 2016, @05:55PM
Was laughing my ass off as well. MySQL started out as a free toy database, quickly designed with, and poorly integrated into many open source projects. In its early days, you would hear horror stories for MySQL murdering databases and destroying projects . Meanwhile, I was playing around with Interbase and Firebird... you know... with ACID :) I never actually lost a Firebird database in over 10 years, before eventually switching to PostgreSQL.
MySQL has got a lot better in the last 10 years, but that doesn't erase it's rocky and spotty history with accuracy and data integrity. It was Hitler complaining about how many people were killed last year by rogue lawnmowers.
On occasion I'll work with MySQL, but I really don't like how it handles stored procedures and code. Not to mention views, queries, etc. I can get in there and perform maintenance, and tweaks, but I'll never design an entire platform with it on purpose. I've spent the time deciding between MySQL and PostgreSQL as both work with Asterisk 13. Going with PostgreSQL, in particular, for its excellent support on OpenBSD, especially with Perl scripts built-in to the database. Yeah, I want something where the project developers actually love, understand, and demand ACID.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by Thexalon on Thursday July 28 2016, @06:01PM
Which is one reason it makes a perfect pairing with PHP, which has the exact same problem! And in both cases, one of the problems is that they have to deal with legacy code the relies on the stupid decisions they made years ago before they knew better.
Also, apropos of nothing else, I agree that the Linux Standard Database, or "LSD" for short, ought to be ACID-compliant.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 1) by Bronster on Friday July 29 2016, @02:56AM
Wow. I didn't read that at all.
I run Cyrus IMAP with its application level replication protocol rather than DRBD under the hood because I know that I can screw up and break the internals in various ways - and I'd rather be shipping descriptive changes with protocol level invariant checking rather than shipping raw disk blocks and replicating any corruption without being able to apply additional sanity checks at the replication layer.
(I've also run MySQL in production, purely InnoDB, for over 10 years without data being destroyed, so I'm amused at your FUD about how it will corrupt your database)
(Score: 2) by stormreaver on Friday July 29 2016, @01:05PM
I've also run MySQL in production, purely InnoDB, for over 10 years without data being destroyed, so I'm amused at your FUD about how it will corrupt your database
I was being a bit hyperbolic about MySQL's data corruption, but the basic idea is true. MySQL changes your data to fit its constraints, rather than telling you that you passed bad data (which is once of its frequent data corrupting mis-features). And MySQL has a long and steady history of spontaneous database corruption after the fact, for no apparent reason other than bad internals.
I've watched MySQL self-destruct enough times to no longer even consider it an option for anything even remotely important.