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

101–110 of 310 posts

Re: Why we lost Uber as a user

#101

Post by dijit »

stonewhite wrote: post #83
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…

Github works on MySQL and they got pretty good at it. Ubers engineers made a respectable decision by switching to a lower-hyped database purely on excellent engineering.

Mitigating against your database going mental is scary and should not be encouraged but it's the default in most MySQL shops.

Whether you /can/ coerce it into doing the right thing is not the issue, Uber are doing their own thing regardless of if its right anyway so they're unlikely to change in that regard- what makes you sure they will do MySQL right at all?

Re: Why we lost Uber as a user

#102

Post by vegabook »

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…

> Given that, there are only four dbs worth using: Postgre, Oracle, DB2, and MS SQL

This is total bullshit. Even a modest size database (3-5 terabyte) for a small company like mine, chokes a relational database bigtime on time series. Especially the modern use cases where you are ingesting fast. You need Cassandra or Hbase which are very serious pieces of technology and are definitely "worth using", and will crush any of the four relational dinosaurs you mention in that space at comparable cost, and with embarrassingly better scalability. And by the way, that space is not some corner case, it is probably the major growth area of the next computing era.

Re: Why we lost Uber as a user

#103

Post by dijit »

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?

Facebook are using MySQL as an object store with no transactions, complex queries or even joins.

I could be wrong but most databases are pretty competent with this style of workload.

Re: Why we lost Uber as a user

#104

Post by bluejekyll »

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

While I don't care about mongoDB, who's running 32bit anymore? And for a production DB?

Re: Why we lost Uber as a user

#105

Post by ansible »

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…

... 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 was FoundationDB, but Apple bought them and stopped selling it as a product.

Re: Why we lost Uber as a user

#106

Post by [deleted] »

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.

[deleted]

Re: Why we lost Uber as a user

#108

Post by sciurus »

DiabloD3 wrote: post #43
nubela wrote: post #36

Earlier quoted context omitted.

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.

Uber relies entirely on their database. If the database is slow, or cannot be considered reliable under extreme load, or can lose data in ways that are hard to recover, then Uber can potentially lose a lot of money especially during peak hours. Yes, I'm aware there are systems for MySQL to handle failure, but I'm also aware of the systems for Postgre, and Postgre's failure handling seem to be far saner and easier to…

Here is an Uber engineer's talk about their worst outage ever. 16 hours of downtime for their API as they repeatedly try and fail to promote a new postgresql master and reparent slaves to it.

https://www.youtube.com/watch?v=bNeZYVIfskc&t=26m54s

https://surge.omniti.com/2015/images/presentations/MattRanne... (Slides 39-63)

Re: Why we lost Uber as a user

#109

Post by SmellTheGlove »

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…

Maybe I've been in big companies for too long, but why not Teradata? Yeah it's expensive for the amount of storage Uber would need, but it's going to scale for them and perform well.

Re: Why we lost Uber as a user

#110

Post by spriggan3 »

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…

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

I've been running a few MySQL setups for a decade, why do you think it is not a good fit for enterprise apps? InnoDB solves most of the previous limitations. I also think MySQL is slightly easier to deploy/scale than Postgres. I believe Facebook is still running MySQL for instance.

Post reply on HN