On Mon, Aug 1, 2016 at 12:49 PM, J. Roeleveld <jo...@antarean.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
