Die Bedeutung von verteilten Datenbanken für das Internet der Dinge

Bei IoT-Anwendungen kann der Bedarf an Datenvolumen in Datenbanken rasch zunehmen. Eine zeit- und platzeffiziente Nutzung von logischen Datenbanken ist entscheidend. Sogenannte verteilte Datenbanken spielen hier eine wichtige Rolle - aber welcher Ansatz ist für IoT-Anwendungen der geeignetste?

Anbieter zum Thema

RTI Real-Time Innovations

ARS Software GmbH

Vereinfacht gesprochen handelt es sich immer dann um eine verteilte Datenbank, wenn alle Daten, die logisch zusammengehören, auf zwei oder mehr physikalische Datenbanken verteilt sind. In der Praxis sieht es deutlich unübersichtlicher aus, als es zunächst klingt: Es existiert eine Vielzahl an Möglichkeiten, wie oder warum Daten verteilt werden.

Diese sind für unterschiedliche Rechenarten mal mehr, mal weniger tauglich: Einige Methoden eignen sich mehr für Edge-Computing, andere mehr für Cloud-Computing. Es gibt aber auch Varianten, die auf das ganze Spektrum von Edge, Cloud und den Zwischenraum Fog-Computing anwendbar sind.

Bildergalerie

Was versteht man unter einer verteilten Datenbank?

Verschiedene Autoren haben in einem Eintrag auf der englischsprachigen Version von Wikipedia eine gemeinsame Definition von verteilten Datenbanken vorgenommen. Grob übersetzt ist demnach eine verteilte Datenbank „eine Datenbank, bei der die Speicher-Devices nicht alle mit dem gleichen Prozessor verbunden sind. Die verteilte Datenbank kann auf mehreren Computern gespeichert sein, die sich wiederum am gleichen physikalischen Platz befinden oder aber über ein Netzwerk verbunden sind. Im Unterschied zu parallelen Systemen, bei denen die Prozessoren eng gekoppelt sind und eine einzelne Datenbank beinhalten, besteht eine verteilte Datenbank aus lose gekoppelten Systemen welche sich keine Hardware Komponenten teilen“. Diese Definition teilt in gewissem Umfang auch das Institute for Telecommunications Sciences, welches mit dem US Department of Commerce verbunden ist.

Das ist allerdings aktuell eine ziemlich eng umrissene Definition. Es gibt mindestens drei andere Use Cases, die sich unter dem Begriff „Verteilte Datenbank“ zusammenfassen lassen, die auf unterschiedlichen Systemen liegen: High Availability, Cluster Datenbank und Blockchain. Speziell High Availability und Cluster sind dabei für das Internet of Things anwendbar. Die Blockchain ist ein Sonderfall ohne Datenbankmanagementsystem (DMBS), das zwar wegen der Rückverfolgbarkeit von Datenblöcken für buchhalterische Zwecke interessant ist, für IoT-Anwendungen im Sinne dieses Beitrags aber nicht relevant ist. Interessanter ist hingegen das Datenbank-Sharding: eine Variante einer verteilten Datenbank, die in Form mehrerer Partitionen auf verschiedenen Systemen, aber auch auf einem einzelnen Computer existieren kann.

Was eine Datenbank letztlich zu einer verteilten Datenbank macht, ist, dass die verschiedenen Partitionen von separaten Instanzen des Datenbanksystems verwaltet werden. Die eigentliche physikalische Lokalisierung der Speicher-Partitionen macht keine verteilte Datenbank aus.

High Availability: Sicherstellung der Verfügbarkeit

Damit ein Datenbank-System High Availability (HA) unterstützen kann, muss – in Echtzeit – eine identische Kopie der Datenbank in einer getrennten Hardwareinstanz unterstützt werden. Das bedeutet, dass die Kopie konsistent mit dem Master zu sein hat. HA wurde für kritische Industriesysteme entwickelt, um dort die Verfügbarkeit von Gateways und Cloud-Anwendungen abzusichern: die Echtzeitanalyse wird auch im Fehlerfall sichergestellt.

Als Beispiel nehmen wir ein Setup mit mindestens zwei Kopien der Datenbank. Diese Kopien werden Slaves (manchmal auch Replicas) genannt. Datenbankoperationen (wie beispielsweise Einfügen, Löschen, Update, usw.), die auf der Master Datenbank durchgeführt werden, sind auch auf der Slave-Datenbank auszuführen. Dabei muss einer der Slaves jederzeit bereit sein, die Rolle des Masters zu übernehmen. Das wird Fehlersicherheit (Failover) genannt.

Master und Replika sind üblicherweise auf unterschiedlichen Hardwaresystemen installiert. In der Telekommunikation kommen in einer HA-Konfiguration z.B. mehrere Boards in einem Chassis zum Einsatz. Davon ist eines der Boards der Master Controller, ein anderes der Standby Controller und die anderen die eigentlichen Kommunikationscontroller.

In diesem Beispiel wird der Datenbank-Master vom Master Controller Board verwaltet. Das Datenbanksystem repliziert Änderungen der Datenbank vom Master auf den Slave (das Standby Controller Board). Auf diesem Board laufen die identischen Prozesse. Für den Fall, dass das Master Controller ausfällt oder entfernt wird (Hot Swap), übernimmt eines der Standby Controller die Rolle des Datenbank-Masters.

Cluster: Wird Skalierbarkeit oder Konsistenz benötigt?

Bei einer Cluster-Datenbank existieren mehrere Kopien der gesamten Datenbank, die alle synchronisiert sind. Im Gegensatz zu einer High-Availability-Datenbank ist hier jede physikalische Instanz der Datenbank modifizierbar. Diese Abänderungen werden dann von dieser Datenbank auf die anderen Datenbanken im Cluster repliziert.

Im Unterschied zu der bei HA angewandten Master-Slave-Konfiguration wird das Cluster-Verfahren auch als Master-Master-Konfiguration bezeichnet. In den Cluster-Varianten selbst gibt es dabei allgemein gesprochen zwei Modelle, je nachdem, wie die Transaktionen im Datenbankmanagementsystem durchgeführt werden.

Eigenschaften von Transaktionen in verteilten Systemen bezeichnet man oft mit dem Dachbegriff ACID (atomicity, consistency, isolation und durability; im Deutschen auch gelegentlich AKID genannt, für Atomarität, Konsistenz, Isolation und Dauerhaftigkeit). In einer gängigen Methode für Cluster-Datenbanken werden beim ACID die Modifizierungen synchron, unter Verwendung eines zweistufigen Commit-Protokolls, repliziert. Das soll sicherstellen, dass nach dem Commit die Daten in allen physikalischen Instanzen der Datenbanken konsistent sind. Dieses Modell eliminiert potentielle Konflikt, indem es diese auflöst, bevor eine Transaktion dem Cluster als erfolgreich gemeldet wird.

Die andere gängige Variante nennt sich Eventual Consistency. Hierbei werden Änderungen asynchron repliziert. Das kann auch lange nach dem Zeitpunkt erfolgen, zu dem ein Node die Änderungen einer Datenbank als comitted angezeigt hat. Dieses Modell impliziert die Verwendung eines Abstimmungsprozesses, mit dessen Hilfe man Konflikte – hervorgerufen von zwei oder mehr Nodes – auflösen kann.

Bei Eventual Consistency sind die Anwendungen unter der Annahme zu schreiben, dass ältere Daten in der physikalischen Instanz der Datenbank vorhanden sind. Nehmen wir hierfür das Beispiel einer Datenbank eines internationalen Buchhändlers: Käufer in New York und Sidney sehen das gleiche Buch, von diesem ist aber nur insgesamt ein Exemplar im Lager. Beide Käufer können aber das Buch in den Einkaufswagen legen und zur Kasse gehen. Das System hat dann zu bestimmen, wer das Buch bekommt und wer auf der Warteliste landet.

Im Einzelhandel haben Anwender dieses Modell akzeptiert. In einem Mobile Phone Network, in welchem die für einen Anwender freigeschalteten Services oder das Guthaben geprüft werden sollen, funktioniert diese Methode dagegen nicht: Solche Anwendungen erfordern eine Konsistenz der jeweiligen Datenbank.

Wegen den geforderten Merkmalen der synchronen Replikation für eine ACID-Implementierung ist die horizontale Skalierbarkeit begrenzt: Es ist schwierig, zusätzliche physikalische Partitionen für die zeitgerechte Verarbeitung und Analyse der Daten hinzuzufügen bzw. diese auf Cores, CPU's oder Server zu verteilen. Die Implementierung selbst ist - da keine Conflict Resolution nötig ist - ziemlich einfach. Die horizontale Skalierbarkeit von Eventual Consistency ist dagegen hoch, die Komplexität allerdings auch.

Cluster-Implementierungen sind bei IoT-Anwendungen ziemlich verbreitet, zum Beispiel in IoT-Gateways. Um deren Skalierbarkeit und Zuverlässigkeit zu erhöhen, werden diese in der Regel in einem Cluster betrieben. Die Anzahl der Nodes in einem solchen Gateway-Cluster ist nicht sehr hoch. Damit sind vor allem die Eventual-Consistency-Modelle geeignet. Ein Cluster kann mehr Datenaufkommen von Edge Devices verarbeiten als ein einzelnes Gateway. Die Zuverlässigkeit ist ebenfalls höher. Das limitiert zwar die Skalierbarkeit bei sofortiger Konsistenz, was aber Problem bei kleinen Clustern kein Problem darstellt.

Kleiner Exkurs: Die Blockchain-Technologie

Häufig wird im Zusammenhang mit dem Begriff „verteilte Datenbank“ auch die Blockchain-Technologie erwähnt, wovon Bitcoin der wahrscheinlich bekannteste Ableger ist. Die Blockchain ist eine dezentrale Datenbank, die sich auf sämtliche Rechner verteilt, die am zugehörigen Netzwerk angeschlossen sind und regelmäßig durch Blöcke ('blocks') erweitert wird. Diese Datenblöcke entstehen durch die Verarbeitung der Transaktionsdaten, an der alle aktiven Netzwerkteilnehmer gleichberechtigt partizipieren. Durch eine Reihe kryptographischer Verfahren werden alle Transaktionen innerhalb dieses Netzwerk sichergestellt. So halten beispielsweise Prüfsummen fest, in welcher Reihenfolge neue Blöcke entstanden sind.

Der Begriff verteilte Datenbank impliziert meist die Verwendung eines verteilten Datenbankmanagementsystems. Dies trifft allerdings auf die Blockchain nicht zu.

Es ist generell wichtig, eine Unterscheidung zu treffen zwischen einer reinen Datenbank und einem Datenbankmanagementsystem. Als Datenbank bezeichnet man eine Sammlung von Daten. Diese Datenbank kann verteilt sein oder auch nicht. Ein DMBS hingegen ist eine Software, die die Datenbank verwaltet, indem sie etwa Metadaten verwaltet, Datentypen und Attribute definiert, die Daten strukturiert und diese aufgearbeitet Anwendern zur Verfügung stellt. Somit macht das Datenbankmanagementsystem möglich, Anwendungen auf einer Datenbank laufen zu lassen.

Dies trifft auf die Blockchain-Technologie nicht zu: Eine Blockchain ist eine reine verteilte Datenbank.

IoT-Replication: Datenverteilung von der Edge in die Cloud

Eine partitionierte Datenbank-Topologie ist laut (englischsprachiger) Wikipedia „abgespeichert in mehreren Computern, die sich am gleichen physikalischen Ort befinden“. Das nennt man auch Datenbank-Sharding. Der wesentliche Unterschied zwischen Sharding im Vergleich zu HA und Cluster ist, dass bei Sharding jede physikalische Datenbankinstanz nur einen Teil der Daten besitzt, etwa nur die Namen von A-H. Solche Shards repräsentieren eine logische Datenbank. Daher müssen sie nicht zwangsläufig auf mehreren Computern verteilt sein, um ihre Vorteile nutzen zu können. Letztendlich geht es um Skalierbarkeit.

Shards können auf mehreren Servern verteilt liegen oder in Partitionen auf einem einzelnen Server. Auch ob sie mehreren verschiedenen CPUs oder den Cores eines Multi-Core-SoCs zum Einsatz kommen ist nicht wirklich relevant. In allen Fällen erfolgt eine parallele Verarbeitung.

Sharding einer Datenbank setzt eine Unterstützung für die Verarbeitung von verteilten Abfragen voraus. Jeder Shard wird von seiner eigenen Instanz des Datenbank-Servers verwaltet. Da jeder Shard / Server nur einen Teil der kompletten logischen Datenbank enthält, besteht die Möglichkeit, dass die Query-Abfragen nur einen Teil der angefragten Daten liefern. Diese Daten sind unter Umständen erst mit den Daten von anderen Query-Abfragen von anderen Servern abzugleichen, um der Client Anwendung die kompletten Daten liefern zu können.

Wenn die Daten optimal verteilt werden, können alle Daten für eine gegebene Abfrage auf einen einzelnen Shard gefunden werden. In der Regel ist es allerdings so, dass es eine Unterstützung sowohl für das Zusammenlegen von Query-Abfragen über mehrere Shards hinweg als auch für die Abfrage von Daten auf einem einzelnen Shard geben muss.

Ein Beispiel dafür wäre eine sehr große IoT-Anwendung in einer Raffinerie, die mehrere Komplexe mit jeweils hunderten unterschiedlichen Messstellen abdecken muss. Wir können die Informationen der einzelnen Komplexe auf mehrere physikalische Datenbanken, also Shards, verteilen. Wenn wir die zu erwartenden Werte für eine Gruppe von Messstellen berechnen wollen (z. B. Druck und Temperatur im Minutentakt), müssen wir nur den jeweiligen Shard abfragen, der die Daten für diese Messstellen speichert. Wenn wir aber die gleichen Messwerte bei allen Komplexen der Raffinerie messen wollen, müssen wir die Abfrage auf viele Shards bzw. Server verteilen. An dieser Stelle kommt Parallelverarbeitung zum Einsatz: Jede Server-Instanz arbeitet an seinem Teil der Abfrage parallel mit denen der anderen Server-Instanzen.

Datenbank-Sharding unterstützt auch vertikale Skalierbarkeit, also die Befähigung, eine einzelne Datenbank zu vergrößern. Um eine einzelne logische Datenbank von 100 TByte Größe anzulegen, können wir 50 Instanzen einer 2 TByte physikalischen Datenbank erstellen. Dabei lassen sich Shards auch im Nachgang hinzufügen. Das bedeutet, dass das gesamte System um Server erweitert wird, um zusätzlich zur vertikalen (Speichergröße) auch horizontale Skalierbarkeit zu erreichen. Das ist gerade für IoT-Anwendungen besonders wichtig: So unterstützt vertikale Skalierbarkeit die Verarbeitung steigender Datenmengen. Horizontale Skalierbarkeit ist hingegen wichtig, um zeitgerechte Verarbeitung und Analyse der Daten zu unterstützen, wenn etwa die 100 TByte von unserem Beispiel nicht mehr ausreichen sollten.

IoT-Replication: Die Datenverteilung von der Edge in die Cloud

Obwohl es keine Aufgabe des Datenbankmanagementsystems ist, sollten wir trotzdem die Verteilung der Daten innerhalb des IoT-Systems selbst erwähnen. Ein IoT-System besteht typischerweise aus Edge, Gateway und Cloud. Datenbanken existieren in all diesen Elementen. Edge Devices generieren bzw. aggregieren am Netzwerkrand Daten und übertragen diese an Gateways, welche sie an die Cloud weitersenden.

Edge-Geräte kommen häufig für die Steuerung oder Abfrage von Sensoren zum Einsatz. Die dort gesammelten Daten werden auf dem Management-Level analysiert oder auf Optimierungsmöglichkeiten untersucht. Dabei geht es häufig um zusätzliche finanzielle Geschäftsmodelle, wie z.B. eine zeitliche Staffel für den Strompreis. Analysefunktionen in der Cloud erlauben eine Optimierung des Verbrauches, von Abschaltzeiten, der Wartungsintervalle, bessere Interaktion mit dem Kunden usw.

Data Distribution bei IoT bedeutet, dass die Daten von Edge Devices über ein Gateway in eine private oder öffentliche Cloud geschickt werden. Auf vier Aspekte kommt es an dieser Stelle besonders an:

• Connectivity: Edge Devices können auf Offline gehen. Das kann systembedingt sein oder aber aus Fehlern in der Kommunikationsinfrastruktur resultieren. Edge Devices, die batteriebetrieben arbeiten, sind nur aktiv, wenn sie Daten aufnehmen und zum Gateway schicken. Es kann sich aber auch um mobile Geräte mit 3G/4G/5G Interface handeln. Diese Geräte sind nicht immer in Reichweite einer Basisstation oder des Gateways. Welcher Fall auch zutrifft, Edge Devices müssen die Daten für eine spätere Übertragung zwischenspeichern.

• Security: Security ist eines der ganz großen Themen bei IoT Anwendung. SSL/TLS ist dabei nur eine Möglichkeit.

• Bandbreite: Die Bandbreite der verwendeten Kommunikationskanäle kann sehr begrenzt sein. Typische PHY Layer Bandbreiten liegen bei 20-250 kBit/s (ZigBee), bis 159 kBit/s (NB IoT), bis 474 kBit/s (GSM IoT) und 1 oder 2 MBit/s (Bluetooth Low Energy). Um die verfügbare Bandbreite effektive ausnutzen zu können, wird häufig eine Datenkomprimierung vor dem Senden durchgeführt.

• Verwendung der Daten: Die Daten können in den Edge Devices verwendet oder aber in Cloud geladen werden. Was davon zutrifft ist vom Anwendungsfall abhängig und bei der Entwicklung entsprechend zu berücksichtigen.

Bei der eXtremeDB-Datenbank von McObject werden diese Punkte in der Active Replication Fabric unterstützt.

Bildergalerie

Fazit

Lassen wir die Blockchain außer Acht umfasst der Begriff verteile Datenbanken drei verschiedene Varianten, die für das Internet der Dinge relevant sind.

• High-Availability-Datenbanken verteilen eine Master-Datenbank auf eine oder mehrere Replicas. Dies gewährleistet eine hohe Verfügbarkeit der Datenbank im Fehlerfall.

• Cluster-Datenbanken verteilen die Datenbanken für Skalierbarkeit (Eventual Consistency) oder einen kooperativen Betrieb für eine relativ kleine Anzahl von Nodes (ACID).

• Sharding partitioniert eine logische Datenbanken in mehrere Shards um den parallelen Betrieb und eine horizontale Skalierbarkeit zu erleichtern.

Alle vorgenannten Datenbanken bzw. deren Merkmale sind wichtig für die Entwicklung von skalierbaren und zuverlässigen IoT-Systemen. Dabei werden einige Mechanismen parallel verwendet. Bild 1 zeigt das sehr gut. Wir sehen mehrere Cluster von Gateways. Jedes Gateway kommuniziert mit mehreren Edge Devices. Wenn ein Cluster-Node ausfällt, kann sich das entsprechende Edge Device mit einem anderen Gateway im Cluster verbinden. Damit ist der weitere Betrieb des Edge Device gewährleistet.

Auf der Server-Ebene wird eine Shard-Database gezeigt. Jeder Shard empfängt Daten von einem Gateway Cluster. Zusammen repräsentieren alle Shards eine logische Datenbank. Jeder Shard besteht aus einer HA Master mit Replica. Das ist für manche Systeme erforderlich. Andernfalls ist bei Ausfall eines Shard die Integrität der logischen Datenbank kompromittiert.

* Steve Graves ist Mitbegründer und CEO von McObject LLC in Washington, USA.

(ID:46332335)