NoSQL: Wie moderne Datenbanken arbeiten

Schwache Konsistenz aus Clientsicht

Allgemeine schwache Konsistenz garantiert nicht, dass ein erfolgreiches Update anschließend für alle Clients sichtbar ist. Eine besondere Form der schwachen Konsistenz ist die schlussendliche Konsistenz (Eventual Consistency). Hierbei garantiert das Speichersystem, dass nach einer gewissen Zeit ohne weitere Datenänderungen alle Replikate aktualisiert werden. Als Akronym für verteilte Speichersysteme mit schlussendlicher Konsistenz schlug Dan Pritchett BASE vor (Basically Available, Soft State, Eventually Consistent). BASE ist optimistisch. Die Daten können gleichzeitig auf verschiedenen Knoten geändert werden. Die Änderungen werden später konsolidiert. Datenbankkonsistenz ist für BASE kein fester Zustand am Ende einer Transaktion, sondern ein Zustand ständiger Veränderung. Bei BASE ist Verfügbarkeit das wichtigste Kriterium. Es gibt verschiedene Variationen der schlussendlichen Konsistenz, zum Beispiel monotone Lesekonsistenz (Monotonic Read Consistency). Wenn ein Client bei diesem Ansatz Daten liest, wird er später nie ältere Daten sehen. Andere Variationen sind zum Beispiel Read-Your-Writes-Konsistenz und Sessionkonsistenz.

Schwache Konsistenz aus Serversicht

Um Ausfallsicherheit und Performance zu verbessern, arbeiten verteilte Speichersysteme mit Replikation. Die Anzahl der Replikate N ist typischerweise größer als zwei und kann auf mehrere hundert ansteigen. Bei Schreiboperationen werden „schlussendlich“ alle Replikate angepasst. Entscheidend für Performance und Konsistenz ist die Anzahl W der Replikate, auf denen die Schreiboperation erfolgreich durchgeführt werden muss, bevor sie als erfolgreich angesehen wird. Ist W=N, muss der Client warten, bis alle Replikate aktualisiert wurden. Bei W < N muss der Client nicht so lange warten. Die verbleibenden Replikate werden asynchron aktualisiert. Die Anzahl der Replikate, von denen gelesen werden muss, um eine Leseoperation erfolgreich durchzuführen, sei R. Wenn W + R > N, dann garantiert das System starke Konsistenz. Mit R = 1 und W = N ist das System für schnelles Lesen optimiert, mit R = N und W = 1 für schnelles Schreiben. Wenn W + R <= N, dann arbeitet das System mit schlussendlicher Konsistenz. Es besteht die Möglichkeit, dass die Menge der Lesereplikate und die Menge der Schreibreplikate nicht überlappen.

Wird eine Datenbank offline beispielsweise auf einem Mobiltelefon benutzt, so ergeben sich Sonderfälle, aber es ist immer noch ein AP-System. Der Client liest nur seine eigenen Daten und liest auch immer seine eigenen Änderungen. Er schreibt nur auf seine lokale Kopie. Später werden dann in einem Replikationsschritt die Daten mit einem anderen Server abgeglichen. Dabei müssen dann auch die eventuell vorhandenen Konflikte aufgelöst werden. Also ist CAP nicht nur für Scale Up, sondern auch für Scale Down relevant.

MapReduce

Eng verbunden mit NoSQL ist MapReduce, ein von Google patentiertes Programmiermodell zur Verarbeitung großer Datenmengen im Computercluster. MapReduce gibt es in unterschiedlichen Ausprägungen. MapReduce wird beispielsweise in Hadoop, CouchDB, MongoDB und Riak angewendet. MapReduce führt die Berechnungen nahe bei den Daten aus, also im Idealfall auf der gleichen Maschine. Dieses Prinzip der Datenlokalität ist der Grund für die gute Performance bei großen Datenmengen. MapReduce arbeitet auf einer abstrakteren Ebene. Der Programmierer kann an Funktionen und Schlüsselwertpaare denken. Im Wesentlichen findet die Verarbeitung bei MapReduce in zwei Schritten statt, wie der Name schon sagt:

  • Im Map-Schritt wird eine Funktion auf jeden Datensatz angewendet. Dazu wird die Funktion an alle Server geschickt, die solche Daten gespeichert haben. Die Funktion kann beispielsweise für jede Log-Zeile eines Webservers den URL heraussuchen. Die Verarbeitung findet dabei typischerweise durch lineares Lesen statt, weil eben jeder Datensatz eingelesen und verarbeitet werden muss.
  • Im optionalen Reduce-Schritt können die Ausgaben der vorhergehenden Mapper weiterverarbeitet werden. Dafür werden die von den Mappern erzeugten Schlüsselwertpaare sortiert und anhand der Schlüssel gruppiert. So können beispielsweise die einzelnen Datensätze für einen URL zusammengefasst werden, um so die Gesamtanzahl der Zugriffe auf einen URL zu erhalten.

Der Vorteil dieses Ansatzes ist, dass alle Server an der Aufgabe mitarbeiten können und der Datenbestand nicht zentral gehalten werden muss. Nachteilig ist der hohe Kommunikationsaufwand zwischen den Servern. Außerdem können natürlich einige der Server ausfallen. Darauf muss das Framework entsprechend reagieren und die Aufgaben dann gegebenenfalls an bestimmte Server noch einmal abschicken. Die Vorteile des Ansatzes sind, dass er mit Standardhardware arbeiten kann. Außerdem können die Anfragezeiten unabhängig von der Datenmenge konstant gehalten werden. Sie hängt nämlich primär von der Datenmenge auf den jeweiligen Servern ab. Wenn man also für eine größere Datenmenge auch eine entsprechend größere Anzahl an Servern nutzt, kann die Antwortzeit nahezu konstant gehalten werden. Neben der Bearbeitung sehr großer Datenmengen kann MapReduce auch genutzt werden, um semi-strukturierte Daten linear nach bestimmten Datensätzen zu durchsuchen. Dadurch können Daten durchsucht werden, die keinem speziellen Schema entsprechen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.