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

271–280 of 310 posts

Re: Why we lost Uber as a user

#271

Post by bind »

duaneb wrote: post #258
angelbob wrote: post #160

Earlier quoted context omitted.

You're not wrong. But mostly we haven't collectively agreed that relational databases aren't great for highly-indexed rapid-update join tables. I think we will at some point. That's the primary original use case for a lot of NoSQL, and the reason Twitter had so much trouble with relational databases. But these are cultural understandings, and those move slowly. Also, we're poorly (collectively) equipped to handle sub…

How has NoSQL addressed join tables? All the approaches I've seen are much, much slower than with a traditionally vertically scaled relational database—or by moving away from joining altogether—it's traditionally been the twin pressures of scale and replication that force people to move to a distributed database.

NoSQL doesn't do table joins.

Re: Why we lost Uber as a user

#272

Post by otterley »

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…

You realize that Google, Facebook, Yahoo, and many, many other shops have successfully run on MySQL for well over a decade, right?

You can armchair engineer all you like, but at the end of the day, the proof of the engineering is in the working.

And if you have Uber stock you'd like to sell just because you think they're making a questionable engineering decision around databases (despite all the real world evidence that it is adequate to serve large scale businesses), I know a few investors who would gladly take it off your hands.

Re: Why we lost Uber as a user

#273

Post by ec109685 »

VLM wrote: post #117
DiabloD3 wrote: post #43

Earlier quoted context omitted.

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…

A better standard HN car analogy: Postgreql is trustworth and predictable and engineered and engineerable. Its like a German union automobile plant press operator sitting down on the job and crossing his arms until the broken safety switch is fixed, which will take precisely 3.25 hours and cost $X while the resulting assembly line shutdown costs 1000 x $X. But it'll be safe and nobody gonna lose an arm. Your downtime…

Can you site any of this? Facebook, Twitter, Google (for a long while), Uber, Yahoo all run critical systems on MySQL.

Re: Why we lost Uber as a user

#274

Post by ec109685 »

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…

500 updates is nothing for a modern database. 10k's of updates is no sweat on modern hardware. What is so scary about this load?

Re: Why we lost Uber as a user

#275

Post by evanelias »

dijit wrote: post #103
jamespo wrote: post #53

Earlier quoted context omitted.

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.

That isn't fully accurate.

It's true that the large majority of FB's mysql fleet is dedicated to the main product data, essentially an object-graph store with a restricted access pattern. The queries are indeed relatively simple. I can't remember for certain but I think that simple joins and transactions are actually used there.

However, the rest of the fleet supports an extremely diverse set of workloads -- keep in mind that MySQL is the primary data store of Facebook, and this includes product, ad serving, payments, async task persistence, internal tooling, many many other things. Countless different query patterns are in use. And although this is a minority of FB's mysql fleet, it's still many many thousands of machines supporting these other workloads, substantially larger than the vast majority of Postgres installations in the world.

(Source: I worked on MySQL automation at FB, and was lead dev on their RDS-like DBaaS, used by a large portion of the company's engineering teams in one way or another.)

I will readily admit that Postgres is a very good database, and definitely a better choice for OLAP workloads than MySQL (which has problems with complex queries) / InnoDB (problems with long-running read queries impacting old-row purge behavior). However, for extremely high-volume, large-scale OLTP workloads, MySQL/InnoDB is absolutely an excellent choice, imo better than Postgres for reasons of performance, ecosystem, and number experienced engineers who have worked at extreme scale.

Re: Why we lost Uber as a user

#276

Post by duaneb »

bind wrote: post #271
duaneb wrote: post #258

Earlier quoted context omitted.

How has NoSQL addressed join tables? All the approaches I've seen are much, much slower than with a traditionally vertically scaled relational database—or by moving away from joining altogether—it's traditionally been the twin pressures of scale and replication that force people to move to a distributed database.

NoSQL doesn't do table joins.

Well, F1 does. I'm fairly sure FoundationDB did too. It isn't incompatible--I'd argue joins are natural for certain tasks, and certainly reduce developer load, especially if the latency isn't a driving priority.

Yes, that's SQL, but the term nosql was always orthogonal to the priorities of the movement (horizontal scalability).

Re: Why we lost Uber as a user

#277

Post by _pmf_ »

serguzest wrote: post #198
_pmf_ wrote: post #37

Earlier quoted context omitted.

> Nice and clean post showing that acknowledging a weakness isn't a terrible choice. Reading between the lines: "let's ignore the obviously suboptimal choice of architecture and concentrate on the DB specific issues addressed". OTOH, what would be a nice way of doing CQRS completely within postgres?

https://github.com/JasperFx/marten

Ah, very nice!

Re: Why we lost Uber as a user

#278

Post by jeremycole »

Grishnakh wrote: post #172
kirubakaran wrote: post #161

Earlier quoted context omitted.

"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

Also, I'm pretty sure most of us are mispronouncing MySQL: IIRC, "My" (the Finnish name of his daughter) is pronounced like English "Me".

My is a Swedish name, not a Finnish one, as Monty is a Swedish-speaking Finn. It's pronounced similar to "Myeuh", so "Myeuh Ess Kuh Ell".

Re: Why we lost Uber as a user

#279

Post by vegabook »

PeCaN wrote: post #237
jamespo wrote: post #215

Earlier quoted context omitted.

I think there's something to be said for the Linus style

Yeah, but generally only when you're actually correct . If you're not, you look like an idiot. Apparently the parent hasn't heard of column-store relational databases (which are kinda great for time series). (I'm most familiar with SQL Server; DB2 and Oracle apparently have similar functionality.) Apparently their 3-5TB time series table chokes ‘dinosaur’ relational databases. For a time series table you should almos…

of course I've heard of column store relational databases, but they're not nearly as efficient nor scalable as Cassandra which has been built from the ground up for this. Fact is, if you don't need referential integrity, there is absolutely no need to pay the massive complexity overhead and horizontal scalability penalties that the relational databases incur.

Separately it is absolutely correct that a comment that asserts that 4 relational databases are the only serious ones is completely misguided and deserves a robust rebuke.

Re: Why we lost Uber as a user

#280

Post by taurath »

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.

I'd really like to know why they DIDN'T consider something like Redis for this - if I'm thinking of my own apps where I just take redis==sessions for granted, why would they make a technology change of this magnitude in order to cover a usecase like that? Maybe there was a lot more?
Post reply on HN