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

171–180 of 310 posts

Re: Why we lost Uber as a user

#171

Post by Grishnakh »

Roboprog wrote: post #152
vegabook wrote: post #102

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…

Suggested edit: s/This is total bullshit/Perhaps you overlooked something:/. Otherwise, this would have been a good comment, I think.

This is one thing I like about HN's system: it lets me edit posts for a limited period. I'll sometimes bang out a post like the above, with a rather negative opening line like that and hit "submit". Then a minute later I'll realize I need to tone that down some, so I'll go edit it, as you suggest here. Unfortunately some shitty web forums don't allow you to edit posts at all, but I do appreciate ones which do allow editing stuff like this before anyone has a chance to read it.

Re: Why we lost Uber as a user

#172

Post by Grishnakh »

kirubakaran wrote: post #161
enave wrote: post #147

Earlier quoted context omitted.

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

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

Re: Why we lost Uber as a user

#173

Post by craigkerstiens »

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

A small bit of history from Tom Lane one of the biggest contributors to the project "Arguably, the 1996 decision to call it PostgreSQL instead of reverting to plain Postgres was the single worst mistake this project ever made."

- https://www.postgresql.org/message-id/2693.1152762174@sss.pg...

Re: Why we lost Uber as a user

#174

Post by Jweb_Guru »

geophile wrote: post #118

Question about Postgres architecture: Why were secondary indexes designed to refer to ctids instead of primary keys?

Among other things, there's a substantial performance penalty for secondary index lookups with clustered indices (since they need to traverse two index structures).

Re: Why we lost Uber as a user

#176

Post by bsaul »

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.

Completely agreee. Highly mutable => in memory ( then add a secondary stream for colder storage backups just in case).

A relational db is originaly meant for fetching data from a slow storage to a fast one, and the other way around, in a smart way. Doing it 500 times a second isn't a scenario for any db.

Build your own in memory data + process tructure, maybe using something like and agent network and using eg akka or erlang for failovers.

I'm curious as to why uber had to rely on a relational db for this case...

Re: Why we lost Uber as a user

#177

Post by qopp »

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.

Just to keep it in memory? Postgres does this already-- it will put tables or parts of tables in memory to speed up reads [1].

[1] Source: https://momjian.us/main/writings/pgsql/hw_performance/

Re: Why we lost Uber as a user

#178

Post by brohee »

bluejekyll wrote: post #104
oneloop wrote: post #20

Earlier quoted context omitted.

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?

DB exist on more than servers, e.g. in an embedded environment... You find sqlite in the oddest places... One could imagine finding mongodb there too, with bonus data corruption...

Re: Why we lost Uber as a user

#180

Post by PeCaN »

vegabook wrote: post #102
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…

> 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 storage for certain workloads).

You don't need to give up proven relational databases for this web-scale bullshit. Financial companies have been doing hundreds of times “modern use cases where you are ingesting fast” for decades. KDB+ is the darling of that industry, but DB2 is pretty popular (IIRC) as well as some other niche options.

Right tool for the right job, basically. I have nothing against Cassandra or HBase, and they're both quite impressive pieces of engineering. But they're not an alternative to relational databases; rather, a complement for very niche use-cases. I see NoSQL stuff get used for “performance and scalability” in places where a columnar relational DB would scale just fine and bring the benefits of a relational database. I'm all for HBase for non-relational use-cases, but those are rather more rare than people seem to think (and end up with an ad hoc relational model because of it).

Post reply on HN