Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we lost Uber as a user

postgresql.org

Post reply on HN
Print view View original

241–250 of 310 posts

Re: Why we lost Uber as a user

#241

Post by MichaelGG »

fennecfoxen wrote: post #82
mixedCase wrote: post #64

Earlier quoted context omitted.

>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…

It's the On Error Resume Next of databases.

Re: Why we lost Uber as a user

#242

Post by MichaelGG »

brazzledazzle wrote: post #222
StavrosK wrote: post #88

Earlier quoted context omitted.

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.

And that's the real issue I would think. If it shut itself down or went into read-only and generated errors it wouldn't be so bad. The limitations 32-bit architectures are why we have 64bit architectures. I think it's fair as a developer to require x64 instead of jumping through hoops to support both architectures. But if you're going to release 32-bit binaries for something like development or testing you should be…

This stems from their choice of "mmap and done" as their entire IO strategy, for earlier versions. The data loss is silly though and shows their attitude.

Re: Why we lost Uber as a user

#243

Post by MichaelGG »

combatentropy wrote: post #223

This later comment in the thread ( https://www.postgresql.org/message-id/flat/7663dfec-e46a-401... ), by Merlin Moncure, describes a set-up that most applications have, and I agree with his assessment of it: Taking a step back, from the outside, it looks like uber: *) has a very thick middleware, very thin database with respect to logic and complexity *) has a very high priority on quick and cheap (in terms of bandwi…

Uber's original post made the case that their engineers might not understand that keeping a DB transaction open while sending an email is not a good idea. Either I have an incredibly unrealistic expectation for "engineers" or Uber's team has low standards.

Re: Why we lost Uber as a user

#244

Post by teddyh »

kbenson wrote: post #200
Grishnakh wrote: post #167

Earlier quoted context omitted.

Slightly clunky names are fine as long as they're somewhat cute or clever. Names are important because it's how we identify and remember things, and a catchy name (even if it seems a little ridiculous or clunky) is better than a boring, banal name if the catchy name is memorable. I'll take PostgreSQL's name (which I consider clever) any day over some name completely devoid of originality or thoughtfulness, such as mo…

Yes, at least it's searchable. The current trend of using common words as names was ridiculous as of a few years ago. Now it's just painful. Someone's going to name their project "The" and I'm not sure I'll be able to remain civil at that point.

There used to be a project named “THE”, but its name was changed to “Archy”:

https://en.wikipedia.org/wiki/Archy

Re: Why we lost Uber as a user

#245

Post by cpeterso »

phaed wrote: post #186
craigkerstiens wrote: post #173

Earlier quoted context omitted.

A small bit of history from Tom Lane one of the biggest contributors to the project "Arguably, the 1996 decision to call it PostgreSQL instead of reverting to plain Postgres was the single worst mistake this project ever made." - https://www.postgresql.org/message-id/2693.1152762174@sss.pg...

> It seems too late to change it now That's what they said in 1996. Then they said it again in 2006. In 2026 when its interwoven in all sorts of AI systems and still causing confusion, they will be looking back thinking why didn't they fix it back in 2017 when they still could. "Now" is always the right time, it's never too late.

And the name "Postgres" was an extension of "Ingres":

https://en.wikipedia.org/wiki/Ingres_(database)

Re: Why we lost Uber as a user

#246

Post by viraptor »

dkersten wrote: post #98
matwood wrote: post #81

Earlier quoted context omitted.

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.

I was recently advised by a DB consultant whose area of expertise is MySQL that 5.7 is still too new and risky and that he would advise against upgrading for at least another 6 months or more. He feels that the releases come out much, much too unstable and unpolished and that it typically takes at least a year since release before he's comfortable running it in production. I don't know enough about MySQL to know if t…

Beware slight ddl incompatibilities. For example Maria will dump timestamp field size, which mysql doesn't understand (or was it the other way around?...)

Re: Why we lost Uber as a user

#247

Post by SQLite »

Grishnakh wrote: post #172
kirubakaran wrote: post #161

Earlier quoted context omitted.

"My" of MySQL is Monty's daughter. "He lives in Helsinki with his second wife Anna and daughter Maria (after whom MariaDB was named), and has a daughter My (after whom MySQL was named)[14] and a son Max (giving the name for MaxDB) from his first marriage" https://en.wikipedia.org/wiki/Michael_Widenius

Also, I'm pretty sure most of us are mispronouncing MySQL: IIRC, "My" (the Finnish name of his daughter) is pronounced like English "Me".

I don't speak Finnish. But I did once hear David Axmark pronounce My's name, and to my ear it sounded like "Mih" - an "M" followed by a short vowel similar to the vowel in "bit". In other words, My's name is the same as Mitt Romney's first name, just without the "t" at the end.

Re: Why we lost Uber as a user

#248

Post by DiabloD3 »

VLM wrote: post #117
DiabloD3 wrote: post #43

Earlier quoted context omitted.

Uber relies entirely on their database. If the database is slow, or cannot be considered reliable under extreme load, or can lose data in ways that are hard to recover, then Uber can potentially lose a lot of money especially during peak hours. Yes, I'm aware there are systems for MySQL to handle failure, but I'm also aware of the systems for Postgre, and Postgre's failure handling seem to be far saner and easier to…

A better standard HN car analogy: Postgreql is trustworth and predictable and engineered and engineerable. Its like a German union automobile plant press operator sitting down on the job and crossing his arms until the broken safety switch is fixed, which will take precisely 3.25 hours and cost $X while the resulting assembly line shutdown costs 1000 x $X. But it'll be safe and nobody gonna lose an arm. Your downtime…

I applaud you. That is exactly MySQL vs Postgresql in a nutshell.

Re: Why we lost Uber as a user

#250

Post by DiabloD3 »

_ea1k wrote: post #139
DiabloD3 wrote: post #33

Earlier quoted context omitted.

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. I guess you wouldn't have wanted to be a GOOG investor either? Most of their early revenue was from AdWords on MySQL.

I actually know engineers who work for Google for that. Google maintains their own MySQL fork internally and also know exactly how MySQL fucks up and has planned for MySQL failure in depth.

Google is maybe the only company I trust to know what they're doing when it comes to databases.

Post reply on HN