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

91–100 of 310 posts

Re: Why we lost Uber as a user

#91

Post by johnnyhillbilly »

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.

I have worked a lot with systems like Teradata, and I am trying to explain to the want-NoSQL-on-my-CV-crowd that large/complex JOINs are _really_ not a problem. Also trying to explain that relations in RDBMS' have nothing to do with relationships, and that normalization is just a tool that provides certain guarantees on the data you store is simply ignored :)

Re: Why we lost Uber as a user

#94

Post by DiabloD3 »

rlpb wrote: post #61
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 ;)

You may call it Postgres: https://wiki.postgresql.org/wiki/ProjectName

Or pg if the context is clear enough.

Re: Why we lost Uber as a user

#95

Post by davidgerard »

LeifCarrotson wrote: post #41
rimantas wrote: post #21

but have you used MySQL? Maybe I am too nitpicky, but I always get suspicious when people make claims about technology whose name they cannot spell right.

In this case, Fabian's CV (linked from his GitHub profile, linked from his HN profile) does claim MySQL experience - correctly capitalized. But yes, I also get suspicious when people can't spell a technology correctly. For example, anyone who has spent time reading some documentation will know that Lua is capitalized in title case, and not written LUA.

The correct spelling is "MariaDB".

Re: Why we lost Uber as a user

#97

Post by emn13 »

brightball wrote: post #45

In reading that, my first thought was "why in the world would Uber do that?" In every single performance tuning a scale story that I've read over the past decade, the very first point of order is: remove joins from high traffic queries. It seems like Uber has gone the complete opposite direction.

It's unrealistic to remove all joins (usually), and most joins aren't very expensive. In normal cases a join is strictly faster than running an extra query to get that extra data.

Joins start getting particularly tricky when you do expensive stuff like filter over the correlated results of many tables. But in those cases, there's also no easy alternative: you'll need to redesign the way you store your data, if possible.

Re: Why we lost Uber as a user

#98

Post by dkersten »

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

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 that's true or not.

We are now investigating switching to MariaDB instead. (I'd personally love to move to Postgres, but that's not likely to happen any time soon)

Re: Why we lost Uber as a user

#99

Post by DCoder »

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

> When running a 32-bit build of MongoDB, the total storage size for the server, including data and indexes, is 2 gigabytes. For this reason, do not deploy MongoDB to production on 32-bit machines.

From https://docs.mongodb.com/manual/installation/#faq-32-bit-lim...

There was also the issue where errors were either logged or not, based on the result of Math.random(): http://stackoverflow.com/q/16833100/1233508

Post reply on HN