Suche
Maßgeschneidert statt von der Stange

Das Ende der Allzweckdatenbank

Werner Vogels

© Shutterstock / spaxiax

Werner Vogels, CTO Amazon.com, beschreibt die aktuelle Vielfalt der Datenbankmodelle. Eins ist dabei sicher: Die Zeiten der Allzweckdatenbanken sind vorbei!

Das Ende der Allzweckdatenbank

Ich werde oft gefragt, warum wir so viele Datenbankprodukte anbieten. Die Antwort ist einfach: Entwickler wollen, dass ihre Anwendungen gut konzipiert sind und effektiv skaliert werden können. Dazu müssen sie in der Lage sein, mehrere Datenbanken und Datenmodelle innerhalb derselben Anwendung zu verwenden.

Schließlich kann eine Datenbank nur selten den Anforderungen mehrerer unterschiedlicher Anwendungsfälle gerecht werden. Die Zeiten der monolithischen Datenbank für alle Einsatzzwecke sind vorbei. Stattdessen konzipieren Entwickler heute hochverteilte Anwendungen mit einer Vielzahl von spezialisierten Datenbank-Arten. Dabei tun sie das, was sie am besten können: komplexe Anwendungen in kleinere Teile zerlegen und dann das beste Werkzeug zur Lösung jedes Problems auswählen. Das optimale Tool ist jedoch von Anwendung zu Anwendung verschieden.

Da es lange Zeit nur relationale Datenbanken gab, wurden die Daten über Jahrzehnte entsprechend modelliert – unabhängig von der Form und Funktion der Daten in der Anwendung. Statt dass der Anwendungsfall die Anforderungen an die Datenbank bestimmt, trieb das Datenmodell den Anwendungsfall voran. Ist eine relationale Datenbank speziell für ein normalisiertes Schema und zum Erzwingen referenzieller Integrität in der Datenbank entwickelt worden? Absolut, aber entscheidend ist, dass nicht alle Anwendungsdatenmodelle oder Anwendungsfälle mit dem relationalen Modell übereinstimmen.

Wie bereits erwähnt, war einer der Gründe, warum wir Amazon DynamoDB entwickelt haben, der, dass Amazon beim Betrieb von Amazon.com die Grenzen einer damals führenden kommerziellen Datenbank ausreizte und wir nicht in der Lage waren, die Anforderungen an Verfügbarkeit, Skalierbarkeit und Leistung weiter zu erfüllen, die das wachsende Geschäft stellte. Wir fanden heraus, dass etwa 70 Prozent unserer Operationen Key-Value-Zugriffe waren, bei denen nur ein Primärschlüssel verwendet wurde, um eine einzige Zeile zurückzugeben. Da wir keine referenzielle Integrität und Transaktionen benötigten, wurde uns klar, dass für diese Zugriffsmuster eine andere Art von Datenbank besser geeignet sein würde. Darüber hinaus würde mit dem Wachstum und der Größe von Amazon.com eine grenzenlose horizontale Skalierung ein wichtiges Designkriterium sein – vertikale Skalierung war einfach keine Option. Das führte schließlich zu DynamoDB, einem nicht-relationalen Datenbankdienst, der darauf ausgelegt ist, über die Grenzen relationaler Datenbanken hinaus zu wachsen.

Lesen Sie auch: Skalierbares Machine Learning mit Amazon SageMaker

Das bedeutet nicht, dass relationale Datenbanken in der heutigen Entwicklung keinen Nutzen bieten und nicht verfügbar, skalierbar oder leistungsstark sind. Das Gegenteil ist der Fall. Unsere Kunden scheinen es genauso zu sehen, denn Amazon Aurora bleibt der am schnellsten wachsende Service in der Geschichte von AWS. Was wir bei Amazon.com erlebt haben, war die Nutzung einer Datenbank über ihren eigentlichen Zweck hinaus.

Das Fazit lautet: Datenbanken sind für einen bestimmten Zweck konzipiert, und die Abstimmung des Anwendungsfalles mit der Datenbank hilft, leistungsstarke, skalierbare und funktionsfähigere Anwendungen schneller zu schreiben.

Maßgeschneiderte Datenbanken

Die Welt verändert sich und die Kategorie der nicht-relationalen Datenbanken wächst weiter. Wir sehen immer mehr Kunden, die internetbasierte Anwendungen entwickeln wollen, die unterschiedliche Datenmodelle erfordern. Als Reaktion auf diese Anforderungen haben Entwickler nun die Wahl zwischen relationalen, Key-Value-, Dokumenten-, Graphen-, In-Memory- und Suchdatenbanken. Jede dieser Datenbanken löst ein bestimmtes Problem oder eine Gruppe von Problemen.

Werfen wir einen genaueren Blick auf den Zweck jeder dieser Datenbanken:

Relationale Datenbanken: Eine relationale Datenbank ist selbstbeschreibend, da sie es Entwicklern ermöglicht, das Schema der Datenbank sowie Beziehungen und Einschränkungen zwischen Zeilen und Tabellen in der Datenbank zu definieren. Entwickler verlassen sich auf die Funktionalität der relationalen Datenbank (nicht auf den Anwendungscode), um das Schema zu erzwingen und die referenzielle Integrität der Daten innerhalb der Datenbank zu erhalten.

Typische Anwendungsfälle für eine relationale Datenbank sind Web- und mobile Anwendungen, Unternehmensanwendungen und Online-Gaming. Airbnb ist ein sehr gutes Beispiel für einen Kunden, der mit Amazon Aurora leistungsstarke und skalierbare Anwendungen entwickelt. Aurora bietet Airbnb einen vollständig verwalteten, skalierbaren und funktionsfähigen Dienst für die Ausführung seiner MySQL-Workloads.

Key-Value-Datenbanken: Key-Value-Datenbanken sind hochgradig partitionierbar und ermöglichen eine horizontale Skalierung auf Ebenen, die andere Arten von Datenbanken nicht erreichen können. Anwendungsfälle wie Gaming, Ad Tech und IoT eignen sich besonders gut für das Key-Value-Datenmodell, bei dem die Zugriffsmuster eine geringe Latenzzeit für Get/Puts für bekannte Schlüsselwerte erfordern. Der Zweck von DynamoDB ist es, eine konsistente, einstellige Millisekunden-Latenzzeit für jede Workload-Größe bereitzustellen. Diese konsistente Leistung ist der Grund dafür, dass die Funktion „Snapchat Stories“, die den größten Teil der Schreibzugriffe von Snapchat ausmacht, nach DynamoDB verschoben wurde.

Dokumenten-orientierte Datenbanken: Dokumenten-orientierte Datenbanken sind für Entwickler intuitiv zu bedienen, da die Daten auf Anwendungsebene typischerweise als JSON-Dokument dargestellt werden. Entwickler können Daten mit dem gleichen Dokumentenmodellformat persistieren, das sie in ihrem Anwendungscode verwenden. Tinder ist ein Beispiel für einen Kunden, der das flexible Schema-Modell von DynamoDB nutzt, um die Effizienz der Entwickler zu steigern.

Graphendatenbanken: Der Zweck einer Graphendatenbank ist es, das Erstellen und Ausführen von Anwendungen, die mit hochgradig verbundenen Datensätzen arbeiten, zu vereinfachen. Typische Anwendungsfälle für eine Graphendatenbank sind Social Networking, Empfehlungsseiten, Betrugserkennung und Wissensgraphen. Amazon Neptune ist ein vollständig verwalteter Graphendatenbankdienst. Neptune unterstützt sowohl das Property-Graph-Modell als auch das Resource Description Framework (RDF) und bietet die Wahl zwischen zwei Graph-APIs: TinkerPop und RDF/SPARQL. Aktuelle Neptune-Nutzer erstellen damit Wissensgraphen, geben Empfehlungen für In-Game-Angebote ab und erkennen Betrug. Thomson Reuters unterstützt seine Kunden beispielsweise bei der Navigation durch ein komplexes Netz globaler Steuerrichtlinien und -vorschriften mit Neptune.

In-Memory-Datenbanken: Finanzdienstleistungen, E-Commerce-, Web- und mobile Anwendungen verfügen über Anwendungsfälle wie Ranglisten, Sitzungsspeicher und Echtzeitanalysen, die Reaktionszeiten von Mikrosekunden erfordern und jederzeit zu großen Verkehrsspitzen führen können. Wir haben Amazon ElastiCache mit Memcached und Redis entwickelt, um Workloads mit geringen Latenzzeiten und hohem Durchsatz zu bewältigen, die nicht mit plattenbasierten Datenspeichern bedient werden können. Eine solche Lösung setzt beispielsweise McDonald’s ein. Amazon DynamoDB Accelerator (DAX) ist ein weiteres Beispiel für einen speziell entwickelten Datenspeicher. DAX wurde entwickelt, um Lesezugriffe in DynamoDB wesentlich zu beschleunigen.

Suchdatenbanken: Viele Anwendungen geben Protokolle aus, um Entwicklern bei der Fehlerbehebung zu helfen. Amazon Elasticsearch Service (Amazon ES) wurde speziell dazu entwickelt, nahezu in Echtzeit Visualisierungen und Analysen von maschinell generierten Daten bereitzustellen, indem halbstrukturierte Protokolle und Metriken indiziert, aggregiert und durchsucht werden. Amazon ES ist zugleich eine leistungsstarke Suchmaschine für die Volltextsuche. Expedia verwendet mehr als 150 Amazon ES-Domänen, 30 Terabyte Daten und 30 Milliarden Dokumente für eine Vielzahl von geschäftskritischen Anwendungsfällen. Diese reichen von der operativen Überwachung und Fehlersuche über die Verfolgung von Aufrufen in verteilten Anwendungen bis hin zur Preisoptimierung.

Erstellen von Anwendungen mit spezialisierten Datenbanken

Entwickler konzipieren hochgradig verteilte und entkoppelte Anwendungen, und AWS ermöglicht es ihnen, diese Cloud-nativen Anwendungen mit mehreren AWS-Dienste zu erstellen. Ein Beispiel dafür ist Expedia: Obwohl die Website für einen Kunden wie eine einzige Anwendung aussieht, besteht Expedia.com im Hintergrund aus vielen Komponenten, die jeweils eine bestimmte Funktion haben. Durch die Aufteilung einer Anwendung wie Expedia.com in mehrere Komponenten mit speziellen Aufgaben (etwa Microservices, Container und AWS Lambda-Funktionen) können Entwickler produktiver arbeiten, indem sie Skalierung und Leistung erhöhen, den Betriebsaufwand reduzieren, die Agilität der Bereitstellung erhöhen und die Entwicklung verschiedener Komponenten unabhängig voneinander ermöglichen. Beim Erstellen von Anwendungen können Entwickler jeden Anwendungsfall mit der Datenbank koppeln, die den Anforderungen am besten entspricht.

Lesen Sie auch: Container in der Wolke – ein Erfolgsmodell

Werfen wir einen Blick auf einige unserer Kunden, die mehrere verschiedene Arten von Datenbanken für die Erstellung ihrer Anwendungen verwenden:

  • Airbnb verwendet DynamoDB, um den Suchverlauf der Benutzer für schnelle Suchen im Rahmen einer personalisierten Anfrage zu speichern. Sie verwenden ElastiCache, um Sitzungszustände im Speicher abzulegen und um das Rendering der Website zu beschleunigen. Außerdem verwendet  Airbnb MySQL auf Amazon RDS als primäre Transaktionsdatenbank.
  • Capital One verwendet Amazon RDS, um Transaktionsdaten für das Zustandsmanagement zu speichern, Amazon Redshift, um Weblogs für Analysen zu speichern, die Aggregationen benötigen, und DynamoDB, um Benutzerdaten zu speichern, so dass Kunden mit der Capital One App schnell auf die gewünschten Informationen zugreifen können.
  • Expedia baute ein Echtzeit-Data-Warehouse für die Preisfindung von Unterkünften und Verfügbarkeitsdaten für die interne Marktanalyse mit Aurora, Amazon Redshift und ElastiCache. ElastiCache für Redis wird genutzt, um Ereignisse in Echtzeit und unter Einbeziehung der Daten der letzten 24 Stunden zu verarbeiten. Das Data Warehouse speichert die verarbeiteten Daten auch direkt in Aurora MySQL und Amazon Redshift, um sowohl operative als auch analytische Anfragen zu unterstützen.
  • Zynga migrierte die Zynga-Pokerdatenbank von einer MySQL-Farm nach DynamoDB und erhielt eine massive Leistungssteigerung. Abfragen, die früher 30 Sekunden gedauert haben, sind jetzt in einer Sekunde fertig. Zynga verwendet auch ElastiCache (Memcached und Redis) anstelle ihrer selbst verwalteten Varianten für das In-Memory-Caching. Die Automatisierung und serverlose Skalierbarkeit von Aurora machen es zur ersten Wahl von Zynga für neue Dienste, die auf  relationalen Datenbanken basieren.
  • Johnson & Johnson verwendet Amazon RDS, DynamoDB und Amazon Redshift, um den Zeit- und Arbeitsaufwand für die Erfassung und Bereitstellung von Daten zu minimieren und eine schnelle Ableitung von Erkenntnissen zu ermöglichen. AWS-Datenbankdienste helfen Johnson & Johnson, die Arbeitsabläufe von Ärzten zu verbessern, optimieren die Supply Chain und helfen beim Finden neuer Wirkstoffe.

So wie Entwickler heute keine monolithischen Anwendungen mehr schreiben, verwenden sie auch nicht mehr eine einzige Datenbank für alle Anwendungsfälle. Stattdessen greifen sie auf mehrere Datenbank-Arten zurück.

Obwohl die relationale Datenbank weiterhin eine Rolle spielt und sich für viele Anwendungsfälle gut eignet, können speziell entwickelte Datenbanken wie Key-Value-, Dokumenten-basierte-, Graphen-, In-Memory- und Suchdatenbanken dabei helfen, die Funktionalität, Leistung, Skalierung einer Lösung und vor allem das Nutzererlebnis der Kunden zu optimieren.

Geschrieben von
Werner Vogels
Werner Vogels
Werner Vogels ist Chief Technology Officer (CTO) und Vizepräsident von Amazon.com. Werner bloggt unter https://www.allthingsdistributed.com.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: