AA+W - Fotolia
Eine passende Datenbank für IoT-Anwendungen auswählen
Wie unterscheidet sich eine IoT-Datenbank von einer herkömmlichen Datenbank? Erfahren Sie, welche Features Datenbanken für IoT-Anwendungen benötigen.
Das Internet der Dinge (Internet of Things, IoT) stellt Datenbankmanagementsysteme vor eine Reihe von Herausforderungen, mit denen herkömmliche Datenbanken nicht oder in deutlich geringfügigerem Umfang konfrontiert sind. Dazu gehören das Erfassen von Daten in Echtzeit, die Verarbeitung von Streaming Events und die Sicherung größerer Mengen von IoT-Geräten und -Daten.
Gleichzeitig stellt das Internet der Dinge weniger Anforderungen an die Datenqualität und -integrität. Beispielsweise kann eine Anwendung, die Daten von Fahrzeugen in einer Flotte sammelt, den Datenverlust für einige Minuten tolerieren und dennoch in der Lage sein, die gesamten Funktionsfähigkeiten der Fahrzeuge zu überwachen.
Obwohl IoT-Sensoren Daten schnell generieren, sind mit ihnen nicht die gleichen Transaktionen verbunden, die in herkömmlichen Unternehmensanwendungen zu finden sind. Dies reduziert den Bedarf an Transaktionen, bei denen Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (ACID/AKID) wichtig sind.
Um für den richtigen Umgang mit IoT-Daten und deren Anforderungen die passende IoT-Datenbank zu finden, sollten IT-Verantwortliche ihr herkömmliches Wissen über übliche Geschäftsabläufe und Vorurteile beim Entwurf von Datenbankanwendungen beiseitelegen.
Anforderungen an IoT-Datenbanken identifizieren
Unternehmen sollten bei der Auswahl einer IoT-Datenbank vier Hauptaspekte berücksichtigen:
1. Skalierbarkeit. Eine Datenbank für IoT-Anwendungen muss skalierbar sein. Idealerweise sind IoT-Datenbanken linear skalierbar, so dass durch Hinzufügen eines weiteren Servers zu einem 10-Knoten-Cluster der Durchsatz um zehn Prozent erhöht wird. IoT-Datenbanken sind normalerweise verteilt, es sei denn, die Anwendung sammelt nur eine kleine Datenmenge, die nicht wesentlich größer wird. Verteilte Datenbanken können auf Standard-Hardware ausgeführt und skaliert werden. Der Vorteil: Anstatt einen Server gegen einen größeren auszutauschen, brauchen bei verteilten Systemen nur neue Server hinzugefügt werden. Verteilte Datenbanken eignen sich besonders gut für Infrastructure as a Service (IaaS), da das Hinzufügen und Entfernen von Servern zum Datenbank-Cluster bei Bedarf relativ einfach ist.
2. Fehlertoleranz. Eine IoT-Datenbank sollte außerdem fehlertolerant und hochverfügbar sein. Wenn ein Knoten im Datenbank-Cluster inaktiv ist, sollte er weiterhin Lese- und Schreibanforderungen akzeptieren können. Verteilte Datenbanken erstellen Kopien von Daten und schreiben sie auf mehrere Server. Wenn einer der Server, auf denen ein bestimmter Datensatz gespeichert ist, ausfällt, kann einer der anderen Server, auf denen ein Replikat des Datensatzes gespeichert ist, auf die Leseabfrage antworten.
Schreibanforderungen können auf verschiedene Arten behandelt werden. Wenn der Server, der normalerweise eine Schreibanforderung akzeptiert, inaktiv ist, kann ein anderer Knoten im Server die Schreibanforderung annehmen. Sobald der Zielserver wieder online ist, kann der Ersatzknoten die Daten an den Zielserver weiterleiten.
3. Hohe Verfügbarkeit. Stellen Sie eine hohe Verfügbarkeit für Schreibvorgänge sicher. Nutzen Sie dafür ein verteiltes Messaging-System wie Apache Kafka oder Amazon Kinesis, das auf Apache Kafka basiert. Diese Systeme können Schreibvorgänge mit hohem Volumen akzeptieren und dauerhaft in einem Publish-and-Subscribe-System speichern.
Wenn ein Server ausfällt oder das Schreibvolumen zu hoch ist, um von der verteilten Datenbank in Echtzeit erfasst zu werden, können Daten im Messaging-System gespeichert werden. Dort werden die Daten so lange vorgehalten, bis die vorgesehene Datenbank den Datenbestand verarbeitet hat, oder dem Datenbank-Cluster zusätzliche Knoten hinzugefügt werden.
4. Flexibilität. IoT-Datenbanken sollten so flexibel sein, wie es die Anwendung erfordert. NoSQL-Datenbanken – insbesondere Schlüssel-Wert-, Dokument- und spaltenorientierte Datenbanken – können problemlos mit mehreren verschiedenen Datentypen und Strukturen verwendet werden. Vordefinierte, feste Schemata sind dafür nicht erforderlich.
NoSQL-Datenbanken sind eine gute Option, wenn eine Organisation mehrere Datentypen verarbeiten muss und sich diese Datentypen mit der Zeit wahrscheinlich ändern werden. In anderen Fällen können Anwendungen, die feste Datensätze erfassen, wie zum Beispiel Wetterdaten, in einem relationalen Datenbankmodell besser funktionieren. Diese Option bieten In-Memory-SQL-Datenbanken wie MemSQL oder PostgreSQL.
Sind gemanagte oder In-house-IoT-Datenbanken besser?
Unternehmen können ihre Datenbank firmenintern betreiben, um Geräte, Software, Sicherheit und Daten besser kontrollieren zu können. Der Inhouse-Betrieb bedeutet, dass Unternehmen ihr Equipment jederzeit an die aktuellen Anforderungen anpassen können.
Sie müssen nicht darauf warten, dass ein Dienstanbieter die Änderungen vornimmt. Im Gegenzug sind Unternehmen aber selbst dafür verantwortlich, dass ihre IT-Experten die IoT-Datenbanken pflegen und ordnungsgemäß sichern. IT-Experten sowie der Betrieb und die Pflege passender Geräte und Software können im Vergleich zu einer extern gemanagten Datenbank zu höheren Gesamtkosten führen.
Database as a Service (DBaaS) hat eine ganze Reihe von Vorteilen: Der externe Servicebetrieb kostet in der Regel weniger als der Kauf und Betrieb firmeneigener Geräte. Betrieb und Wartung erfolgen durch den Servicebetreiber, interne Administratoren müssen die Datenbank weder betreiben noch warten. Service-Provider bieten zudem in der Regel mindestens grundlegende Sicherheitsvorkehrungen und stellen Support zur Verfügung.
Ein paar Nachteile gibt es aber auch: So kann mangelnde Sicherheit von Datenbankdiensten ein Negativpunkt sein, was die Angriffsfläche erhöht. Und Unternehmen, die eine gemanagte IoT-Datenbank nutzen, sind generell auf das beschränkt, was der Dienstleister anbietet. Individuelle Konfigurationen sind nicht oder nur mit zusätzlichen Kosten möglich.
Interne IoT-Datenbanken, die in Frage kommen
Für Organisationen, die ihre eigenen Datenbanken verwalten, steht eine breite Auswahl zur Verfügung. DataStax Cassandra, eine hoch skalierbare verteilte Datenbank, unterstützt ein flexibles Big-Table-Schema und ermöglicht schnelles Schreiben und Skalieren großer Datenmengen. Es basiert auf Apache Cassandra, der Open Source NoSQL-Datenbank. Riak IoT ist ein verteilter, hoch skalierbarer Schlüssel-Wert-Datenspeicher, der in Apache Spark, einer Big-Data-Plattform mit Echtzeitanalyse, integriert ist. Cassandra lässt sich auch in Spark- und Big-Data-Analytics-Plattformen wie Hadoop MapReduce integrieren.
Die Open Source Zeitreihendatenbank OpenTSDB kann auf Hadoop und HBase ausgeführt werden. Die Datenbank besteht aus Befehlszeilen-Interfaces und einem Time Series Daemon (TSD). TSDs sind für die Verarbeitung aller Datenbankanforderungen verantwortlich und werden unabhängig voneinander ausgeführt. Obwohl TSDs HBase zum Speichern von Zeitreihendaten verwenden, haben TSD-Benutzer kaum oder gar keinen Kontakt zu HBase.
MemSQL ist eine relationale Datenbank, die für das Streaming von Daten in Echtzeit optimiert ist. Mit MemSQL können gestreamte Daten, Transaktionen und historische Informationen in derselben Datenbank gespeichert werden. Die Datenbank kann auch sofort mit Geodaten genutzt werden – was für standortbasierte IoT-Anwendungen sinnvoll ist. MemSQL unterstützt die Integration in Data-Warehouse-Produkte, einschließlich Hadoop Distributed File System (HDFS) und Apache Spark.
So wählen Sie zwischen gemanagten IoT-Datenbanken
Bei den gemanagten Datenbanken stehen Unternehmen und Entwicklern viele Services mit unterschiedlichen Vorteilen zur Auswahl. In Frage kommen vor allem AWS-Angebote wie Kinesis und DynamoDB, Azure Cosmos DB, MongoDB oder Google Firebase. Mit Kinesis können Unternehmen Daten in Echtzeit erfassen und diese an die NoSQL-Dokumentendatenbank DynamoDB senden. Diese ist in Amazon Elastic MapReduce integriert. Der Dienst stellt Hadoop- und Spark-basierte Analyseservices bereit.
Wenn Sie mit einem Database-as-a-Service-Anbieter zusammenarbeiten, sollte Sie vor allem die Kostenstruktur sorgfältig prüfen. Die Preise für AWS Kinesis Streams basieren in erster Linie auf den Shared-Stunden. Eine Shared-Stunde weist eine Eingabekapazität von 1 MB pro Sekunde und eine Ausgabekapazität von 2 MB pro Sekunde zu. Kunden zahlen 0,018 US-Dollar pro Shard-Stunde (Region Europa/Frankfurt).
Für die Daten selbst verwendet Kinesis Streams PUT-Nutzlasteinheiten. Damit wird die Gesamtnutzung berechnet. Jede Einheit umfasst zwischen 1 und 25 KB Daten, so dass beispielsweise ein 10-KB-Datensatz als eine Einheit und ein 30-KB-Datensatz als zwei Units berechnet werden. Kunden zahlen 0,0175 US-Dollar pro 1.000.000 Einheiten.
Bei AWS DynamoDB sind die ersten 25 GB pro Monat kostenlos. Jedes GB danach wird mit 0,25 US-Dollar pro Monat berechnet. Bei den Operationen wird der Schreibdurchsatz mit 0,0065 US-Dollar pro Stunde pro 10 Einheiten Schreibkapazität kalkuliert. Der Lesedurchsatz wird für jeweils 50 Einheiten mit der gleichen Rate berechnet. Beachten Sie, dass der Datenverbrauch in der Cloud die Rohdatengröße überschreitet und die Preise je nach Region variieren.
Der Preis für Azure Cosmos DB basiert auf Request Units – zum Beispiel für das Lesen eines 1-KB-Elements – unabhängig davon, ob der Datenbankvorgang gelesen, geschrieben oder abgefragt wird. Der bereitgestellte Durchsatz von 100 Request Units von einem Single-Region-Konto kostet 0,008 US-Dollar pro Stunde.
