Julia Thrandorf EXXETA

„Durch den Testaufbau mit Docker lassen sich via Pumba sehr einfach Serviceausfälle und Infrastrukturstörungen simulieren. Für die Demonstration in diesem Artikel haben wir uns auf Ausfälle konzentriert“

 

André Haucke EXXETA

„Es ist klar, dass stärkere Konsistenzgarantien mit höherer Rechenleistung und damit mit Performance erkauft werden. Durch die hier gezeigten Last- und Stresstests bekommt man durch ihr Laufzeitverhalten bereits einen ersten Eindruck, wie sich einzelne Konfigurationen auf die Performance auswirken können. „

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 den 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. Jeder 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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 2.19 - "Moderne Frontend-Architektur"

Alle Infos zum Heft
579872088Cassandra, Pumba und der Ernst des Lebens
X
- Gib Deinen Standort ein -
- or -