Dokumentorientierte NoSQL-Datenbanken, Teil 2

Vorteile der verteilten Datenhaltung

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

Erstellung eines global verteilten Clusters mit minimalen Lese- und Schreib-Latenzen auf Basis von Zone Sharding.
Erstellung eines global verteilten Clusters mit minimalen Lese- und Schreib-Latenzen auf Basis von Zone Sharding. (Bild: MongoDB)

Die verteilte Datenhaltung von NoSQL-Plattformen bietet einige Vorteile, darunter Hochverfügbarkeit, Workload Isolation und Datenlokalität. Wie die Technik dahinter funktioniert, schauen wir uns hier genauer an.

Applikationen werden heutzutage für Tausende oder Millionen von Nutzern entwickelt; 24/7-Erreichbarkeit von jedem Gerät aus und elastische Skalierbarkeit sind selbstverständlich geworden. Nutzer erwarten konsistente und minimale Antwortzeiten unter Wahrung von Datenschutz und Datensicherheit.

Um Hochverfügbarkeit zu gewährleisten, erstellen die meisten relationalen Systeme eine Spiegelung des Datenbestands. Infolgedessen werden zusätzliche Werkzeuge zur Datenreplikation bzw. zum Erkennen von Fehlern benötigt, die ein Umschalten der Datenbanken im Fehlerfall initiieren.

Im Gegensatz dazu arbeitet eine verteilte Datenplattform mit eingebauten Mechanismen zur Replikation. Diese sogenannten Replica Sets stellen einen Verbund von Servern dar, sind selbstheilend und führen ein Failover vollautomatisch durch. Zudem wird mit dieser Architektur auch eine rollierende Wartung möglich, z.B. das Einspielen von Upgrades ohne Downtime.

Selbstheilende Replica-Sets.
Selbstheilende Replica-Sets. (Bild: MongoDB)

Um eine hohe Datenkonsistenz zu gewährleisten, erhält ein Verbundserver die Rolle des Primary Servers, gegen den alle Schreiboperationen stattfinden. Die weiteren Mitglieder des Replica Sets arbeiten als Secondary Server und replizieren alle Veränderungen des Primary Servers auf Basis des Operations Log. Es besteht aus einer geordneten Menge idempotenter Operationen, die auf die Replicas kopiert werden.

Kommt es auf dem Primary Server zu einem Fehler, wird einer der Secondary Server vollautomatisch innerhalb weniger Sekunden zum neuen Primary Server gewählt; Applikationen werden automatisch auf den neuen Primary Server umgeleitet.

Tritt der ehemalige Primary Server wieder dem Cluster bei, geht er automatisch in den Secondary Status und synchronisiert seine Daten vom (neuen) Primary Server. Schreibverfügbarkeit ist auch während des Failover-Vorgangs durch Retryable Writes gegeben: Nicht ausgeführte Schreiboperationen werden automatisch gemäß des „exactly once“-Prinzips wiederholt.

Die Server innerhalb eines Replica Sets erlauben die Verteilung von Daten über Rechenzentren hinweg und automatischen Failover im Falle des Totalausfalls eines Rechenzentrums, aber auch globale Verteilung von Daten für schnelle Lesezugriffe. Entwickler können die Replica Sets dabei flexibel konfigurieren:

  • Sicherstellen von Schreiboperationen auf spezifische Server eines Replica Sets – lokal und in entfernten Standorten. Der „write concern“ konfiguriert Regeln zur Bestätigung einer Datenbankoperation, z.B. das Schreiben auf mindestens zwei Server in einer Region sowie mind. einem Server einer weiteren Region.
  • Sicherstellen von garantierten Latenzen von Leseoperationen, z.B. basierend auf der physischen Lokation eines Servers. Die „read preference“ vom Typ „nearest“ wählt automatisch den Server mit der geringsten Ping-Zeit aus, im Fehlerfall automatisch einen anderen Server in der Nähe. Explizite Nodes können über Tags angesprochen werden.

Kombination von operativen und analytischen Workloads.
Kombination von operativen und analytischen Workloads. (Bild: MongoDB)

Replica Sets erlauben zusätzlich eine Workload-Isolation zwischen operativen und analytischen Aufgaben innerhalb desselben Clusters. Explorative Abfragen oder das Training von Machine-Learning-Modellen erfolgen ohne Einfluss auf operative Applikationen. Zusätzliche Secondary Server werden vollautomatisch mit allen Daten der operativen Applikation ETL-frei und in Echtzeit versorgt.

Zur Realisierung von Echtzeit-Data Pipelines lauschen Applikationen über sog. Change Streams auf Veränderungen in der Datenbank und triggern Aktionen. Dieser reaktive Programmiermodus eröffnet diverse Use Cases: Trading-Applikationen, die in Echtzeit auf steigende/fallende Kurse reagieren müssen; Aktualisierung von Dashboards in analytischen Systemen oder Suchmaschinen; IoT-Data Pipelines, die auf den Zustand der physischen Geräte reagieren; Synchronisation von Daten in Serverless- oder Microservice-Architekturen.

Automatisches Sharding für horizontale Skalierung (scale-out und scale-in).
Automatisches Sharding für horizontale Skalierung (scale-out und scale-in). (Bild: MongoDB)

Horizontale Skalierung (alias Sharding oder Partitionierung) auf Basis von Standard-Hardware oder Cloud-Infrastruktur ist die Antwort auf Anforderungen zu hohen Datenvolumina und Durchsatz bei geringen Kosten. Die Verteilung von Daten auf Shards (jeweils ein hochverfügbares Replica Set) erfolgt automatisch über einen frei definierbaren Shard Key.

Shards können, transparent für die Applikation und je nach Anforderung, hinzugenommen, aber auch wieder aus dem Cluster entfernt werden: Egal ob ein oder Hunderte von Shards, der Quellcode sieht exakt identisch aus; es ist keine zusätzliche Logik in der Applikation notwendig; ebensowenig spezielle Cluster-Software oder verteilte Storage-Systeme. Abfragen werden über Query Router (deren Anzahl sich aus den Anforderungen zu Performance und Verfügbarkeit ergibt) an die eigentlichen Shards verteilt.

Die meisten Datenbanksysteme bieten nur ein Hash-basiertes Verteilen von Daten auf Partitionen. In Abhängigkeit der Anwendung sollten jedoch mehrere Mechanismen zur Verfügung stehen:

  • Ranged Sharding: Dokumente mit ähnlichen Schlüsseln liegen sehr wahrscheinlich auf demselben Shard. Dieser Ansatz eignet sich für range-based Queries sowie zur gemeinsamen Ablage von Kunden einer spezifischen Region in einem Shard;
  • Hashed Sharding: Dokumente werden anhand eines MD5-Hashes des Shard Keys verteilt. Dieser Ansatz garantiert eine uniforme Verteilung von Schreiboperationen;
  • Zone Sharding: Dieser Ansatz erlaubt die Definition von spezifischen Regeln zur Ablage von Daten im geshardeten Cluster. Zones sind ideal, um ein Datenlokalitätsprinzip umzusetzen: Entweder nach geographischen Region (Zonen für Nordamerika, Europa und Asien) oder auch nach Serviceklassen (schnelle Hardware für Premium-Kunden oder heiße Daten, langsamere für lauwarme / kalte Daten). Jede Zone kann dabei mehrere Shards enthalten, was wiederum zu einer unabhängigen Skalierbarkeit der einzelnen Zonen führt.

Umfassende Sicherheitsmechanismen runden die Möglichkeiten ab: Authentifikation (LDAP/Active Directory, Kerberos, x.509-Zertifikate, IP-Whitelisting), Autorisierung (auf Basis von rollenbasierter Zugriffskontrolle mit granularen Berechtigungen pro User/Rolle), Auditierung (für regulatorische Compliance; DDL, DML, DCL) sowie Verschlüsselung (at Rest und in Flight).

Zusammenfassung

Kritische Erfolgsfaktoren für die Digitale Transformation sind Geschwindigkeit und Qualität: Wie schnell ist ein Unternehmen in der Lage, neue Applikationen zu entwickeln, diese zu skalieren und Erkenntnisse aus den generierten Daten zu gewinnen? Diese Elemente sind der Schlüssel für bessere Kundenerfahrungen, tiefere und datengetriebene Einsichten in das Kundenverhalten sowie neue Produkte und Geschäftsmodelle.

Eine moderne Datenplattform muss hierfür drei wesentliche Punkte erfüllen:

  • Schnelle, einfache, flexible und vielseitige Arbeit mit Daten – das Dokumentenmodell erweist sich als ideal und entspricht der natürlichen Denk- und Arbeitsweise von Fachabteilungen und Entwicklern;
  • Verteiltes Systemdesign – Hochverfügbarkeit, automatische Skalierung sowie Kombination von operativen und analytischen Workloads in Echtzeit unter der Beachtung von Datenlokalität;
  • Einheitliche Nutzung für Entwickler auf allen Plattformen, um zukunftssichere Applikationen zu erstellen und einen Vendor Lock-In zu vermeiden.

Dieser Gastbeitrag soll eine Anregung zum Paradigmenwechsel in der Arbeit mit und der Verwaltung von Daten sein. Die drei hier dargelegten Säulen bildet auch die Open-Source-Datenbank MongoDB ab. Leserinnen und Leser SIND herzlich eingeladen, sich eine Version herunterzuladen bzw. im gemanagten Service (DBaaS) MongoDB Atlas ein kostenfreies Cluster in der Cloud zu starten. Die Dokumentation ist ebenfalls frei zugänglich und hält eine Vielzahl von Tutorials bereit. Ebenso bietet die kostenfreie MongoDB University Kurse und Zertifizierungen an.

* 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: 46075858 / Datenbanken)