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@xxxxxxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
