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…
Why we lost Uber as a user
281–290 of 310 posts
Re: Why we lost Uber as a user
#282Earlier 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.
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
#283Earlier 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…
Re: Why we lost Uber as a user
#284Earlier 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…
Re: Why we lost Uber as a user
#285Earlier 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.
Re: Why we lost Uber as a user
#286Earlier 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".
Re: Why we lost Uber as a user
#287Earlier 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…
Re: Why we lost Uber as a user
#288The 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.
Re: Why we lost Uber as a user
#289Earlier 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.
Re: Why we lost Uber as a user
#290Earlier 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" :-)