From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | pgwhatever <michael(at)sqlexec(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why we lost Uber as a user |
Date: | 2016-07-28 14:08:41 |
Message-ID: | CAHyXU0yF5+6yYZV5ne3vp5PUS3Nj6mOZoucZ+3PZLCj62xXbUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 28, 2016 at 8:16 AM, pgwhatever <michael(at)sqlexec(dot)com> wrote:
> Statement-Based replication has a lot of problems with it like indeterminate
> UDFs. Here is a link to see them all:
> https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html#replication-sbr-rbr-sbr-disadvantages
Sure. It's also incredibly efficient with respect to bandwidth -- so,
if you're application was engineered to work around those problems
it's a huge win. They could have used pgpool, but I guess the fix was
already in.
Taking a step back, from the outside, it looks like uber:
*) has a very thick middleware, very thin database with respect to
logic and complexity
*) has a very high priority on quick and cheap (in terms of bandwidth)
replication
*) has decided the database needs to be interchangeable
*) is not afraid to make weak or erroneous technical justifications as
a basis of stack selection (the futex vs ipc argument I felt was
particularly awful -- it ignored the fact we use spinlocks)
The very fact that they swapped it out so easily suggests that they
were not utilizing the database as they could have, and a different
technical team might have come to a different result. Postgres is a
very general system and rewards deep knowledge such that it can
outperform even specialty systems in the hands of a capable developer
(for example, myself). I'm just now hammering in the final coffin
nails that will get solr swapped out for jsonb backed postgres.
I guess it's fair to say that they felt mysql is closer to what they
felt a database should do out of the box. That's disappointing, but
life moves on. The takeaways are:
*) people like different choices of replication mechanics -- statement
level sucks a lot of the time, but not all the time
*) hs/sr simplicity of configuration and operation is a big issue.
it's continually gotten better and still needs to
*) bad QC can cost you customers. how much regression coverage do we
have of hs/sr?
*) postgres may not be the ideal choice for those who want a thin and
simple database
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-07-28 14:12:16 | Re: LWLocks in DSM memory |
Previous Message | Fujii Masao | 2016-07-28 14:04:49 | Re: pg_basebackup wish list |