© Evstigneev Alexander/Shutterstock.com
Datenkonsistenz bei NoSQL-Datenbankclustern im Grenzfall

Cassandra, Pumba & der Ernst des Lebens


Die Datenbank ist die Hüterin der Konsistenz – normalerweise. Aber wie schlagen sich die NoSQL-Datenbankcluster unter Stress? Wie sieht es mit der Datenkonsistenz aus, wenn das System plötzlich unter Dauerlast steht oder sporadisch einzelne Knoten ausfallen?

Im ersten Teil unseres Artikels in Ausgabe 11.18 haben wir bestimmte Konsistenzmodelle definiert und gezeigt, wie diese mit wenig Aufwand überprüft werden können. Die Methode ist unabhängig von der Ablagestruktur und lässt sich problemlos auch auf andere Datenbankmanagementsysteme (DBMS) bzw. unterschiedliche Versionen übertragen. Da der Datenbankcluster als Blackbox verwendet wird, kann die Methode natürlich keinen Beweis für die interne Korrektheit erbringen. Allerdings können wir mit entsprechend hoher Wahrscheinlichkeit davon ausgehen, dass die Konsistenz gewahrt bleibt. Durch die Erhöhung der Durchläufe bzw. mit zunehmender Testdauer präzisiert sich diese Wahrscheinlichkeit weiter.

Werfen wir nun einen Blick auf die Stress- und Grenzfälle, mit denen ein Datenbankcluster in der Realität konfrontiert ist. Dazu setzen wir den Cluster im ersten Schritt mit YCSB unter Last. Anschließend simulieren wir mit Docker und Pumba den Ausfall einzelner Knoten. Konkret zeigen wir das wieder beispielhaft mit Apache Cassandra.

Mit YCSB die Performance messen

YCSB ist ein Benchmarking-Framework für Performancemessungen von NoSQL-Datenbanken, das 2010 von Yahoo! entwickelt wurde [1]. Das Framework besteht aus einem Client, der die Workload generiert, und einer Sammlung von sechs Standard-Workloads. Die Standard-Workloads bilden verschiedene Anwendungsfälle ab (Tabelle 1). Dazu beinhalten sie unterschiedliche Verhältnisse an Lese- und Schreiboperationen oder führen diese in einer bestimmten Reihenfolge aus. Beispielsweise kann Workload A (Update heavy workload) verwendet werden, um einen Session Store zu simulieren, der die neuesten Aktivitäten erfasst. Das Verhältnis von Lese- und Schreibzugriffen liegt in diesem Fall bei 50 zu 50. Jede Workload besteht aus zwei Phasen: einer Loading-Phase und einer Transaktionsphase. In der Loading-Phase wird zunächst eine Datenbasis erstellt und es werden entsprechend des Werts des Parameters recordcount unterschiedliche Datensätze angelegt.

In der Transaktionsphase werden anschließend Lese- und Schreiboperationen auf den Datensätzen ausgeführt und Performancemessungen vorgenommen. Durch den Parameter operationcount können wir dabei festlegen, wie viele Lese- und Schreibzugriffe ausgeführt werden sollen.

Workload

Beschreibung

Anwendungsbeispiel

Workload A: Update heavy workload

Besteht je zur Hälfte aus Lese- und Schreibvorgängen

Session Store, der kürzlich ausgeführte Aktionen aufzeichnet

Workload B: Read mostly workload

Besteht aus einem Lese-/Schreibmix von 95/5

Fototagging: Das Hinzufügen eines Tags ist eine Schreiboperation, am häufigsten werden Tags jedoch gelesen.

Workload C: Read only

Besteht zu hundert Prozent aus Leseoperationen

Benutzerprofilcache, in dem Profile an anderer Stelle erstellt werden (z. B. Hadoop)

Workload D: Read latest workload

Bei dieser Workload werden neue Datensätze eingefügt, die zuletzt eingefügten Datensätze sind am beliebtesten.

Benutzerstatusupdates: User wollen das Neueste lesen.

Workload E: Short ranges

In dieser Workload werden kleine Bereiche anstelle von einzelnen Datensätzen abgefragt.

Konversationen in Threads, in denen jede Abfrage für die Beiträge in einem bestimmten Thread gilt; hier wird davon ausgegangen, dass Beiträge nach der Thread-ID gruppiert sind.

Workload F: Read-modify-write

In dieser Workload liest der Client einen Datensatz, ä...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang