Dokumentorientierte NoSQL-Datenbanken, Teil 1 Das Datenmodell im JSON-Format

Für performante, elastisch skalierbare und global verfügbare Applikationen eignen sich DevOps und Microservices hervorragend. Die Datenverwaltung und -verarbeitung bereitet derweil oft Kopfschmerzen, denn relationale Datenbank-Konzepte stoßen schnell an ihre Grenzen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

mongoDB

Neue digitale Produkte und moderne Applikationen entscheiden über Erfolg oder Misserfolg eines Unternehmens. Doch trotz agiler Methoden, Microservices, Cloud und neuer Technologien wie Machine Learning, IoT und Blockchain: 88 Prozent der CIOs profitierten 2017 noch nicht von ihrer Digitalisierungsstrategie.

Unsere Erfahrung aus der Arbeit mit Tausenden von Unternehmen – Startups bis hin zu Fortune 100-Unternehmen – zeigt, dass die Arbeit mit Daten als Herz jeder Applikation schwerfällig ist:

• Starre Datenmodelle und Wasserfall-ähnliche Entwicklungsmodelle erschweren kurze Release-Zyklen;

• Datenmengen wachsen massiv mit neuen und sich ständig verändernden Datentypen;

• Schwierigkeiten in der Nutzung verteilter Systeme und Cloud-Computing versperren den Zugang zu on-demand und hoch skalierbarer Rechen- und Speicherkapazität;

• Hohe Anforderungen existieren bzgl. Datensouveränität und -lokalität, nicht zuletzt durch die neue Europäische Datenschutzgrundverordnung.

Dokumentenorientierte NoSQL-Datenbanken wie MongoDB wirken dem entgegen. Das JSON-basierte Dokumentenmodell ist Schema-frei und nimmt Daten in beliebiger Struktur auf. Mit verteilten Datenbanksystemen versprechen sie Hochverfügbarkeit, horizontale Skalierbarkeit, Workload Isolation sowie global verteilte Cluster.

Entwicklungsproduktivität: Das Dokumentenmodell

Nachdem sich relationale Datenbanken in den letzten 40 Jahren als Standard zur Datenhaltung, -nutzung und -anreicherung etabliert haben, ist es an der Zeit, den schemagebundenen Ansatz abzulösen. Das JSON-basierte Modell kombiniert vier Vorteile:

• Einfachheit durch die Arbeit mit Daten in einer intuitiven Art und Weise, inkl. Strong Consistency und Transaktionen über mehrere Dokumente;

• Flexibilität: Anpassungen an Schemata während der Laufzeit ermöglichen Code-only Deployments;

• Performance durch Bündelung von Strukturen bei gleichzeitiger Reduktion von Code;

• Vielseitigkeit durch die Unterstützung einer breiten Palette an Datenmodellen, Beziehungen und Abfragen.

Ein Beispiel zur Kundenverwaltung soll die Unterschiede verdeutlichen: Spaltet das relationale Modell die Entität Kunde wie in der vorangestellten Abbildung in verschiedene Tabellen auf – und begründet somit die Notwendigkeit von ORM-Layern zur Überwindung des „object-relational impedance mismatch“ – repräsentiert im Dokumentenmodell eine einzige Datenstruktur ein Objekt entsprechend der Anforderungen der Applikation.

In Beziehung stehende Strukturen werden als Subdokumente und Arrays eingebettet. Das JSON-Dokument in der zweiten Abbildung zeigt einen exemplarischen Kunden.

Die physische Speicherung als Binary JSON (BSON) erlaubt erweiterte Datentypen, wie int, long, date, floating point und decimal128. Sie sind insb. für verlustfreie Finanz- und wissenschaftliche Berechnungen sowie zum Vergleich und Sortieren von Daten notwendig.

Idiomatische Treiber für alle populären Programmiersprachen, wie Java, Javascript, C/C++, C#/.NET, Python, PHP, Scala (und über 30 weitere) sowie für analytische Zwecke, z.B. Spark und R (siehe auch Workload Isolation weiter unten), machen Daten intuitiv zugänglich. Entwickler können also ihre üblichen Werkzeuge verwenden – Neuentwicklung und Einarbeitung in bestehende Projekte erfolgen somit viel schneller. Über SQL greifen Reporting-Werkzeuge direkt auf Dokumente, inkl. automatischem Mapping auf Tabellen und Views, zu.

Garantien zur Konsistenz von Strong Consistency über Eventual Consistency und Causal Consistency (read your own writes) bis hin zu strikter Linearisierbarkeit, sind Cluster-weit oder bis auf Einzelabfrage pro Use Case konfigurierbar und werden durch die Datenbank forciert (siehe auch Hochverfügbarkeit weiter unten).

Cross-Document ACID-Transaktionen inklusive Commit- und Rollback-Funktionen sowie den notwendigen Isolations- und All-Or-Nothing-Garantien stehen für Veränderungen an mehreren Dokumenten zur Verfügung. Ein Beispiel hüerfür wäre ein Banktransfer, bei dem Debitor und Kreditor unbedingt den gleichen Betrag atomar abgebucht bzw. gutgeschrieben bekommen sollen.

Die Flexibilität des schemafreien Ansatzes ermöglicht das Hinzufügen neuer Daten und weiterer Attribute ohne jegliches CREATE oder ALTER TABLE Statement. Eine Reihe von Schema-Design-Patterns beschreiben Best-Practices. Der sog. Polymorphismus erlaubt z.B., dass Kunden unterschiedlich strukturiert sein können: Alle Kunden haben eine ID, optional je nach Kundengruppe einen Social Media-Account oder Geodaten aus der mobilen App.

Das JSON-Schema dient der Schema-Governance: DevOps und DBA-Teams machen klare Vorgaben für jede Collection, inkl. der gerade beschriebenen Mischung aus Pflichtwerten und freien Attributen. Die Datenbank weist Dokumente ab bzw. wirft eine Warnung, sollten diese den Regeln widersprechen.

Verbesserte Performance entsteht durch das Speichern von zusammengehörigen Daten in einem Dokument. Physisch ist im Kundenbeispiel also nur ein einziger gegenüber herkömmlich sieben Festplattenzugriffen notwendig. Verknüpfungen über mehrere Collections erlaubt der $lookup-Operator.

Die Vielseitigkeit des Dokumentenmodells erlaubt u.a. die Modellierung von tabellenartigen Strukturen, Key-Value-Paaren, Geodaten, sowie Knoten und Kanten von Bäumen und Graphen innerhalb einer einzigen Technologie.

Die ausdrucksstarke Abfragesprache (Beispiele in der ersten Tabelle), ergänzt um Indexierung sekundärer Attribute (Tabelle 2), unterstützt einfache CRUD-Operationen bis hin zu anspruchsvollen Pipelines für Analysen und Transformationen.

Der zweite Teil dieses Gastbeitrags widmet sich dem Themenfeld der verteilten Datenhaltung. Zudem sehen wir uns an, wie der Grundgedanke einer einheitlichen Plattform es ermöglicht, beliebige Deployment-Umgebungen zu kombinieren.

Tabelle 1: Beispiele für umfassende Abfragen.

Tabelle 2: MongoDB unterstützt vollwertige sekundäre Indizes.

* Dr. Christian Kurze ist Senior Solutions Architect bei MongoDB.

(ID:46051667)