CAP und PACELC als Entscheidungshilfen statt als Schlagworte

Worum es geht

CAP besagt, dass ein repliziertes System, während eine Netzwerkpartition seine Replikate trennt, nicht gleichzeitig jede Anfrage auf jeder Seite beantworten und jeden Lesevorgang konsistent mit jedem Schreibvorgang halten kann. Brewers Rückblick von 2012 (zitiert) hält fest, dass die Formulierung „2 von 3" irreführend war: CAP verbietet nur einen winzigen Teil des Entwurfsraums, nämlich perfekte Verfügbarkeit und Konsistenz bei Vorliegen von Partitionen, und da Partitionen selten sind, gibt es wenig Grund, bei gesundem Netzwerk auf eine der beiden Eigenschaften zu verzichten. Abadis PACELC (zitiert) ergänzt den Fall, der jeden Tag zählt: Liegt eine Partition vor (P), tauscht das System Verfügbarkeit gegen Konsistenz (A oder C); andernfalls (E), im Normalbetrieb, tauscht es Latenz gegen Konsistenz (L oder C). Kleppmanns Kritik (zitiert) untersucht die Mehrdeutigkeiten in CAPs Definitionen und warnt, dass es sorgfältigeres Nachdenken erfordert, CAP als Beweis dafür zu lesen, dass eventual-konsistente Datenbanken „verfügbarer" seien.

Warum es wichtig ist

Produktseiten etikettieren Systeme als „AP" oder „CP", als wäre das eine feste Eigenschaft. Die nützlichen Fragen sind pro Operation zu stellen: Was geschieht mit einem Schreibvorgang auf der Minderheitsseite einer Partition, wartet ein Commit auf entfernte Replikate, und welche Lesevorgänge müssen den jüngsten Schreibvorgang beobachten. Derselbe Store beantwortet dies je nach Konfiguration oft unterschiedlich (Quorum-Grössen, synchrone oder asynchrone Replikation, Konsistenzstufe pro Anfrage).

So wird es angewendet

• Operationen auflisten, die eine über die Replikate hinweg geltende Invariante benötigen (eindeutige Benutzernamen, Kontostände, die nicht negativ werden dürfen, „den eigenen Schreibvorgang lesen" nach dem Absenden eines Formulars). Diese benötigen Abstimmung; alles andere kann veraltete Daten für eine begrenzte Zeit tolerieren.
• Für jeden Store das dokumentierte Verhalten bei Partition ermitteln (was eine Minderheit tut, ob Schreibvorgänge abgelehnt oder akzeptiert und später abgeglichen werden) sowie im Normalbetrieb (worauf ein Commit wartet).
• Die Entscheidung in PACELC-Begriffen im Entscheidungsprotokoll festhalten: „PA/EL für den Aktivitäts-Feed, PC/EC für Zahlungen".
• Den Partitionsmodus explizit entwerfen: wie er erkannt wird, welche Operationen abgelehnt oder in eine Warteschlange gestellt werden, und wie der Zustand anschliessend abgeglichen wird. Brewers Artikel fasst dies als Planung für den Betrieb während einer Partition und die Wiederherstellung danach.
• Veraltung sichtbar machen: die Replikationsverzögerung als Kennzahl offenlegen und eine vom Produkt akzeptierte Obergrenze festlegen.

Stolpersteine

„CA" ist für nichts, was ein Netzwerk verwendet, eine Option. „Konsistenz" bedeutet in CAP Linearisierbarkeit, nicht das C in ACID. „Verfügbarkeit" in CAP bedeutet, dass jeder nicht ausgefallene Knoten antwortet, nicht eine Uptime-Prozentzahl. Eine Einzelknoten-Datenbank mit einem asynchronen Replikat steht bereits vor der PACELC-Wahl.