Why we lost Uber as a user
postgresql.org
Why we lost Uber as a user
1–10 of 310 posts
Re: Why we lost Uber as a user
#2I am guessing that VACUUM only kicks in for row deletions? With that busy a table, can't you just bypass VACUUM and reuse dead keys? I am assuming because you are talking indexes here, you are talking fixed length records and not dynamically allocated VARCHARs etc.??
Re: Why we lost Uber as a user
#3This only talks about a particular write amplification issue. A far better message IMO is just a few clicks upthread: https://www.postgresql.org/message-id/579795DF.10502%40comma...
Provides a link to the rationale post from uber (https://eng.uber.com/mysql-migration/), and a tl;dr of it. Prior discussion here: https://news.ycombinator.com/item?id=12166585
Re: Why we lost Uber as a user
#4Wow, 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.
Re: Why we lost Uber as a user
#5The original Uber blog post that led to the discussion - https://eng.uber.com/mysql-migration/
Re: Why we lost Uber as a user
#6The attitude with which the article is discussed in the mailing list is admirable.
Re: Why we lost Uber as a user
#7Wow, 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.
Re: Why we lost Uber as a user
#8This only talks about a particular write amplification issue. A far better message IMO is just a few clicks upthread: https://www.postgresql.org/message-id/579795DF.10502%40comma... Provides a link to the rationale post from uber ( https://eng.uber.com/mysql-migration/ ), and a tl;dr of it. Prior discussion here: https://news.ycombinator.com/item?id=12166585
It is nice to see that while the thread does question some of Uber's motivation for the change, where there is a genuine problem with their product there is a frank admission (with quotes like "this is a common problem case we don't have an answer for yet" and "limitations of our current replication system are real, or we wouldn't have so many people working on alternatives") which people discuss seriously (asking for clarification and/or suggesting ways forward) rather than reacting with a knee-jerk defensive posture.
Re: Why we lost Uber as a user
#9How well will INNODB scale for this particular use case? It seems that the architecture is a bit too reliant on the complex performance characteristics of one subsystem.
Re: Why we lost Uber as a user
#10Wow, 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.
> 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".