Re: [gentoo-user] PostgreSQL Vs MySQL @Uber

[Rich Freeman]

On Mon, Aug 1, 2016 at 12:49 PM, J. Roeleveld <joost@××××××××.org> wrote:
> On Monday, August 01, 2016 08:43:49 AM james wrote:
>
>> Sure this part is only related to
>> transaction processing as there was much more to the "five 9s" legacy,
>> but imho, that is the heart of what was the precursor to ACID property's
>> now so greatly espoused in SQL codes that Douglas refers to.
>>
>> Do folks concur or disagree at this point?
>
> ACID is about data integrity. The "best 2 out of 3" voting was, in my opinion,
> a work-around for unreliable hardware. It is based on a clever idea, but when
> 2 computers having the same data and logic come up with 2 different answers, I
> wouldn't trust either of them.

I agree, this was a solution for hardware issues.  However, hardware
issues can STILL happen today, so there is an argument for it.  There
are really two ways to get to robustness: clever hardware, and clever
software.  The old way was to do it in hardware, the newer way is to
do it in software (see Google with their racks of cheap motherboards).
I suspect software will always be the better way, but you can't just
write a check to get better software the way you can with hardware.
Doing it right with software means hiring really good people, which is
something a LOT of companies don't want to do (well, they think
they're doing it, but they're not).

Basically I believe the concept with the mainframe was that you could
probably open the thing up, break one random board with a hammer, and
the application would still keep running just fine.  IBM would then
magically show up the next day and replace the board without anybody
doing anything.  All the hardware had redundancy, so you can run your
application for a decade or two without fear of a hardware failure.

However, you pay a small fortune for all of this.  The other trend as
I understand it in mainframes is renting your own hardware to you.
That is, you buy a box, and you can just pay to turn on extra
CPUs/etc.  You can imagine what the margins are like for that to be
practical, but for non-trendy businesses that don't want to offer free
ice cream and pay Silicon Valley wages I guess it is an alternative to
building good software.

>
> You have seen how "democracies" work, right? :)
> The more voters involved, the longer it takes for all the votes to be counted.
> With a small number, it might actually still scale, but when you pass a magic
> number (no clue what this would be), the counting time starts to exceed any
> time you might have gained by adding more voters.
>
> Also, this, to me, seems to counteract the whole reason for using clusters:
> Have different nodes handle a different part of the problem.

I agree.  The old mainframe way of doing things isn't going to make
anything faster.  I don't think it will necessarily make things much
slower as long as all the hardware is in the same box.  However, if
you want to start doing this at a cluster scale with offsite replicas
I imagine the latencies would kill just about anything.  That was one
of the arguments against the Postgres vacuum approach where replicas
could end up having in-use records deleted.  The solutions are to
delay the replicas (not great), or synchronize back to the master
(also not great).  The MySQL approach apparently lets all the replicas
do their own vacuuming, which does neatly solve that particular
problem (presumably at the cost of more work for the replicas, and of
course they're no longer binary replicas).

>
> The way Uber created the cluster is useful when having 1 node handle all the
> updates and multiple nodes providing read-only access while also providing
> failover functionality.

I agree.  I do remember listening to a Postgres talk by one of the
devs and while everybody's holy grail is the magical replica where you
just have a bunch of replicas and you do any operation on any replica
and everything is up to date, in reality that is almost impossible to
achieve with any solution.

-- 
Rich