Dokumentorientierte NoSQL-Datenbanken, Teil 1

Das Datenmodell im JSON-Format

| Autor / Redakteur: Dr. Christian Kurze * / Stephan Augsten

Modellierung eines Kunden im relationalen Modell – Daten sind über mehrere Tabellen verteilt
Modellierung eines Kunden im relationalen Modell – Daten sind über mehrere Tabellen verteilt (Bild: MongoDB)

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.

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.

Modellierung eines Kunden im relationalen Modell – Daten sind über mehrere Tabellen verteilt
Modellierung eines Kunden im relationalen Modell – Daten sind über mehrere Tabellen verteilt (Bild: MongoDB)

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.

Modellierung eines Kunden als JSON-Dokument.
Modellierung eines Kunden als JSON-Dokument. (Bild: MongoDB)

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.

Ausdrucksstarke Abfragen Finde alle Kunden einer bestimmten Stadt, die nicht auf der “do not call”-Liste stehen
Geodaten Finde das beste Angebot für einen Kunden, der sich gerade auf den Koordinaten der Maximilianstraße in München befindet
Volltextsuche Finde alle Tweets, die einen bestimmten Firmennamen innerhalb der letzten beiden Jahre aufweisen
Facettierte Navigation Filtere alle Produkte < 50 EUR, Größe L, und hergestellt durch ExampleCo
Aggregation Zähle und sortiere die Kunden nach Stadt, berechne minimalen, maximalen und durchschnittlichen Umsatz
Nativer Support für Binary JSON Füge eine weitere Telefonnummer zu einem Kunden hinzu, ohne das Dokument auf Client-Seite neu zu schreiben; Update von zwei aus zehn Telefonnummern; Sortierung nach Modifikationsdatum
Feingranulare Array-Operationen In den Scorings eines Kunden: Update jeden Score, der < 70 ist, auf 0
JOIN ($lookup) Finde alle Kunden aus München, suche alle Transaktionen und summiere den Betrag pro Kunden
Graph-Abfragen ($graphLookup) Finde alle Personen, die über max. drei Stufen mit einem Kunden in Beziehung stehen.

Tabelle 1: Beispiele für umfassende Abfragen.


Index-Typen Index-Features
Primary Index: Jede Collection hat einen Primary Key Index TTL Index: Index auf einem Datumsfeld; sobald die Gültigkeit abgelaufen ist, lösche das Dokument
Compound Index: Index auf mehreren Attributen im Dokument Unique Index: Stellt sicher, dass alle Werte nur einmal vorkommen
MultiKey Index: Index auf Arrays Partial Index: Basierend auf einem Ausdruck, erlaubt Indexe auf einem Subset von Daten
Text Index: Volltextsuchen Case Insensitive Index: Textsuche ohne Unterscheidung der Groß-/Kleinschreibung
GeoSpatial Index: 2d & 2dSphere Index für Geodaten Sparse Index: Nur Dokumente mit einem bestimmten Feld im Index
Hashed Index: Hash-basierte Werte für Sharding

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

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

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46051667 / Datenbanken)