zurück zum Artikel

Benchmarks helfen bei der zielgerichteten Wahl des richtigen, kostengünstigen DBaaS. Der Artikel zeigt beispielhaft vier PostgreSQL-Angebote in zwei Szenarien.

Cloud-native Anwendungen sind so konzipiert, dass sie die ganze Flexibilität des Cloud Computings nutzen können: Skalierbarkeit, Elastizität, Resilienz. Traditionell liegt bei Cloud-nativen Anwendungen ein besonderes Augenmerk auf der Trennung von Datenhaltung (Storage) und Rechenleistung (Compute), sodass sich Letztere bei Bedarf elastisch skalieren lässt. Datenbank-Management-Systeme (DBMS) fanden im Cloud-native-Kontext lange Zeit wenig Beachtung. Allerdings wünschen sich immer mehr Anwender eine homogene Betriebsumgebung für Compute und Storage.

Die Verwendung von Stateful Sets in Kubernetes bietet eine Möglichkeit dazu. Ein anderer Ansatz ist es, das DBMS als externen Cloud-Dienst in eine Anwendung einzubinden. Der Cloud-Terminologie folgend, spricht man hier von Database as a Service (DBaaS). Die Kunden beziehen dabei eine vollständig verwaltete Instanz eines DBMS.

Übersicht über den DBaaS-Markt

Seit dem Erscheinen von AWS DynamoDB im Jahr 2012 sind eine Vielzahl an DBaaS-Angeboten auf den Markt gekommen, ein Großteil davon in den letzten fünf Jahren. Betreiber von DBaaS sind Datenbankhersteller, Cloud-Provider und Drittanbieter – sogenannte Broker. Auf technischer Ebene deckt der Markt ein breites Spektrum unterschiedlicher Datenbanktechnologien ab. Populäre relationale Datenbanken sind insbesondere PostgreSQL, MariaDB und MySQL. Bei dokumentenbasierten Datenbanken gibt es eine Vielzahl an Angeboten für MongoDB und Derivate, vereinzelt aber auch Couchbase. Die meisten Dienste für spaltenorientierte DBMS basieren auf Apache Cassandra.

Fast jeder Datenbankhersteller stellt inzwischen eigene DBaaS-Angebote bereit. Beispiele hierfür sind MongoDB Atlas, Couchbase Capella, MariaDB SkySQL oder ScyllaDB Cloud. Den meisten dieser Produkte liegt das Infrastructure as a Service (IaaS) der drei Hyperscaler AWS, MS Azure oder Google Cloud Platform zugrunde. Auch so gut wie alle europäischen Cloud-Anbieter haben DBaaS im Portfolio – darunter Open Telekom Cloud, StackIT, OVHcloud und weitere. Der Übergang zwischen DBaaS und Managed Services ist an dieser Stelle fließend.

Die Grundlage von DBaaS bilden oft beliebte Open-Source-Projekte wie PostgreSQL, MySQL oder Apache Cassandra. In anderen Fällen lizenzieren die Anbieter Enterprise-Versionen von beispielsweise MongoDB. Insbesondere die Hyperscaler offerieren darüber hinaus eigene Systeme (Google Spanner oder Alibaba PolarDB) oder bieten Weiterentwicklungen von Open-Source-Projekten (AWS Aurora, Google AlloyDB for PostgreSQL). DBaaS-Broker wie zum Beispiel Aiven, Scalegrid und Instaclustr bieten wie die Cloud-Provider in der Regel eine Vielzahl unterschiedlicher DBMS. Im Gegensatz zu den Cloud-Providern unterhalten Broker jedoch keine eigene Infrastruktur und betreiben ihre DBMS-Instanzen bei unterschiedlichen Cloud-Providern als IaaS oder neuerdings Container as a Service (CaaS).

Kostenaspekte

Die Minutenpreise von DBaaS-Angeboten erscheinen auf den ersten Blick im Vergleich zu IaaS sehr teuer. Dennoch gibt es vernünftige Gründe, DBaaS zu verwenden, anstatt ein DBMS selbst zu betreiben – sei es On Premises oder auf IaaS. Ein Beispiel des Hyperscalers AWS mit dem Relational Data Service (RDS): Hier kostet eine nicht-replizierte DBaaS-Instanz auf einer virtuellen Maschine von AWS (m6i.4xlarge) mit 16 Kernen, 64 GByte Arbeitsspeicher und 1 TByte persistentem GP3-Speicher etwa 1.375 Dollar pro Monat. Die zugrunde liegenden IaaS-Ressourcen schlagen dagegen nur mit etwa 640 Dollar zu buche.

Der DBaaS-Dienst kostet doppelt so viel wie die reinen Cloud-Ressourcen. Hierfür bekommen Kunden allerdings eine Reihe von Leistungen, die sie bei reinem IaaS-Betrieb durch Arbeitszeit und Tooling selbst beisteuern müssten. Insbesondere beinhaltet das Angebot

• automatische Installation und Konfiguration der DBMS-Instanz,
• Monitoring mit Fehlerbehebung,
• Wartung und Aktualisierung der Datenbank,
• Service-Versprechen und Support-Leistungen,
• automatisierte Empfehlungen zum Datenbank-Tuning.

Ein Datenbank-Administrator lässt sich somit einsparen. Bei geschätzten Personalkosten von monatlich 10.000 Dollar für einen erfahrenen DB-Admin sollte sich DBaaS daher für kleinere und mittlere Datenbank-Cluster wirtschaftlich lohnen. Ein gemanagtes Cloud-Projekt für einen 100-Knoten-Cassandra-Cluster dürfte hingegen deutlich teurer sein als eine Lösung in Eigenregie.

DBaaS-Dienste können sich also finanziell lohnen und ihr Einsatz kann darüber hinaus auch strategisch sinnvoll sein: So setzt der Wechsel gegebenenfalls Personalressourcen frei und ermöglicht eine stärkere Fokussierung auf die Produktentwicklung. DBaaS eröffnet zudem einfachen Zugang zu Datenbank-Technologien, für die noch kein eigenes Know-how vorliegt. Letztlich erhöht DBaaS, wie vom Cloud Computing gewohnt, die Flexibilität. Allerdings ergibt sich andererseits auch eine Abhängigkeit vom Anbieter durch Lock-in-Effekte. Entsprechend wichtig ist es, von Anfang an den geeignetsten Dienst auszuwählen.

Service-Modelle

Im Markt existieren drei große Gruppen von Betriebs- und Kostenmodellen: ressourcenbasierte, operationsbasierte und serverless. Das ressourcenbasierte Modell ist das intuitivste und darum mit 90 Prozent der Angebote auch das aktuell verbreitetste. Ähnlich wie bei der Buchung von IaaS-Ressourcen mietet der Nutzer einen festgelegten Typ virtueller Maschinen. Beim operationsbasierten Modell bucht er hingegen eine definierte Anzahl an Datenbankoperationen abhängig vom erwarteten Workload. Für schwankende Workloads kann das Serverless-Modell eine sinnvolle Lösung bieten. Es ist eng verwandt mit dem operationsbasierten Modell, erfordert aber nicht mehr das Buchen einer festen Zahl an Operationen. Stattdessen kostet jede Operation einen fixen Betrag. Der DBaaS-Dienst skaliert die benötigten Ressourcen automatisch und optimal mit der anliegenden Last.

Leistung und Preis-Leistung

Interessenten können alle Ausstattungskriterien für einen Marktvergleich weitestgehend selbst recherchieren. Dies gilt auch für die Preisgestaltung, die auf den Seiten der Anbieter in vielen Fällen allerdings eher unübersichtlich dargestellt ist. In Hinblick auf die Leistungsfähigkeit eines DBaaS-Systems und dessen Preis-Leistungs-Verhältnis stellt sich die Sache jedoch weitaus komplexer dar:

• Die meisten DBMS besitzen eine Vielzahl von Konfigurationsoptionen, die auf die verwendete (virtuelle) Hardware und den zu erwartenden Workload angepasst werden müssen. Viele DBaaS-Anbieter schränken die für Nutzerinnen und Nutzer konfigurierbaren Optionen zwar ein, passen die restlichen aber nicht automatisch auf das Laufzeitverhalten der Instanz an. Unterschiedliche Anbieter stellen darüber hinaus unterschiedliche Standardkonfigurationen bereit.
• Virtuelle Hardware ist zwischen IaaS-Anbietern nicht vergleichbar, so werden virtuelle Maschinen mit acht Kernen, 64 GByte RAM und SSD-Speicher auf AWS und MS Azure unterschiedliche Leistungscharakteristika haben und entsprechend zu unterschiedlichem Durchsatz führen.
• Leistung ist nicht gleich Leistung. In der Regel muss der Betreiber einer DBMS-Instanz entscheiden, für welche Art von Workload das System konfiguriert sein soll und ob eine Optimierung hinsichtlich des Durchsatzes oder der Latenz erfolgen soll. Im letzteren Falle muss er auch noch zwischen Lese- und Schreiblatenz unterscheiden.

Entsprechend wichtig ist es, insbesondere für den Produktivbetrieb eines ressourcenbasierten DBaaS die erforderliche Leistungsfähigkeit durch geeignete Werkzeuge anhand des erwarteten Workloads zu ermitteln.

Ermitteln der Leistungsfähigkeit mit Benchmarks

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 [1] 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.

Auswertung und Einblicke

Die Abbildungen 2 und 4 illustrieren den Durchsatz mit dem jeweiligen Benchmark (höhere Werte sind besser). Die Skalen der beiden Grafen lassen sich wegen der Unterschiede der Methodiken von TPC-H und TAPT nicht unmittelbar vergleichen. Insbesondere misst TPC-H Transaktionen (TXN), die sich über mehrere, teils länger laufende Operationen erstrecken, während TAPT leichtgewichtigere Operationen ermittelt. Für beide Benchmarks liegen OTC und AWS auf vergleichbarem Niveau, wobei AWS 87,5 % bzw. 97,6 % des Durchsatzes von OTC erreicht. In beiden Fällen bildet OVH das Schlusslicht, wegen der geringeren Ressourcen. MS Azure hingegen ist im Falle von TPC-H 24,8 % leistungsfähiger als OTC, während es im TAPT nur 49,1 % der Leistung von OTC erreicht – und damit leicht besser als OVH abschneidet.

Eine detaillierte, vergleichende Leistungsanalyse erfolgt in der Regel auch in Hinblick auf andere Parameter wie Latenz und deren Perzentile oder Speicherbedarf. Die Preis-Leistungs-Verhältnisse der vier Angebote sind in den Abbildungen 3 und 5 dargestellt (niedrigere Werte sind besser). Auch hier sind die Einheiten unterschiedlich. Während beim TPC-H die Kosten pro 10.000 Transaktionen dargestellt sind, zeigt das TAPT-Diagramm die Kosten pro eine Milliarde Operationen. Bei den TAPT-Ergebnissen zum Preis-Leistungs-Verhältnis liegen drei Angebote nah beieinander, mit leichten Vorteilen für AWS im Vergleich zu OVH und OTC. MS Azure dagegen ist pro Milliarde Transaktionen fast doppelt so teuer. Im Falle des TPC-H ist OVH trotz des geringsten absoluten Durchsatzes klarer Preis-Leistungs-Sieger, gefolgt von MS Azure, dem Wettbewerber mit dem größten absoluten Durchsatz. OTC und AWS liegen bei Durchsatz und Preis-Leistung nah beieinander, sind jedoch deutlich teurer als OVH und MS Azure.

Fazit

Obwohl die Auswertung aufgrund des vereinfachten Benchmarkings nur oberflächliche Ergebnisse liefert, zeigt sie deutlich die große Variabilität der Preisgestaltung und der Leistungsfähigkeit der Angebote. Eine Benchmark-basierte Auswertung erweist sich als hilfreich und notwendig, um eine fundierte, faktenbasierte Entscheidung bei der Wahl eines DBaaS treffen zu können. Teile der für diese Evaluation verwendeten Informationen sind als Open Data im Rahmen des benchANT DBaaS Navigators einsehbar [2]. Die rohen Messdaten finden sich im zugehörigen GitHub-Repository [3].

Alle erwähnten Daten zu den DBaaS-Angeboten haben die Autoren mit größter Sorgfalt erhoben. Allerdings spiegelt insbesondere die volatile Preisgestaltung der Anbieter lediglich den Stand zum Zeitpunkt des Verfassens dieses Artikels wider.

Jörg Domaschka
forschte als promovierter Informatiker über 15 Jahre zu Cloud-Computing und DevOps. Dies treibt ihn an, moderne, automatisierte Lösungen für Probleme in IT-Anwendungen zu entwickeln.

Jan Ocker
hat nach dem Physikstudium Erfahrung im IT-Projektmanagement und der Datenanalyse gesammelt. Bei benchANT widmet er sich der (Cloud-)Kosten-Kalkulation und dem Database-as-a-Service-Markt.

Daniel Seybold
promovierte im Bereich verteilter Systeme und Datenbanken. Die Forschungsergebnisse legen den Grundstein für benchANT zur objektiven Leistungsbeurteilung von Cloud und Datenbanken.

(map [4])

URL dieses Artikels:
https://www.heise.de/-9613623

Links in diesem Artikel:
[1] https://benchant.com/de
[2] https://benchant.com/de/navigator/dbaas
[3] https://github.com/benchANT/dbaas-navigator/blob/main/scoring/document.MD
[4] mailto:map@ix.de

Copyright © 2024 Heise Medien