Live data from Hacker News

Why we lost Uber as a user

postgresql.org

281–290 of 310 posts

Re: Why we lost Uber as a user

#281

Earlier quoted context omitted.

> 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 an…

I consider your argument misinformed. Technology moves fast. Very fast. If a piece of tech gets old enough to be called a dinosaur, and is still run at brand-new companies, it's doing something right, even if it's not for your usecase. And the fact is, not all of us have 3-5TB time seriesdatabases. And time series data can cause a lot of DBs to choke. The point is, I'm glad Cassandra and Hbase, or a dedicated TSDB, o…

Clearly the relational databases are very good and very useful in more cases than time series. However timeseries is huge, and growing - it's not a niche case anymore. Anyhow my beef was with the assertion that the 4 relational databases listed were the "only serious ones". This is completely untrue.

Re: Why we lost Uber as a user

#282

Earlier quoted context omitted.

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

I can tell you it doesn't work very well for wrapping remote postgres tables... it doesn't even send the where clause to the remote server, instead does a table scan across the network and matches locally.

Depends which Postgres version you are using: 9.1 added read only FDW support, 9.3 made it writable, 9.5 also has join pushdown into remote table.

Obviously, a lot depends on the FDW extension you are using - it doesn't help if there is support in postgres, if your specific extension does not utilize it.

Re: Why we lost Uber as a user

#283
post #180

Earlier quoted context omitted.

> 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 an…

There are column-oriented relational databases for that. DB2 and SQL Server both implement columnar systems for OLAP-esque workloads pretty well, and I think Oracle has something like that as well. In the Free software space, MonetDB is pretty good and I believe there's some Postgres extension to store data column-wise (which is probably not competitive with ground-up column stores like MonetDB, but beats row-wise st…

who said they were an alternative to relational databases? The problem with the post was not that the 4 mentioned were bad, only that they were the "only four worth using" which is an eye-rollingly ridiculous statement. Anybody who asserts that relational databases are the only serious databases is plain wrong, or has an ulterior motive. And this is not for "web scale bullshit" by the way. It is about large amounts of financial timeseries ingest for machine learning optimizations that I can promise you, has nothing to do with the web.

Re: Why we lost Uber as a user

#284

Earlier quoted context omitted.

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

You can't configure MySQL to not do "any" of that. You can certainly make it better, but there simply aren't options to configure away all of the boneheadedness. There are also tons of hidden gotchas that exist in, for example, the query planner. It can be extremely fickle and suddenly switch from a performant query plan to a terrible one that creates unindexed temporary tables and sorts them or joins against them. O…

You can add in checks at the application level - like you would need to with a number of NoSQl databases anyway.

Re: Why we lost Uber as a user

#285

Earlier quoted context omitted.

I consider your argument misinformed. Technology moves fast. Very fast. If a piece of tech gets old enough to be called a dinosaur, and is still run at brand-new companies, it's doing something right, even if it's not for your usecase. And the fact is, not all of us have 3-5TB time seriesdatabases. And time series data can cause a lot of DBs to choke. The point is, I'm glad Cassandra and Hbase, or a dedicated TSDB, o…

Clearly the relational databases are very good and very useful in more cases than time series. However timeseries is huge, and growing - it's not a niche case anymore. Anyhow my beef was with the assertion that the 4 relational databases listed were the "only serious ones". This is completely untrue.

You may have missed the line "In that case" :-)

Re: Why we lost Uber as a user

#286

Earlier quoted context omitted.

True, they're admitting there's a problem (which exists for this very specific user case) and not just deflecting the criticism. I'm impressed, I'd say a lot of projects couldn't have handled this so nicely

They're trying to "Do One Thing And Do It Well". It's always interesting how core UNIX philosophy often gets lost in Startup Culture's rush to "Disrupt The World".

How does adding support for JSON types work with the Unix idea?

Re: Why we lost Uber as a user

#287
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…

It is like saying I would not invest in Facebook as it is using PHP.

Re: Why we lost Uber as a user

#288

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.

I agree, I opened that link expecting a "you're doing it wrong" style post. I was pleasantly by what I saw

Re: Why we lost Uber as a user

#289
post #139

Earlier quoted context omitted.

> Uber switching to MySQL over Postgre is rather scary, I wouldn't want to be a Uber investor right now. I guess you wouldn't have wanted to be a GOOG investor either? Most of their early revenue was from AdWords on MySQL.

I actually know engineers who work for Google for that. Google maintains their own MySQL fork internally and also know exactly how MySQL fucks up and has planned for MySQL failure in depth. Google is maybe the only company I trust to know what they're doing when it comes to databases.

What about facebook? As I'm sure I've read they've forked MySQL too

Re: Why we lost Uber as a user

#290

Earlier quoted context omitted.

Clearly the relational databases are very good and very useful in more cases than time series. However timeseries is huge, and growing - it's not a niche case anymore. Anyhow my beef was with the assertion that the 4 relational databases listed were the "only serious ones". This is completely untrue.

You may have missed the line "In that case" :-)

[deleted]
Post reply on HN