Anmerkungen zu ACID, BASE, CAP – und Google Spanner
Werbung
FACHARTIKEL 2014 Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Unsere Fachartikel online auf www.norcom.de Copyright © 2014 NorCom Information Technology AG. Our Customers Come First. Anmerkungen zu ACID, BASE, CAP – und Google Spanner In diesem Artikel möchte ich, ein paar Erläuterungen zum Verständnis der drei genannten Akronyme formulieren, und dann eine grobe Einteilung von aktuellen Entwicklungen in der Datenbanktechnologie in die gegebenen Kategorien dieser Terminologien vornehmen. ACID (deutsch AKID) steht für Atomicity, Consistency, Isolation und Durability (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) – seit über 30 Jahren wichtige Eigenschaften für die Zuverlässigkeit von Datenbanksystemen. Jeder Verarbeitungsschritt in einem DBMS und vor allem auch in einem verteilten Datensystem wird daran gemessen, ob er die genannten vier Kriterien erfüllt. Das Akronym ACID zur Charakterisierung von Transaktionen wurde bereits 1983 in einem Paper1 von Theo Härder und Andreas Reuter geprägt. A wie Atomarität Atomarität (Abgeschlossenheit) bedeutet, dass eine Sequenz von DatenOperationen entweder ganz oder gar nicht ausgeführt wird – was normalerweise über den Einsatz von Transaktionen erreicht wird. Das Datenbanksystem verhält sich gegenüber dem Benutzer so, als ob die, in einer Transaktion zusammengefassten Operationen eine einzelne elementare Operation wäre, die nicht von anderen Operationen unterbrochen werden kann. De facto werden die einzelnen Anweisungen einer Transaktion nacheinander ausgeführt, aber erst für gültig erklärt (über einen so genannten Commit), wenn sie erfolgreich abgeschlossen sind. Andernfalls wird die gesamte Transaktion zurück abgewickelt, so dass der konsistente Ausgangszustand wiederhergestellt wird (Rollback). C wie Konsistenz Konsistenz heißt in diesem Zusammenhang, dass eine Sequenz von DatenOperationen einen konsistenten Datenzustand hinterlässt, falls die Datenbank davor konsistent war. In klassischen, relationalen DBMS wie Oracle, Informix, DB2 oder MS SQL Server versteht man unter Konsistenz die Integrität von Daten. Diese wird durch das Aufstellen von sogenannten Integritätsbedingungen2 (oft auch Constraints genannt) definiert - und davon gibt es vier Arten: 1 Siehe weiterführende Links auf Seite 8 2 Bedingungen, die bestimmte Datenobjekte erfüllen müssen, um als konsistent zu gelten, beispielsweise bestimmte Datentypen, Wertebereiche oder Abhängigkeitsbeziehungen zu anderen Objekten. Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 2 Seite 2 Our Customers Come First. Bereichsintegrität: Der Wert jedes Attributes muss in einem bestimmten Wertebereich liegen. Entitätsintegrität: Jeder Primärschlüssel muss eindeutig und darf auf keinen Fall Null sein. Referentielle Integrität: Der Wert eines Fremdschlüssel muss entweder Null sein, oder ein Objekt mit diesem Schlüssel muss existieren. Logische Konsistenz: Zusätzliche, logische Integritätsbestimmungen, die durch die Anwendung festgelegt werden. Konkret werden in relationalen Datenbanken mindestens folgende Constraints angeboten: NOT NULL → der Skalar kann nicht NULL sein PRIMARY KEY → der Skalar muss einzigartig sein und kann nicht NULL sein FOREIGN KEY → der Skalar muss auf Referentielle Integrität geprüft werden UNIQUE → der Skalar muss innerhalb des Attributes einzigartig sein CHECK()→ explizite Überprüfungsanweisung an das DBMS; auf was geprüft werden muss, wird als Option dieser Anweisung definiert Des Weiteren gibt es verschiedene Typen von Constraints: Attribut Constraints, beziehen sich auf eine einzelne Spalte Relationen Constraints, beziehen sich auf mehrere Attribute (Spalten) Benannte Constraints, können anhand des Namens manipuliert werden Unbenannte Constraints, erhalten einen vom System generierten Namen Eine Datenbank ist konsistent, wenn sie alle Integritätsbestimmungen erfüllt. Falls mindestens eine Integritätsbedingung verletzt wird, wird sie als nicht konsistent bezeichnet. In der Praxis wird die Konsistenz durch eine Normalisierung des Datenbestands sowie durch explizit definierte Integritätsbedingungen erreicht. Nach jeder durch eine Transaktion gegebenen Reihe von Veränderungen der Daten (Einfügen, Löschen oder Ändern) wird die Datenbank auf die festgelegten Integritätsbedingungen geprüft. Falls diese nicht erfüllt sein sollten, wird ein Rollback durchgeführt. In verteilten Speichersystemen werden Daten mehrfach über verschiedene Server repliziert, um die Verfügbarkeit der Daten zu erhöhen und die Zugriffzeiten zu verringern. In diesem Kontext bedeutet Konsistenz, dass alle Replika eines Datensatzes identisch sind. Insbesondere bedeutete dies aber auch, dass ein verteiltes Speichersystem für einen Datensatz A konsistent und gleichzeitig für einen Datensatz B inkonsistent sein kann. Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 3 Seite 2 Our Customers Come First. Seite 4 Seite 2 Nun fordert strikte Konsistenz, dass alle Replika immer identisch sind – und das ist in verteilten Systemen nicht immer sinnvoll – bzw. mit vertretbarem Aufwand – realisierbar, und erfahrungsgemäß oft nur auf Kosten der Verfügbarkeit, Performanz oder Ausfallsicherheit. In diesem Zusammenhang gilt das sogenannte CAP-Theorem3 von Eric Brewer, welches besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig die drei Eigenschaften Konsistenz (C), Verfügbarkeit (A) und Partitionstoleranz (P) zu garantieren4. C A P Unter Verfügbarkeit wird dabei die Forderung verstanden, dass immer alle Anfragen beantwortet werden, und als Partitionstoleranz die Forderung, dass das System auch bei Verlust von Nachrichten oder Ausfall einzelner Netzknoten oder Partitionen des Netzes möglichst fehlerfrei weiterarbeitet. In modernen hochverteilten und hochverfügbaren Systemen wird das CAP Theorem oft als Begründung für schwächere Konsistenzmodelle herangezogen. Bei solchen Systemen spricht man von einer schwachen (weak) Konsistenz, wenn keine Konsistenzgarantien abgegeben werden, oder von der sogenannten eventual Consistency - auch BASE (Basically Available, Soft state, Eventual consistency). BASE ist als Alternative zu ACID gedacht - ACID ist pessimistisch und erwartet Konsistenz am Ende jeder Operation während BASE optimistisch ist - und in Kauf nimmt, dass die Konsistenz der Datenbank in einem fließenden Status ist – weil davon auszugehen ist, dass es immer eine Zeit lang dauert, bis eine Änderung über alle Replikate im Netz verteilt ist. Eventuell – wenn dafür eine hinreichend lange Zeit ohne weitere Schreibzugriffe oder Fehler zur Verfügung steht - werden alle Änderungen auf allen Maschinen propagiert – daher die Bezeichnung »Eventual Consistency«. Zwischen eventual und strict Consistency gibt es einige Zwischenstufen - dabei unterscheidet man zwischen client-centric (d.h. aus Sicht des Clients) und data-centric (d.h. interne) Konsistenz. 3 Das Theorem entstand im Jahr 2000 als Vermutung des Informatikers Eric Brewer an der University of California, Berkeley beim »Symposium on Principles of Distributed Computing« (PODC). 2002 veröffentlichten Seth Gilbert und Nancy Lynch vom MIT einen axiomatischen Beweis von Brewers Vermutung und etablierten diese somit als Theorem. 4 Im Original: “It is impossible for a protocol to guarantee both consistency and availability in a partition prone distributed system”. Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Our Customers Come First. Client-centric Consistency Monotonic Read Consistency: Wenn ein Speichersystem einmal auf eine Leseanfrage eines Clients für einen bestimmten Schlüssel mit Version N geantwortet hat, werden alle späteren Lesezugriffe dieses Clients nur noch Versionen, die mindestens so neu sind wie N zurückliefern. Monotonic Write Consistency: Wenn ein Client für einen bestimmten Schlüssel erst Wert 1 und dann Wert 2 schreibt, dann ist garantiert, dass das System intern die Werte ebenfalls in dieser Reihenfolge schreibt. Read Your Writes Consistency: Das Speichersystem garantiert, dass ein Prozess, der ein Datum mit der Versionsnummer N geschrieben hat, garantiert keine Versionen lesen wird, die älter sind als N. In der Praxis wird dies oft durch sogenannte Session Consistency umgesetzt, bei der die Garantie nur für die Dauer einer Session gilt. Alle Anfragen eines bestimmten Prozesses werden zum selben Replika geroutet, ist dieses nicht verfügbar, wird die Session beendet. Write Follows Reads Consistency: Wenn ein Prozess ein Datum X in einer Version N gelesen hat und anschließend derselbe Prozess dieses Datum überschreibt, dann wird garantiert, dass der Schreibvorgang nur auf Replika stattfindet, die mindestens in Version N vorliegen. Data-centric Consistency Causal Consistency bedeutet, dass alle Operationen, die in einer kausalen Beziehung stehen, in der gleichen Reihenfolge auf allen Replika serialisiert werden müssen. Eine Operation O ist genau dann kausal von einer Operation P abhängig, wenn eine oder mehrere der folgenden Bedingungen gelten: O und P wurden vom gleichen Prozess ausgelöst und P lag chronologisch vor O. O ist ein Read, P ist ein Write und O hat das Ergebnis von P gelesen. O ist kausal abhängig von einer Operation X, die wiederum kausal abhängig von P ist. Sequential Consistency fordert, dass alle Operationen in der gleichen Reihenfolge auf allen Replika serialisiert werden und die Operationen jedes Clientprozesses in ihrer korrekten chronologischen Reihenfolge ausgeführt werden – und ist damit strikter als Causal Consistency. Linearizability ist noch strikter als Sequential Consistency - und bedeutet, dass die Ordnung der Operationen der tatsächlichen chronologischen Reihenfolge entspricht und alle Requests so erscheinen, als würden sie an einem Zeitpunkt passieren. Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 5 Seite 2 Our Customers Come First. I wie Isolation Isolation bezeichnet die Trennung von Transaktionen, so dass eine laufende Transaktion nicht von einer parallel ablaufenden Transaktion durch Änderungen an den gemeinsam benutzten Daten in einen undefinierten Zustand gebracht werden kann. Von den vier ACID-Eigenschaften ist diese in der Umsetzung die schwierigste. Durch mangelnde Transaktionsisolation können folgenden Probleme auftreten: 1. Lost Updates: Wenn zwei Transaktionen dieselbe Information verändern, dann können die Änderungen der ersten durch die Änderungen der zweiten überschrieben werden, wodurch die erste Änderung verloren geht. 2. Dirty Read: Wenn eine Transaktion Daten liest, die von einer noch nicht abgeschlossenen (Committed) Transaktion verändert wurden. 3. Non-Repeatable Read: Wiederholte Lesevorgänge auf denselben Datensatz innerhalb einer Transaktion liefern unterschiedliche Ergebnisse, weil zwischenzeitlich eine parallel ablaufende Transaktion den Datensatz verändert hat. 4. Phantom Read: Suchkriterien treffen während einer Transaktion auf unterschiedliche Datensätze zu, weil eine parallel laufende andere Transaktion Datensätze hinzugefügt, entfernt oder verändert hat. Im ANSI/ISO SQL-Standard, der von den relationalen DBMS wie Oracle, Informix, DB2 oder MS SQL Server weitgehend implementiert wurde, sind dafür vier Transaktionsisolationsebenen vorgesehen: 1. Read Uncommitted: Leseoperationen ignorieren jegliche Sperre, daher können alle oben genannten Probleme auftreten. 2. Read Committed: Schreibsperren werden für die gesamte Transaktion auf alle Objekte gesetzt, die verändert werden sollen. Lesesperren werden nur kurzzeitig beim tatsächlichen Lesen der Daten gesetzt. Daher können NonRepeatable Read und Phantom Read auftreten 3. Repeatable Read stellt sicher, dass wiederholte Leseoperationen mit den gleichen Parametern auch dieselben Ergebnisse haben. Sowohl bei Lese- als auch bei Schreiboperationen werden für die gesamte Dauer der Transaktion Sperren gesetzt. Damit können höchstens noch Phantom Reads auftreten. 4. Serializable garantiert, dass die Wirkung parallel ablaufender Transaktionen exakt dieselbe ist wie sie die entsprechenden Transaktionen zeigen würden, liefen sie nacheinander in Folge ab. Auf diese Weise ist sichergestellt, dass keine Transaktion verloren geht und dass sich keine zwei Transaktionen gegenseitig beeinflussen. Um ein möglichst hohes Niveau der Isolation zu gewährleisten, werden in DBMS komplexe Sperrmechanismen wie das 2PL (Two Phase Locking) oder dar sogenannte MVCC (Multiversion Concurrency Control) implementiert was allerdings zu Verlusten bei der Parallelität führen kann. Letztendlich liegt es oft an der Anwendung, mit möglichen Serialisierungsfehlern umzugehen und ggf. abgebrochene Transaktionen zu wiederholen. Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 6 Seite 2 Our Customers Come First. D wie Dauerhaftigkeit Dauerhaftigkeit sagt aus, dass die Daten nach dem erfolgreichen Abschluss einer Transaktion garantiert dauerhaft in der Datenbank gespeichert sind. Dieses muss auch nach einem Systemfehler wie einem Software-Fehler oder einem Hardware-Ausfall garantiert sein. Insbesondere darf es nach einem Ausfall des Hauptspeichers nicht zu Datenverlusten kommen. Dauerhaftigkeit kann durch das Schreiben eines Transaktionslogs in einem persistenten Speicher sichergestellt werden. Ein Transaktionslog erlaubt es, nach einem Systemausfall alle in der Datenbank fehlenden Schreib-Operationen zu reproduzieren. Klassifizierung von Datenbanktechnologien gemäß CAP CA – RDBMS: Die klassischen Relationalen Datenbanken wie Oracle, DB2 oder Microsoft SQL Server streben vor allem Konsistenz an. Ein RDBMSCluster fällt ebenfalls meistens in die Kategorie CA. Sie streben vor allem Verfügbarkeit und Konsistenz aller Knoten an. Da sie meistens mit hochverfügbaren Netzwerken und Servern betrieben werden, ist das Thema Partitionstoleranz meist eher etwas nachrangiger. CP – Banking-Anwendungen: Für verteilte Finanzanwendung wie z. B. Geldautomaten ist die Konsistenz der Daten oberstes Gebot: Ein abgehobener Geldbetrag muss zuverlässig vom Konto abgebucht werden, eingezahltes Geld muss auf dem Konto erscheinen. Diese Anforderung muss auch bei Störungen im Datenverkehr sichergestellt werden (Partitionstoleranz). Die Verfügbarkeit ist in diesem Fall eher zweitrangig, so soll bei Netzwerkstörungen ein Geldautomat eher nicht verfügbar sein als fehlerhafte Transaktionen abzuwickeln. AP – DNS und Cloud Systeme sowie verteilte NoSQL-Datenbanken. Das DNS fällt in die Kategorie AP. Die Verfügbarkeit ist extrem hoch, ebenso Toleranz gegenüber dem Ausfall einzelner DNS-Server. Allerdings ist die Konsistenz nicht immer sofort gegeben: es kann mitunter Tage dauern, bis ein geänderter DNS-Eintrag an die gesamte DNS-Hierarchie propagiert ist und damit von allen Clients gesehen wird. Cloud-Plattformen setzen auf eine horizontale Skalierung, die Last wird auf viele Knoten verteilt, die ggf. auf preiswerter, nicht unbedingt ausfallsicherer Hardware laufen. Daher muss eine CloudAnwendung zwingend Toleranz gegenüber dem Ausfall einzelner Knoten zeigen können. Ebenso wird normalerweise eine hohe Verfügbarkeit gefordert. Beispiele für Web-Anwendungen, die nicht auf strenge Konsistenz angewiesen sind, wären Social-Media-Sites wie Twitter oder Facebook. Die meisten aktuellen NoSQL Datenbanksysteme stellen ebenfalls einen oder zwei der drei Faktoren über den oder die anderen: Google BigTable, die proprietäre Hochleistungsdatenbank auf Basis des Google File Systems (GFS) sowie HBase, die freie Implementierung von BigTable aus dem Apache Hadoop Projekt garantieren strikte Konsistenz innerhalb eines Datacenters und höchste Verfügbarkeit, Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 7 Seite 2 Our Customers Come First. Inkonsistenzen zwischen Datacentern sind aber möglich. Updates werden asynchron an alle Replikate verteilt. Amazon DynamoDB und Apache Cassandra stellen ebenfalls die Verfügbarkeit und Partitionstoleranz über die Konsistenz – auch hier werden Updates asynchron an alle Replikate verteilt. Oracle NoSQL erlaubt die Konfiguration eines strikteren Konsistenzmodells ggf. auf Kosten der Performance. FoundationDB – die NoSQL-Datenbank soll in der aktuellen Version ACID konform sein. Google Spanner, der Nachfolger von BigTable, der bei Google bereits seit 4 Jahren im Einsatz ist, soll als global verteilte und synchron replizierende Datenbank erstmals eine strikte Konsistenz bieten. Fazit Es ist naheliegend, dass strikte Konsistenzforderungen wie sie in ACID formuliert sind, Opfer bei der Verfügbarkeit und Performance von verteilten Systemen fordern - und auch, dass hohe Anforderungen an die Verfügbarkeit und Performanz wie sie in weltweit verteilten Systemen gängig sind und mit dem BASE Paradigma umgesetzt werden, Opfer bei der Konsistenz fordern - das ist mit CAP vermutet und bewiesen worden. Mit der neuen globalen Spanner Datenbank hat sich nun Google aber vorgenommen, zu zeigen, dass C, A und P vielleicht doch gleichzeitig erfüllt werden können – zumindest besser als je zuvor… Prof. Eric Brewer muss es wissen – er arbeitet für Google. Bereits am 10.05.2011 hat er bei Twitter gepostet: I will be leading the design of the next gen of infrastructure at Google. The cloud is young: much to do, many left to reach. Wir dürfen gespannt bleiben… Weiterführende Links ACID Paper von 1983: http://www.minet.uni-jena.de/dbis/lehre/ws2005/dbs1/HaerderReuter83.pdf Beweis des CAP Theorems: http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf Google BigTable: http://static.googleusercontent.com/media/research.google.com/de//archive/bi gtable-osdi06.pdf Apache HBase: http://hbase.apache.org/ Amazon DynamoDB: http://aws.amazon.com/de/dynamodb/ Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Seite 8 Seite 2 Our Customers Come First. Seite 9 Seite 2 Apache Cassandra: http://cassandra.apache.org/ Oracle NoSQL: http://www.oracle.com/de/products/database/nosql/overview/index.html FoundationDB: https://foundationdb.com/acid-claims Google Spanner: http://static.googleusercontent.com/media/research.google.com/de//archive/sp anner-osdi2012.pdf Haben Sie Fragen, Kommentare oder Feedback? Unsere Experten sind rund um die Uhr für Sie da. Fragen Anmerkungen zu ACID, BASE, CAP – und Google Spanner Von Gunther Zerbes Sie uns jetzt!
