6 comments

  1. Wat ook belangrijk is om je te realiseren is dat het CAP-theorema uitgaat van een ge-isoleerd system zonder besef van tijd. Dat betekent dat door tijd of ander extern invloed toe te voegen door b.v. een gedistribueerde tijdklok zoals GPS in Google Spanner je voorbij het CAP-theorema kan gaan.

    Rolf Huisman

  2. Google Spanner lijkt me in de CP hoek te positioneren.

    Tim Mahy

  3. Eigenlijk moet je bij CAP niet alleen kijken wat er gebeurt als er partities optreden, maar ook hoe je zaken weer kunt consolideren tot 1 geheel als de partities weer wegvallen (en de verbinding dus weer terug is). Door het mechanisme wat Rolf noemt maak je het mogelijk om achteraf veel preciezer te reconstrueren wat de volgorde van updates was, waardoor je, ondanks het tijdelijk opgeven van een C, deze toch weer (grotendeels) terug kunt krijgen.
    Daarnaast moet je ook rekening houden met tijdsvertraging in verbindingen. Ook al is een gedistribueerd systeem connected, als je geen gebruik maakt van 2PC, dan heb je per definitie ingeboet op C, omdat er ook enige tijd zit tussen een mutatie op het “master” en het “slave” systeem.

    Raimond Brookman

    • Eigenlijk moet je bij CAP niet alleen kijken wat er gebeurt als er partities optreden, maar ook hoe je zaken weer kunt consolideren tot 1 geheel als de partities weer wegvallen (en de verbinding dus weer terug is). Door het mechanisme wat Rolf noemt maak je het mogelijk om achteraf veel preciezer te reconstrueren wat de volgorde van updates was, waardoor je, ondanks het tijdelijk opgeven van een C, deze toch weer (grotendeels) terug kunt krijgen.

      Zeer zeker. Dat is m.i. één van de belangrijkste punten om te overwegen wanneer je meer A wilt: uiteindelijk wil je ergens weer een bepaalde mate van C bereiken. Gedistribueerde timers kunnen daarbij helpen om de juiste volgorde de reconstrueren (en dus op het moment dat er geen partities meer zijn weer C te bereiken), maar je blijft inboeten op C.
      Een mooie oplossing die heel sterk voor AP gaat is een gedistribueerd versiebeheersysteem als Git. Door de keuze dat iedere deelnemende node een eigen repository heeft, is er nooit maximaal Consistency. Zelfs in een systeem dat zo sterk op AP gericht is, is er echter nog steeds een relatieve consistency binnen één tree wanneer er een push / pull wordt uitgevoerd. Die C kan echter soms pas bereikt worden na het oplossen van ‘Merge Conflicts’. ‘Merge Conflicts’ zijn de ultieme niet-C: twee hosts die elkaar tegenspreken. Deze kun je deels oplossen met behulp van gedistribueerde timers, maar niet helemaal: het feit dat je collega 10 minuten later dan jij een update heeft doorgevoerd in de code betekent niet dat dat de juiste of werkelijke waarde is.

      Daarnaast moet je ook rekening houden met tijdsvertraging in verbindingen. Ook al is een gedistribueerd systeem connected, als je geen gebruik maakt van 2PC, dan heb je per definitie ingeboet op C, omdat er ook enige tijd zit tussen een mutatie op het “master” en het “slave” systeem.

      Uiteraard moet je daar rekening mee houden. Dit is echter geen uitzonderingsgeval die buiten CAP omgaat: tijdsvertraging is een optredende partitie. Een master-slave-systeem waarbij de master updates blijft doorvoeren wanneer de slave deze nog niet bevestigd heeft heeft dus ingeboet op C ten behoeve van een klein beetje meer A en P.

      Dit raakt ook de kern van de post: in de praktijk zijn systemen niet zomaar te plaatsen op de ‘assen’ CA / AP / CP. C, A en P zijn geen discrete waarden die je zomaar op een product / oplossing kunt plakken: in de praktijk is er altijd sprake van een tradeoff bij de bouw van een systeem, waarbij de verschillende niveaus afgewogen worden (zoals in het master-slave-voorbeeld). Ook blijft het de vraag op welk niveau je deze uitspraken doet: over het hele systeem genomen is HDFS bijvoorbeeld redelijk sterk AC (want partities tussen namenode en datanodes kunnen gewoon niet bestaan), maar ingezoomd op federated namenodes schuift HDFS meer richting CP (federated namenodes verdelen de administratieve last, communiceren niet en werken onafhankelijk van elkaar. Het uitvallen van één van de federated nodes leidt altijd tot verlies van availability). Met name in de gesprekken rond NoSQL / Big Data systemen wordt hier echter nogal eens een rookgordijn gelegd in de vorm van extreme simplificaties (“Ja, maar Hadoop is AP, dus kan geen Consistency garanderen” of “Alle relationele databases zijn AC, dus zijn nooit partition tolerant”) of verkeerde uitleg (met name de P als zijnde ‘horizontale schaalbaarheid’ is een erg hardnekkige).

      Koos van Strien

Comments are closed.