Why we lost Uber as a user • Hacker News Board

Re: Why we lost Uber as a user

#191

Post by noisy_boy » Mon, Aug 01, 2016, 5:34 PM UTC

babuskov wrote: post #28

matthewmacleod wrote: post #11

The PoststgreSQL project never fails to impress me. I know that there are some use cases which are not currently covered by it versus alternatives, but I have consistently got the feeling that everybody involved in the project is supremely professional and interested in building an excellent database – and the focus is on how to work to fix these use cases, instead of pointless mudslinging. Class act.

> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)

Given a choice, I would name it PostSQL.

Re: Why we lost Uber as a user

#192

Post by [deleted] » Mon, Aug 01, 2016, 5:38 PM UTC

noisy_boy wrote: post #191

babuskov wrote: post #28

Earlier quoted context omitted.

> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)

Given a choice, I would name it PostSQL.

[deleted]

Re: Why we lost Uber as a user

#193

Post by cobbzilla » Mon, Aug 01, 2016, 5:49 PM UTC

qopp wrote: post #177

cobbzilla wrote: post #146

great explanation by the Postgres crew. it makes me wonder, though: if I had a table with 50k rows, updated hundreds of times per second and used in joins throughout the database, is there any way I can just stick that whole table into memcached or redis? I know there are some cases where this works, some where it doesn't. curious if this option was explored.

Just to keep it in memory? Postgres does this already-- it will put tables or parts of tables in memory to speed up reads [1]. [1] Source: https://momjian.us/main/writings/pgsql/hw_performance/

It's not about "just" keeping it in memory, it's about handling hundreds of updates per second without creating un-vacuumable bloat (per description in OP's link).

Re: Why we lost Uber as a user

#194

Post by cdelsolar » Mon, Aug 01, 2016, 5:57 PM UTC

spacecop wrote: post #185

_RPM wrote: post #144

Earlier quoted context omitted.

Reddit styles puns aren't allowed here, that's why you're getting downvoted.

what an enlightened community of robot people

I upvoted the puns, don't worry.

Re: Why we lost Uber as a user

#195

Post by ben_jones » Mon, Aug 01, 2016, 6:02 PM UTC

brianwawok wrote: post #132

tjsousa wrote: post #107

Earlier quoted context omitted.

I sense an off by one error in this sentence...

No it's premature optimization.

I've never been accused of premature optimization

Re: Why we lost Uber as a user

#196

Post by matwood » Mon, Aug 01, 2016, 6:03 PM UTC

merb wrote: post #189

sciurus wrote: post #108

Earlier quoted context omitted.

Here is an Uber engineer's talk about their worst outage ever. 16 hours of downtime for their API as they repeatedly try and fail to promote a new postgresql master and reparent slaves to it. https://www.youtube.com/watch?v=bNeZYVIfskc&t=26m54s https://surge.omniti.com/2015/images/presentations/MattRanne... (Slides 39-63)

the problem mostly happened cause ppl just ignored the "running out of disk space" message. Would happen on mysql, too. And I really wouldn't want that to happen on galera, I guess that would be a way bigger desaster.

Running out of disk space on any RDBMS is a bad day.

Re: Why we lost Uber as a user

#197

Post by sluukkonen » Mon, Aug 01, 2016, 6:03 PM UTC

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".

The y is pronounced like the ü in über.

Re: Why we lost Uber as a user

#198

Post by serguzest » Mon, Aug 01, 2016, 6:08 PM UTC

_pmf_ wrote: post #37

gnur wrote: post #4

Wow, nice explanation. I was expecting a lengthy post with refuting everything uber said and explaining why pgsql was a better choice and uber was wrong. Nice and clean post showing that acknowledging a weakness isn't a terrible choice. I do wonder whether a different data structure would have mitigated the issue instead of transitioning to a different storage engine.

> Nice and clean post showing that acknowledging a weakness isn't a terrible choice. Reading between the lines: "let's ignore the obviously suboptimal choice of architecture and concentrate on the DB specific issues addressed". OTOH, what would be a nice way of doing CQRS completely within postgres?

https://github.com/JasperFx/marten

Re: Why we lost Uber as a user

#199

Post by cdelsolar » Mon, Aug 01, 2016, 6:15 PM UTC

DiabloD3 wrote: post #43

nubela wrote: post #36

Earlier quoted context omitted.

You wouldn't wanna be an Uber investor because choice of DBMS? As a programmer, I think this is the problem with developers thinking that technical problems are a bigger deal than it is.

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…

Please don't call it Postgre...

Re: Why we lost Uber as a user

#200

Post by kbenson » Mon, Aug 01, 2016, 6:15 PM UTC

Grishnakh wrote: post #167

scardine wrote: post #57

Earlier quoted context omitted.

If only a clunky name was the worst problem with some software (even closed source) we have to deal with.

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.