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

141–150 of 310 posts

Re: Why we lost Uber as a user

#141

Post by Thaxll »

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…

Facebook is a massive MySQL user so you wouldn't be a Facebook investor as well?

Re: Why we lost Uber as a user

#142

Post by zeveb »

ngcazz wrote: post #115
ZoFreX wrote: post #59

Earlier quoted context omitted.

Really? I will claim you will not meet many engineers who know more about Tcl than I do, and I can't remember whether it's TCL or Tcl. The absence of that knowledge has not impeded me from editing the Tcl interpreter itself. I am not convinced such pedantic measure of spelling is an accurate predictor of knowledge, to me it sounds more like elitism.

Table manners, itsy-bitsy rules for itsy-bitsy people as Robert Pirsig put it.

Or, table stakes to distinguish folks worth spending time on & folks not worth spending time on. Since it's so easy to get the little things right, anyone who doesn't is just a bit suspect.

It's like discarding resumés which arrive with large food stains on them. It's just too easy to print off a clean copy, that anyone who doesn't must be a bit off.

Re: Why we lost Uber as a user

#143

Post by spacehunt »

spotman wrote: post #131
dumbfounder wrote: post #86

Sounds like postgres needs to support pluggable storage engines. I am sure Uber (and many others) would have paid some license fee to someone who developed a storage engine that fixed this use case. Think of how much it cost them to switch...

Yea would be amazing to see an innodb backend for PG! ( I'll let myself out ;)

There _is_ a Foreign Data Wrapper that wraps MySQL[1]. Not exactly the same thing though, and no idea how well it works.

[1] https://github.com/EnterpriseDB/mysql_fdw

Re: Why we lost Uber as a user

#145

Post by methehack »

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. One has to ask: for how long will it work? Surely the clock is running out on such a design.

Re: Why we lost Uber as a user

#146

Post by cobbzilla »

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.

Re: Why we lost Uber as a user

#147

Post by enave »

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

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

Re: Why we lost Uber as a user

#149

Post by jrochkind1 »

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

The design of MySQL has a lot more silent failures, silent coercing of data, and other ways that it attempts to do what it thinks you might mean (because you're an incompetent PHP programmer) instead of what you ask. The obvious example is that SELECT 0 = 'banana' returns 1. A typical takedown would be the likes of: http://grimoire.ca/mysql/choose-something-else (which also touches storage engine configuration things…

I'm pretty sure Uber has enough money and enough developers to configure MySQL to not do any of that.

Re: Why we lost Uber as a user

#150

Post by jrochkind1 »

zspitzer wrote: post #67
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") --…

or you can use a materialized view https://www.postgresql.org/docs/current/static/rules-materia...

I don't think materialized views are an answer to this problem, precisely because postgres materialized views do not automatically update when the underlying data has changed.
Post reply on HN