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

161–170 of 310 posts

Re: Why we lost Uber as a user

#161

Post by kirubakaran »

enave wrote: post #147
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 ;)

Maybe, but it's a much better name than mysql. I feel like a little kid every time I say "my" anything.

"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

Re: Why we lost Uber as a user

#162

Post by angelbob »

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.

Sometimes this is very hard to do. This is in effect Twitter's core use case as well, with the list of accounts you follow.

And it's a hard problem. Twitter spawned a huge wave of NoSQL to deal with this, and it's still not really dealt with.

Re: Why we lost Uber as a user

#163

Post by wldcordeiro »

methehack wrote: post #145

Does anyone else think the scenario in the explanation is an unreasonable request to make of a relational database? I think that if you've created a design that requires you to update a 50K row table 500 times a second that itself is heavily indexed and used heavily in joins, you have a software design problem more than a database problem. I wouldn't expect any database to handle that and am surprised that mysql does…

Yeah it feels like the kind of thing where regardless of the database system they use they're going to eventually hit some performance issues, but undoing that DB mess is likely no easy task and they're betting that they can keep kicking the can there.

Re: Why we lost Uber as a user

#164

Post by blaze33 »

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 ;)

On the other hand it makes for more relevant search results!

Edit: did not see the typo at first though the word seemed longer than usual...

Re: Why we lost Uber as a user

#165

Post by morinted »

methehack wrote: post #145

Does anyone else think the scenario in the explanation is an unreasonable request to make of a relational database? I think that if you've created a design that requires you to update a 50K row table 500 times a second that itself is heavily indexed and used heavily in joins, you have a software design problem more than a database problem. I wouldn't expect any database to handle that and am surprised that mysql does…

I believe that was the subtext that the writer was trying to convey. Despite it being a bad pattern, it's one that their users still encounter and people are asking a solution for.

Re: Why we lost Uber as a user

#166

Post by eternalban »

coldtea wrote: post #24
jhh wrote: post #6

The attitude with which the article is discussed in the mailing list is admirable.

Couldn't help contrasting it to some popular programming language mailing lists, especially a CSP inspired language by a major search company.

In contrast, there is the community of a "useless language" (to quote one of its leading lights) that has never adopted [the] acceptance of paternalism as a requirement of espirit de corps.

imho some of the glaring shortcomings of the technology you refer to can be traced back to the very issue that you are highlighting.

Re: Why we lost Uber as a user

#167

Post by Grishnakh »

scardine wrote: post #57
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 ;)

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 most of the names Microsoft uses for its software.

Re: Why we lost Uber as a user

#168

Post by assface »

ansible wrote: post #105
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…

... 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), You may be interested in CockroachDB, which was inspired by Google's F1 and Spanner implementations. https://www.cockroachlabs.com/ Another contender…

> Another contender was FoundationDB,

No, it was not. FoundationDB's SQL layer was a joke. The system was horribly slow. Every DBA that I talked to that tried it said that it did not deserve the hype that it got.

Re: Why we lost Uber as a user

#169

Post by lemcoe9 »

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.

Is this not what Redis was designed for? In this situation, I would value Redis over memcached just based on its performance values and the cheapness of RAM in the cloud right now.

Re: Why we lost Uber as a user

#170

Post by fleetfox »

MadWombat wrote: post #133

I see some comments call this a "very specific user case". This is not. Pretty much every major web project is going to have tables like that. User sessions are just one example. Sure, you can design around this, but it is a problem and no design is going to make it completely go away.

Storing sessions in rdbms is a rather poor choice espesially at scale.
Post reply on HN