Live data from Hacker News

Why we lost Uber as a user

postgresql.org

81–90 of 310 posts

Re: Why we lost Uber as a user

#81

Earlier quoted context omitted.

Mysql eats and corrupts data by design. For a company responding to real time events in physical world, that can be a big issue. I know they're trying to improve their defaults lately, but a lot of weird behaviour remains. And you don't have to be an expert DBA to know that choosing a technology known for silent data corruption is risky.

>Mysql eats and corrupts data by design. I'd like to have a source on that, would help shutdown a lot of MySQL discussions if true.

You can Google for silent truncation for a quick example. To be fair, MySql > 5.6 has fixed some of these issues and it also has some flags that can be set to help prevent them.

The by design part is referring to early versions of mysql and discussions around it purposely did not care about ACID. Speed was the number one driver.

Re: Why we lost Uber as a user

#82

Earlier quoted context omitted.

Mysql eats and corrupts data by design. For a company responding to real time events in physical world, that can be a big issue. I know they're trying to improve their defaults lately, but a lot of weird behaviour remains. And you don't have to be an expert DBA to know that choosing a technology known for silent data corruption is risky.

>Mysql eats and corrupts data by design. I'd like to have a source on that, would help shutdown a lot of MySQL discussions if true.

The design of MySQL has a lot more silent failures, silent coercing of data, and other ways that it attempts to do what it thinks you might mean (because you're an incompetent PHP programmer) instead of what you ask. The obvious example is that SELECT 0 = 'banana' returns 1.

A typical takedown would be the likes of: http://grimoire.ca/mysql/choose-something-else (which also touches storage engine configuration things that are easier to defend against by an experienced organization). Unfortunately this sort of takedown solves very few discussions.

Re: Why we lost Uber as a user

#83
post #7

Earlier quoted context omitted.

Yes, I have a lot more respect for this than say MongoDb which claims to be great at everything.

For the kind of stuff Uber stores, they may actually be doing it wrong (given what that Postgre mailing list post says) because that is one hell of an ugly use case for any DB. I would have tried solving it by loading a dual E5v4 server full of 3TB and a slew of SSDs for L2ARC+ZIL under ZFS: more SSDs > bigger SSDs because the absolute worst case SSD performance that any and all SSDs suffer from is random reads (not…

Github works on MySQL and they got pretty good at it. Ubers engineers made a respectable decision by switching to a lower-hyped database purely on excellent engineering.

Re: Why we lost Uber as a user

#86
Sounds like postgres needs to support pluggable storage engines. I am sure Uber (and many others) would have paid some license fee to someone who developed a storage engine that fixed this use case. Think of how much it cost them to switch...

Re: Why we lost Uber as a user

#87
post #46

Earlier quoted context omitted.

Yes "denormalization" was the word for that. Is that still a thing?

It's a term used frequently in NoSQL land, to explain a key difference to people coming from SQL. In SQL land, normalizing your data is still the canonical thing to do, and I don't recall anyone in academia officially talking about denormalizing ever having its place...but in industry, the realities of use cases and performance have meant its usage. But I don't know that it's a standard tool given out to graduating s…

Of course they do, that's why there are the Normal Forms. Since like the 1970s people have been talking about this stuff. It's actual maths.

Re: Why we lost Uber as a user

#88
post #20

Earlier quoted context omitted.

Also, wasn't there a ridiculous issue that they had where the db can't be bigger than 4gb on a 32 bit file system because that's the largest size a file can have...?

Yes, apparently the limit on 32-bit is 2GB actually. MongoDB has always stated upfront that 32-bit architectures are not recommended for production use for precisely this reason: http://blog.mongodb.org/post/137788967/32-bit-limitations This has also has been stated on their download page for 32-bit binaries as well.

It hasn't always been stated there, and it was a warning on a README somewhere. The server would run happily on 32 bits, and never crash or produce any user-visible errors, it would just silently corrupt data while pretending the insertion went great.

Re: Why we lost Uber as a user

#89
I think it's very cool that Postgres didn't just post some long thing about Uber saying "they're using it wrong omg!!!" and instead address the problems, understand their decision, and move on. I think that's very cool, there's clearly a good team working on this DB.

Re: Why we lost Uber as a user

#90
post #7

Earlier quoted context omitted.

Yes, I have a lot more respect for this than say MongoDb which claims to be great at everything.

For the kind of stuff Uber stores, they may actually be doing it wrong (given what that Postgre mailing list post says) because that is one hell of an ugly use case for any DB. I would have tried solving it by loading a dual E5v4 server full of 3TB and a slew of SSDs for L2ARC+ZIL under ZFS: more SSDs > bigger SSDs because the absolute worst case SSD performance that any and all SSDs suffer from is random reads (not…

>Uber switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber investor right now.

That is extremely hyperbolic.

Post reply on HN