Re: Uber migrated from Postgres to MySQL

On 27 July 2016 at 17:11, Andrew Sullivan <ajs(at)crankycanuck(dot)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 <ajs(at)crankycanuck(dot)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
> ajs(at)crankycanuck(dot)ca
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>