Textprobe: Kapitel 2.2, Brewer's Theorem und 'letztendliche Konsistenz': Letztendliche Konsistenz ist dann von großer Bedeutung, wenn ein hochverfügbarer Datenbankservice bereitgestellt werden soll. Wenn die Daten in einem verteilten System redundant gespeichert sind und es eine Verzögerung bei der asynchronen Replikation gibt, dann ist es möglich, dass eine Anfrage an eine dieser Replikationen einen nicht aktuellen Wert zurückliefert. Welche Chancen und Risiken bietet letztendliche Konsistenz bei genau diesem Szenario? Wenn ein System starke Konsistenz unterstützt, dann wird der geschriebene Wert garantiert zurückgegeben. Bei einer schwachen Konsistenz wird dies nicht garantiert. Dann ist es nicht vorhersehbar, wann eindeutig der veränderte Wert von jedem Knoten ausgegeben wird. 'Die letztendliche Konsistenz ist eine Form von schwacher Konsistenz, bei welcher das Datenbanksystem garantiert, dass, wenn keine weiteren Veränderungen an dem Objekt vorgenommen werden, das System letztendlich und von jeder Serverinstanz den richtigen Wert zurückgibt.' Wenn kein Fehler auftritt kann die Zeit, bis das System einen konsistenten Zustand erreicht hat, bestimmt werden. Das erfolgt anhand Eigenschaften wie Kommunikationsverzögerungen, Systemlast und Anzahl der Serverinstanzen. Eines der berühmtesten Systeme dieser Art ist z.B. das Domain Name System (DNS). Welche Möglichkeiten existieren, um mit inkonsistenten Verhalten umzugehen? Wenn ein Algorithmus einen Wert schreibt, dann muss es Möglich sein, dass dieser Prozess auch den veränderten Wert wieder zurückgibt und niemals den alten ('lies-was-du-schreibst (RYW-)Konsistenz'. In Kapitel 3.4 wird die RYW-Konsistenz näher beschrieben. Praktisch kann dies mit 'Session-Konsistenz' umgesetzt werden. Ein Prozess greift innerhalb einer Sitzung auf die Datenbank zu. Solange die Sitzung existiert, wird die 'RYW-Konsistenz' garantiert. Wenn diese Sitzung aufgrund eines Fehlers terminiert, dann wird eine neue Sitzung eröffnet, welche keine Überlappungen mit anderen Sitzungen garantiert. Durch eine Versionierung der Datensätze ist eine 'Monotonic read consistency' gleichbleibende Lese-Konsistenz) möglich, hierbei gibt ein Prozess immer die letzte Version eines Wertes zurück, niemals einen älteren. Bei einer gleichbleibenden Schreib-Konsistenz 'Monotonic write consistency' wird garantiert, dass ein Prozess, welcher eine Serialisierung vornehmen soll, diese auch eigenständig durchführt und kein anderer. 'Viele dieser Eigenschaften können kombiniert werden, z.B. 'gleichbleibende Lese- mit sitzungsbasierter Konsistenz'. Aus praktischer Sicht sind 'gleichbleibende-Lese-Konsistenz' und 'RYW Konsistenz' die wichtigsten Vertreter in einem 'letztendliche Konsistenz'-System.'. Diese zwei Prinzipien machen es für Entwickler einfacher, Applikationen zu entwickeln. Die Datenbank kann ihre Konsistenz aufweichen und hohe Verfügbarkeit bieten. Es gibt viele verschiedene Szenarios und Kombinationen, die auf unterschiedliche Anwendungen zugeschnitten sein können. An Kompromissen führt jedoch kein Weg vorbei. Inkonsistenz muss bei verteilten Systemen akzeptiert werden. Die Lese- und Schreibgeschwindigkeit ist unter hoch konkurrierenden Bedingungen, zu langsam. Partitionstoleranz kann aufgrund der Fehlertoleranz entscheidend dazu beitragen. Ob diese Kompromisse gemacht werden können, hängt stark von der jeweiligen Applikation ab. In jedem Fall muss sich der Entwickler darüber im Klaren sein, dass diese Konsistenzansprüche von der Datenbank ausgehen und diese bei einer Entwicklung beachten. 'Verbesserungen wie 'sitzungsbasierende Konsistenz' oder 'gleichbleibende Lese-Konsistenz' geben dem Entwickler bessere Werkzeuge, um mit 'letztendlicher Konsistenz' zu arbeiten.' Ein bestimmter Fall beschreibt eine Webseite, bei der die Absicht besteht, dem Benutzer eine von ihm akzeptierte Konsistenz zu gewährleisten. Dabei muss das 'inkonsistente Zeitfenster' kleiner sein als das zu erwartende 'Neuladen' der Seite sein. Dabei kann eine Konsistenz hergestellt werden, bevor ein neuer Lesezugriff höchstwahrscheinlich erfolgt. Wenn z.B. ein Facebookbenutzer eine Nachricht an jemand schreibt, dann kann die Nachricht im 'Browser-Speicher' (Javascript) zwischengespeichert werden, bis diese Nachricht in der Datenbank persistent gemacht wurde. Die gesendete Nachricht erscheint vorrübergehend im Postausgang, doch ist sie noch nicht 'gespeichert' und an den Empfänger übermittelt. Die kurze Zeitspanne erlaubt es der asynchronen Verteilung dem Benutzer ein jederzeit konsistenten Service zu simulieren, bis die Speicherung in einem 'letztendliche Konsistenz System' wirklich erfolgt ist. Der Web-Service einer Bank, um z.B. Überweisungstransaktionen durchzuführen, benötigt eine starke Konsistenz. Angenommen es befindet sich eine relationale Datenbank auf dem Server, 'dann verbringt die Datenbank mehr Zeit damit zu entscheiden, auf welchen Server geschrieben werden soll und in welcher Reihenfolge der Bearbeitungsprozess stattfindet als mit dem eigentlichen Schreibprozess.' Der Service in einem verteilten System ist dann nicht verfügbar. Dieser Kompromiss muss für diese Art von Web-Service akzeptiert werden. Ein Webshop führt keine Geldtransfers durch, der Kompromiss, die 'Verfügbarkeit einzuschränken', kann nicht gemacht werden, denn in der Zeit können andere Kunden keine Artikel bestellen. Bei einem hochfrequentierten Webshop entstehen sonst Umsatzeinbußen. 'Es wird akzeptiert, dass, wenn zwei Kunden denselben Artikel bestellen, einer davon eine nachträgliche Stornierung erhält.' Wenn z.B. zwei Kunden bei einem Webshop denselben Artikel bestellen und nur ein einziger verfügbar ist, dann bekommt der Käufer, der vielleicht nur eine Sekunde später auf 'Bestellen' geklickt hat eine Stornierung. Das ist ein Kompromiss um Verfügbarkeit gegenüber Konsistenz vorzuziehen. Vorsorglich kann die Lieferzeit verändert werden, wenn nur noch wenige Bestände von einem Artikel vorhanden sind. Wenn zwei Kunden sich gegenseitig 'kongruieren', dann freut sich der eine Kunde, weil er den Artikel sofort zugeschickt bekommt und der andere weiß von der langen Wartezeit im Voraus. Wenn die Zeitspanne, bis eine Konsistenz letztendlich wieder erreicht ist, gering bleibt, dann gehen viele diesen Kompromiss ein und akzeptieren eine vorübergehende Inkonsistenz. Amazon behauptet, dass 'nur eine Steigerung der Antwortlatenz um 0.1 einen Umsatzrückgang von 1% nach sich zieht'. Google sagt aus, dass 'eine Suchergebnisliste, welche nur 0.5 Sekunden zu spät ausgeliefert wird, einen Datendurchsatzrückgang von 0.2 % nach sich zieht.'