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

31–40 of 310 posts

Re: Why we lost Uber as a user

#31

Post by chii »

coldtea wrote: post #25
ZanyProgrammer wrote: post #13

Its weird seeing a post mortem for losing a user (I really want to say customer) from a piece of FOSS. Its also weird (still!) to consider Uber a tech company, rather than a company that happens to use tech.

They don't "happen to use tech", their whole business is based on tech, and not in the way a bank would use tech say, but especially on tech they create (the client, the reservations system, extra services, etc). It's like saying Google is just an ad company that "happens to use tech".

why isn't the tech that a bank would create in house be categorized similarly to the tech uber creates?

Re: Why we lost Uber as a user

#32

Post by redwood »

mnw21cam wrote: post #18
erikb wrote: post #12

I agree it's a nice thing. But some kind of answer may also be good. Like restructuring your data to become faster. I also wonder what happened the last few (10) years. When I was in university I'm pretty sure I learned that JOIN was Satan's mother and if you have a big DB you need to avoid JOINs as much as possible. That's not a big deal today anymore, it seems.

That kind of thinking is probably what spawned the whole "do the join in the app, not the database" anti-pattern. The truth is, the database is going to be much faster at performing a join than loading the contents of two tables into your app and iterating. If you need the data that results from doing a join, doing a join is the best way to get it. Unless you already have your entire database in-memory in your app, t…

I think he's referring to denormalizing.

Re: Why we lost Uber as a user

#33

Post by DiabloD3 »

collyw wrote: post #7
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.

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 writes) can slow to 200MB/sec even on those insanely fast "enterprise" PCI-E SSDs that do 2-4GB/sec continuous reads.

Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and MS SQL. Unless you're doing something that is truly not suited for SQL (or SQL is insanely overkill), or you're Google and have a database in the hundreds or thousands of TB and literally have to write your own database (they went from almost inventing mapreduce, to going full circle back to full scale distributed RDBMS SQL with F1, which I wish they'd open source), any other database is just going to be a pain in the ass, buggy, and full of gotchas and undiscovered corner cases simply because it doesn't have over a decade of development and millions of users behind it.

Also, I have not included MySQL for obvious reasons: fun for toy SQL DBs where sqlite isn't a good fit, but not for enterprise use by any means. Uber switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber investor right now.

Re: Why we lost Uber as a user

#34

Post by [deleted] »

mnw21cam wrote: post #18
erikb wrote: post #12

I agree it's a nice thing. But some kind of answer may also be good. Like restructuring your data to become faster. I also wonder what happened the last few (10) years. When I was in university I'm pretty sure I learned that JOIN was Satan's mother and if you have a big DB you need to avoid JOINs as much as possible. That's not a big deal today anymore, it seems.

That kind of thinking is probably what spawned the whole "do the join in the app, not the database" anti-pattern. The truth is, the database is going to be much faster at performing a join than loading the contents of two tables into your app and iterating. If you need the data that results from doing a join, doing a join is the best way to get it. Unless you already have your entire database in-memory in your app, t…

[deleted]

Re: Why we lost Uber as a user

#35

Post by ZanyProgrammer »

menzoic wrote: post #17
ZanyProgrammer wrote: post #13

Its weird seeing a post mortem for losing a user (I really want to say customer) from a piece of FOSS. Its also weird (still!) to consider Uber a tech company, rather than a company that happens to use tech.

Just curious, what's your definition of "Tech Company"? All services provided by Uber are purely technical. Drivers and Riders are customers of Uber's technology. The full name of the company is "Uber Technologies Inc."

Well if that's what their name says it must be true!

Re: Why we lost Uber as a user

#36

Post by nubela »

DiabloD3 wrote: post #33
collyw wrote: 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…

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.

Re: Why we lost Uber as a user

#37

Post by _pmf_ »

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?

Re: Why we lost Uber as a user

#38

Post by oblio »

chii wrote: post #31
coldtea wrote: post #25

Earlier quoted context omitted.

They don't "happen to use tech", their whole business is based on tech, and not in the way a bank would use tech say, but especially on tech they create (the client, the reservations system, extra services, etc). It's like saying Google is just an ad company that "happens to use tech".

why isn't the tech that a bank would create in house be categorized similarly to the tech uber creates?

Well, the main difference I'd expect from Uber vs a bank is that the majority of Uber employees are (software) engineers while the majority of bank employees are economists.

Re: Why we lost Uber as a user

#39

Post by czep »

oblio wrote: post #38
chii wrote: post #31

Earlier quoted context omitted.

why isn't the tech that a bank would create in house be categorized similarly to the tech uber creates?

Well, the main difference I'd expect from Uber vs a bank is that the majority of Uber employees are (software) engineers while the majority of bank employees are economists.

The majority of Uber employees... are drivers. Clearly proportion of software engineers cannot be a good metric for what makes a "tech" company.

Re: Why we lost Uber as a user

#40

Post by nxzero »

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.

>> "focus is on how to work to fix these use cases, instead of pointless mudslinging"

More than that, within PoststgreSQL I get the sense that while there are serious discussions, all parties try to understand alternative positions and resolve conflicts instead of letting them brew.

Post reply on HN