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

71–80 of 310 posts

Re: Why we lost Uber as a user

#71

Post by piaste »

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?

Without banking technology, a bank can still be a bank and provide its distinctively unique services, just slower. It worked for the Templars, and they didn't even have double-entry bookkeeping.

Without Uber technology, Uber would not exist - it would just be Uber Taxi Inc., a perfectly ordinary taxi company indistinguishable from all others.

Re: Why we lost Uber as a user

#72

Post by kstenerud »

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

Here we go down the etymology hole, where original intent is forgotten, and argumentative minutiae reign supreme.

Re: Why we lost Uber as a user

#73

Post by romanows »

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

As a casual observer, their whole business actually seems based on lobbying and lawyers.

Re: Why we lost Uber as a user

#74

Post by thom_nic »

oneloop wrote: post #20
spriggan3 wrote: post #10

Earlier quoted context omitted.

> MongoDb which claims to be great at everything lol right, with MongoDb, Map Reduce is a joke, GridFS is slow and barely usable, the storage is extremely inefficient, the "query engine" slow, and don't get me started on their "full text search" engine. MongoDb is a successful marketing stunt in the "Nodejs era".

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.

Re: Why we lost Uber as a user

#75

Post by lostcolony »

erikb wrote: post #46
dagss wrote: post #29

Earlier quoted context omitted.

What you are missing here is "denormalization" -- e.g. many-to-many relationships. You can either use a JOIN with a table on a "normalized" database, or keep managing the result of the join in application code. Loading the entire tables into application code very seldom has anything to do with it... A more realistic example is, do you get Alice's pets by doing a JOIN on tables Person, Pet, PetOwnedByPerson ("SQL") --…

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 software devs and DBAs.

Re: Why we lost Uber as a user

#76

Post by sneak »

jamespo wrote: post #53
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…

Maybe Facebook investors should bail out too by that reasoning?

Google, too.

Re: Why we lost Uber as a user

#77

Post by baakss »

erikb wrote: post #46
dagss wrote: post #29

Earlier quoted context omitted.

What you are missing here is "denormalization" -- e.g. many-to-many relationships. You can either use a JOIN with a table on a "normalized" database, or keep managing the result of the join in application code. Loading the entire tables into application code very seldom has anything to do with it... A more realistic example is, do you get Alice's pets by doing a JOIN on tables Person, Pet, PetOwnedByPerson ("SQL") --…

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

Yes, especially in business intelligence / data warehousing. Here is an excellent resource if you're interested in this sort of thing: https://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimen...

Re: Why we lost Uber as a user

#78

Post by moomin »

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…

It really depends. Sometimes it's possible to slurp relatively small subsets in. Sometimes you've already got the data loaded in memory for other reasons. Sometimes (especially in long-running ETL stuff) you can come up with a way better query plan than a query-by-query approach could achieve.

But yeah, usually, don't be clever and don't spaff the contents of the database across a network just to do a join.

Re: Why we lost Uber as a user

#79

Post by baakss »

lostcolony wrote: post #75
erikb wrote: 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…

The link I posted above is a common SQL land usage. Dimensional modeling in a star schema is very widely used in BI projects.

There's actually two competing philosophies on data warehousing (Inmon and Kimball), but I've only ever used Kimball's method, which favors denormalization.

http://www.computerweekly.com/tip/Inmon-vs-Kimball-Which-app...

Re: Why we lost Uber as a user

#80

Post by vmateixeira »

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

Acording to UK's Companies House search, Uber's nature of business (SIC) is 74990 - Non-trading company. This is quite vague but it doesn't mention technology.

Interestingly, they were also called UBER TECHNOLOGIES LTD and UBERTECHNOLOGY LIMITED at some point in time, but these companies are now dissolved.

Post reply on HN