Was man sich unter “polyglotter Persistenz” vorstellen kann, erläutert Holger Temme in seinem aktuellen Blog für silicon.de: Ein kleiner Reiseführer für so genannte NoSQL-Datenbanken soll den parallelen Einsatz von verschiedenen Datenbank-Architekturen in einer Anwendung erleichtern.
Gemeinsam stärker
Bei der Erstellung von Anwendungen stehen Systemarchitekten oft vor der Qual der Wahl: Sie müssen entscheiden, welche Datenbank sich für welche Einsatzzwecke am besten eignet. Graphdatenbanken punkten im Vergleich zu relationalen Datenbanken beispielsweise durch eine deutlich höhere Performance und Skalierbarkeit. Zudem benötigen sie weniger Rechnerleistung und Hardwarekapazität und senken so in vielen Projekten den Overhead deutlich.
Der Einsatz von Graphtechnologie schließt jedoch die Verwendung von bestehenden relationalen oder anderen Datenbanken nicht von vornherein aus. Vielmehr geht der Trend zur “polyglotten Persistenz”, das heißt dem parallelen Einsatz von mehreren Datenbanken für umfangreiche Anwendungen.
Im Idealfall können Entwickler dadurch die Stärken der verschiedenen Datenbanken nutzen und die Schwächen einzelner Datenbanken umgehen. Der Vorteil für Unternehmen: Bestehende Systeme können weiterhin genutzt werden und sparen so Kosten ein. Voraussetzung dafür ist jedoch, dass Anwender den Überblick über die verschiedenen Technologien und ihrer unterschiedlichen Anforderungen behalten.
Dokumentendatenbanken
Ein Beispiel wie sich mehrere Datenbanken sinnvoll miteinander verknüpfen lassen, ist der Einsatz der Graphdatenbank Neo4j mit der Dokumentendatenbank MongoDB. MongoDB ist eine schemafreie Datenbank, in der sich Daten auf natürliche Weise modellieren lassen. Die Daten können nämlich in komplexen Hierarchien verschachtelt werden, bleiben dabei aber immer abfragbar und indizierbar.
Wie Neo4j zählt auch MongoDB zu den NoSQL-Datenbanken. Es gibt also keine festen Tabellenschemata und dadurch beispielsweise auch keine zwingenden Relationstabellen und Joins, die bei wachsender Datenmenge an zusätzlicher Komplexität gewinnen. Stattdessen lassen sich die Beziehungen zwischen den Daten entweder direkt im Datensatz speichern oder bei Bedarf individuell bei der Datenabfrage erstellen. Dadurch ist die Datenstruktur wesentlich flexibler als bei herkömmlichen relationalen Datenbanken.
Beispiel E-Commerce: Echtzeit-Empfehlungen
Suchabfragen im Produktkatalog eines Online-Anbieters gehören zu den Paradebeispielen für Dokumentendatenbanken. Die funktionalen Anforderungen sind hier sehr hoch: Komplexe Abfragen und Filter müssen in unterschiedlichen Portfolien die diversen Eigenschaften von Produkten (z. B. Preis, Verfügbarkeit, Kategorie) durchsuchen können. Dabei ist es entscheidend, alle relevanten Daten mit nur einer Abfrage innerhalb von Sekunden zu erfassen.
Ein Beispiel: Die Website eines Sportartikelherstellers bietet Besuchern unterschiedliche Artikel (zum Beispiel Schuhe, Sportbekleidung, Geräte) an, aber auch persönliche Fitness-Beratungen, Veranstaltungshinweise oder News zu Sportlern oder Mannschaften. Im Web-Shop können Kunden Produkte nach bestimmten Merkmalen wie Farbe, Größe, Preis oder Marke weiter auswählen. Dabei nutzen die Suchabfragen verschiedene Indexes (zum Beispiel Volltextsuche, Filterkategorie oder Preisskala). Relevante Informationen werden mit einer einzigen Suchabfrage erfasst und gesammelt an den Nutzer weitergegeben.
Nutzer finden in Web-Shops so zwar einfach und schnell was sie suchen, der jeweilige Kontext der Personen, ihre Vorlieben, Einkaufsgewohnheiten und Interessen, werden jedoch nicht berücksichtigt. Ein persönliches Einkaufserlebnis wird erst durch Graphdatenbanken wie Neo4j möglich. Sie ermöglichen sogenannte Recommendation Engines, die relevante Produkte und Informationen in Echtzeit empfehlen. Dazu werden zum Beispiel Einkaufshistorie von Kunden, Interaktionen mit anderen Nutzern, Kommentare oder Bewertungen genutzt. Dokumentenorientierte Datenbanken wie MongoDB eignen sich also sehr gut für die Abfrage von Produktkatalogen. Um Kunden persönlich anzusprechen, ist jedoch zusätzlich eine Graphdatenbank wie Neo4j gefragt.
Einfache Synchronisierung
Typischerweise beinhaltet die Nutzung von zwei Systemen wie Neo4j und MongoDB die Synchronisierung der Daten auf der Anwendungsschicht: die Daten müssen einmal in MongoDB und ein weiteres Mal in Neo4j geschrieben werden. Mit diesem Vorgehen kommen jedoch neue Fragen auf: Wurden beide Speichervorgänge korrekt abgeschlossen? Was, wenn eine der Transaktionen fehlschlägt? Und zu welchem Zeitpunkt werden die Daten aktualisiert? Je mehr Systeme zum Einsatz kommen, desto komplexer gestaltet sich die Synchronisierung der Daten.
Es gibt jedoch automatisierte Lösungen, die das Synchronisieren der Daten von MongoDB und Neo4j vereinfachen, so zum Beispiel der Neo4j Doc Manager, eine Implementierung des Mongo Connector-Projekts. Mongo Connector bietet einen Mechanismus für Anwendungen, der jede Aktualisierung in MongoDB meldet und diese Updates an ein bestimmtes Zielsystem übermittelt. Wann immer Dokumente aktualisiert werden, erhält der Doc-Manager automatisch eine Nachricht. Zudem ist er in der Lage, Dokumente direkt in einen Graph umzuwandeln und dieses Update an Neo4j weiterzugeben. Damit wird die Synchronisierung der beiden Datenbanken sichergestellt.
Ähnliche Architektur lassen sich auch bei anderen Datenbankmodellen erfolgreich aufsetzen. Entwickler können so unterschiedliche Datenbanken für unterschiedliche Aufgaben und im jeweiligen Kontext einsetzen. Damit reduzieren sie die Komplexität von polyglotter Persistenz und können gleichzeitig die Stärken unterschiedlicher Technologien für ihre Anwendung voll ausnutzen.
