On 27 July 2016 at 17:11, Andrew Sullivan <a...@crankycanuck.ca> wrote:
> Given > the discussion in the post in question, the decision to use MySQL > appears to have been well-justified: > Well yes, but that's pretty-much the point of back-justification, isn't it? [snip a whole bunch of good points] > > For what it's worth, from what I've read uber are a company whose very > > business plan relies on them taking things that they don't deserve while > > they treat customers and employees with similar levels of arrogance. > > Nothin' for nothin', but I don't think it helps Postgres to attack > others' business plans -- whatever one thinks of them -- as part of an > argument about why Postgres is the right tool for a given job. > Oh, I wasn't using as an argument about anything (hence "for what it's worth"). G On 27 July 2016 at 17:11, Andrew Sullivan <a...@crankycanuck.ca> wrote: > On Wed, Jul 27, 2016 at 04:51:42PM +0100, Geoff Winkless wrote: > > technical reasons. Most developers will harp on at their boss about how > > terrible their current database is and how <preferred database> performs > > much better. Eventually one of two things happens: either a) those > > developers end up in a position where their direct boss is in a position > to > > make the change and he or she doesn't understand how much time and money > it > > will actually take to change; or b) commercial considerations dictate the > > change. > > In a different context, someone suggested to me that Postgres > advocates sounded to him too often like FreeBSD advocates complaining > about Linux, and I'm afraid there is a certain truth to that. Given > the discussion in the post in question, the decision to use MySQL > appears to have been well-justified: > > 1. They'd decided to use a NoSQL database and ditch relational > systems, because shards. > > 2. They wanted an MVCC engine behind the above. > > 3. They wanted SQL semantics to this MVCC-enabled filesystem layer. > > Sounds just like MySQL+InnoDB to me. Once you've already decided on > (1), the rest of it flows pretty naturally and Postgres is probably > not your choice. You can dismiss any of 1-3 as commerical or > political advocacy, but while I happen to think they're a somewhat > questionable set of goals they're not obviously stupid, and > competent people of good will could disagree about them. > > At the same time, there really are two serious problems with Postgres > under heavy write loads. Postgres's focus on readers' speed and > convenience means you have to take the hit somewhere, so writers take > it instead. (The other side of the disk-layout description in the > blog post is that, under MySQL, secondary index use is more expensive > for readers than it is in Postgres. The post acknowledges that, but > of course most important secondary indexing is useless under sharding > anyway, since you have to select from shards; so they won't care.) > I/O storms on Postgres are a major source of pain for large operators, > and the tools for understanding are sort of primitive because many of > them depend on underlying OS features and tools. > > The second is the upgrade-by-replica-and-fallback-plan problem. It's > really an issue. There is a reason that, back in the cloudy past, we > designed Slony to be able to replicate to and from any supported > version of Postgres: Afilias needed to be able to upgrade without a > lot of down time and with the ability to roll back if we had to, > because that was our contractual obligation. This has always been a > large gap, and when it was raised in the past the answer was, "Well, > Slony can already do that so use it." It wasn't too satisfying then, > and it's not much more satisfying now. :) > > > better invested in employing one of the commercial PG companies to > improve > > the specific postgres problems they found. > > I think the two big problems laid out above are deep architectural > ones. I'm not sure these are the sort of improvement you can buy > without getting the community on board. > > > For what it's worth, from what I've read uber are a company whose very > > business plan relies on them taking things that they don't deserve while > > they treat customers and employees with similar levels of arrogance. > > Nothin' for nothin', but I don't think it helps Postgres to attack > others' business plans -- whatever one thinks of them -- as part of an > argument about why Postgres is the right tool for a given job. > > Best regards, > > A > > -- > Andrew Sullivan > a...@crankycanuck.ca > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
