Seite 2: Ermitteln der Leistungsfähigkeit mit Benchmarks

Inhaltsverzeichnis

Doch wie lässt sich die Leistungsfähigkeit ermitteln, insbesondere wenn wie in einem Green-Field-Projekt die zu nutzenden Anwendungen noch gar nicht existieren? Im Datenbank-Bereich hat Benchmarking eine lange Tradition, um die Fähigkeiten unterschiedlicher Technologien und verschiedener Konfigurationen zu ermitteln. Hierzu existiert eine Vielzahl von Suiten, die eine idealisierten Workload an eine DBMS-Instanz anlegen, um so die Leistungsfähigkeit zu evaluieren. In unterschiedlichen Einsatzszenarien (OLTP, OLAP, Caching, Zeitserien etc.) herrschen jeweils andere Workloads mit variierenden Anforderungen, für die spezialisierte Benchmarks existieren.

Da der Interessent Erkenntnisse von einer Art Workload und einem dazu passenden Benchmark nicht auf einen anderen übertragen kann, ist es essenziell, gleich die richtige Suite auszuwählen. Viele Suiten erlauben zudem eine Parametrisierung, um sich dem echten Workload sukzessive anzunähern.

Workload Modelling

Der erste Schritt bei der Analyse von Performance und Kosten ist die Abbildung des echten Workloads auf eine oder mehrere Benchmark-Suiten, auch Workload Modelling genannt. In vielen Szenarien kommen mehrere Workload-Intensitäten zum Einsatz, um die Skalierbarkeit der DBaaS-Instanz feiner zu evaluieren.

Neben der Bestimmung der Workloads gilt es die zu analysierenden DBaaS-Konfigurationen zu definieren, zum Beispiel: Typ des Block-Speichers, Größe der virtuellen Maschinen, Konfiguration des Clusters usw. Bevor Tester die Benchmarks durchführen, müssen sie die Methodik definieren, die die Struktur und den Automatisierungsgrad der Benchmarks einschließt. Nur eine nahezu vollständige Automatisierung gewährleistet Vergleichbarkeit der Ergebnisse und ermöglicht eine erneute Ausführung unter veränderten Ausgangsbedingungen. Außerdem sollte die Anzahl der Wiederholungen festgelegt sein, um statistisch zuverlässige Ergebnisse zu erhalten.

Bei der Aufbereitung der Ergebnisse ist eine visuelle Repräsentation der Daten hilfreich, um zu einer abschließenden Bewertung zu kommen. Da die Ergebnisse in der Regel nur Leistungsparameter ermitteln, müssen Interessenten diese noch in Bezug zu den Kosten bringen. Auch hier empfiehlt sich eine visuelle Aufbereitung.

Tools für das Datenbank-Benchmarking

Es existieren eine Vielzahl unterschiedlicher Benchmarking-Suiten für Datenbanken. Weithin bekannt sind die des Transaction Processing Performance Council (TPC). So fokussieren sich TPC-C und TPC-E auf OLAP-Systeme, TPCx-HS und TPCx-BB sind für Big-Data-Anwendungen vorgesehen, TPC-H und andere für den Bereich Analytics. Ursprünglich in der Forschungsabteilung von Yahoo entwickelt, ist Yahoo Cloud Serving Benchmark (YCSB) inzwischen ein Open-Source-Community-Projekt für das Benchmarken von NoSQL-Datenbanken. YCSB ist in der Forschung und zum Erstellen von White Papern weit verbreitet.

Weitere Suites existieren zum Beispiel in Form der Time Series Benchmark Suite (TSBS) für Zeitserien-Datenbanken oder der Graph Database Benchmark (GDB) für Graph-Datenbanken. BenchBase ist eine Sammlung unterschiedlicher Workloads und Benchmarking-Tools, die sich über eine einheitliche Schnittstelle verwenden lassen. Weiterhin haben einige Datenbankhersteller Benchmarks für die interne Qualitätssicherung entwickelt.

Keine der genannten Suites ist jedoch von sich aus in der Lage, Benchmarks für DBaaS-Angebote durchzuführen, da alle eine bereits bestehende Datenbankinstanz voraussetzen. Zum automatisierten Benchmarking einer großen Anzahl von Angeboten müssen Tester die Suites in ein größeres Test-Framework integrieren, das sich um Ressourcen-Allozierung beim Cloud-Anbieter, Koordination der Benchmark-Durchläufe, Ressourcen-Freigaben und Auswertung der Ergebnisse kümmert. Die Plattform von benchANT beispielsweise erlaubt automatisiertes Datenbank-Benchmarking.

Performance-Kosten-Analyse für PostgreSQL DBaaS

Basierend auf den vorangegangenen Informationen folgt nun ein beispielhafter, begrenzter Vergleich von DBaaS-Angeboten für PostgreSQL der beiden Hyperscaler AWS und MS Azure sowie der europäischen Anbieter Open Telekom Cloud (OTC) und OVHcloud. Tabelle 1 fasst ausgewählte Aspekte in Hinblick auf Deployment und Management zusammen. Ein Vergleich der Support-Levels und SLAs entfällt an dieser Stelle, da sich gezeigt hat, dass alle Anbieter vergleichbare, aber keinesfalls identische Angebote haben. Insbesondere in Hinblick auf die Cluster-Topologie bestehen Unterschiede, aber auch auf die jeweiligen größtmöglichen Konfigurationen und Anzahl der verfügbaren Disk-Typen.

Alle Angebote folgen dem ressourcenorientierten Kosten-Modell. Entsprechend ist ein Kostenvergleich nur möglich, wenn sowohl die Art des Clusters als auch die Größe der virtuellen Maschinen und des Speicherplatzes bekannt sind. Das Fallbeispiel verwendet daher wo immer möglich virtuelle Maschinen mit 16 Kernen und 64 GByte Arbeitsspeicher. OVH bot eine solche Konfiguration nicht an, sodass für den Test die nächst ähnliche zum Einsatz kam. Alle Konfigurationen bauen auf dem von den Anbietern für I/O-intensiven Einsatz vorgesehenen Block-Speicher auf. Die konkreten Konfigurationen sind zusammen mit den monatlichen Kosten in Tabelle 2 zusammengefasst.

Workloads für das Benchmarking

Zum Erzeugen der Workloads werden zwei leselastige Benchmarks verwendet: TPC-H und TATP in der BenchBase-Implementierung. TPC-H ist für analytische Anwendungsszenarien konzipiert und verwendet komplexe, aber ausschließlich lesende Queries. Dabei weist er eine CPU-intensive Charakteristik auf. Der TATP-Benchmark simuliert eine Teilnehmerdatenbank aus dem Mobilfunkbereich. Entsprechend repräsentiert er mit seiner überwiegend lesenden Last latenzkritische Szenarien, wie sie neben der Telekommunikation auch in Finanzdienstleistungen oder Reservierungssystemen anzutreffen sind. Ähnlich wie der TPC-H kann auch TATP CPU-intensiv sein, stellt darüber hinaus aber auch hohe Anforderungen an den Durchsatz in Netzwerk und Speicher-Backends.