Was ist Transbase Crowd?
Transbase Crowd ist eine Architektur, bei der die Daten gespeichert werden, wo sie anfallen: nämlich dezentral (on-Edge) in einer Datenbank auf jedem Gerät. Trotzdem können sie zentral abgefragt werden. Dieser Ansatz unterscheidet sich vom aktuellen Trend des zentralen Cloud-Computings, ist aber aus unserer Sicht die einzig skalierbare Möglichkeit, die enormen Datenmengen zu verarbeiten, die im Zuge des Internet of Things mit immer mehr Geräten anfallen werden.
Die Vorteile dieser Architektur sind:
- Der Netzwerktraffic im Internet wird deutlich reduziert
- Die Daten bleiben auf dem Edge-Device und sind besser geschützt
- Die Effizienz wird gesteigert durch paralleles Ausnutzen der Ressourcen der Edge-Geräte
Wie funktioniert Transbase Crowd?
Setup
Jedes Edge Device erhält eine eigene Transbase Edge Datenbank, in der alle Daten dauerhaft gespeichert werden. Jedem dieser Edge-Geräte wird eine ID zugeordnet.
Auch jeder Server erhält eine eigene Transbase Crowd Datenbank sowie eine eigene ID. Das Datenbank-Schema ist in beiden Instanzen identisch. Wie genau das Zusammenspiel dieser beiden Strukturen funktioniert, wird im nächsten Abschnitt erläutert.
Connection Management
In untenstehender Abbildung befinden sich vier Devices mit jeweils eigener ID, sowie ein Server. Die auf jedem Device generierten Daten werden nicht automatisch an die Zentralinstanz gesendet, sondern in der Edge-Datenbank auf dem Gerät gespeichert.
Anders als bei herkömmlichen Verteilten Datenbanken, hat der Server kein Wissen über existierende Devices. Erst wenn ein Device eine Verbindung aufgebaut und sich beim Server registriert und authentifiziert hat, ist es für den Server sichtbar. In diesem Beispiel sind Devices 1,2 und 746 auf dem Server registriert. Device 27 hat entweder keine Verbindung oder will nicht verbunden sein.
Möchte die Zentrale nun Daten von ihren Devices erfragen, so kann sie an alle in diesem Moment verfügbaren Geräte eine SQL-Anfrage senden.
Die Verbindung zwischen Device und Server wird also vom Device aufgebaut; anschließend kann der Server über diese Verbindung Anfragen zum Device schicken. Insbesondere können so auch Android- oder iOS-basierte Systeme von außen abgefragt werden.
Skalierbarkeit
In untenstehender Abbildung ist eine kaskadierte Architektur zu sehen, wobei wir annehmen, dass jeweils 1000 Geräte zu einem Server verbunden werden.
Möchte man mehr als 1000 Geräte erreichen so muss die Architektur um eine Ebene erweitert werden. Dadurch kann die Zentralinstanz 1000 Server ansprechen, an welche wiederum jeweils 1000 Edge Geräte angeschlossen sind. In der Summe ergibt das 1 Million Edge-Geräte.
Erhöht man die Architektur erneut um eine weitere Ebene, so erhöht sich die Anzahl der Devices auf 1 Milliarde.
Query Anfrage
Um das Prinzip besser zu veranschaulichen, soll nun ein praktisches Beispiel einer Query Anfrage präsentiert werden, in dem die Zentrale eine gewisse SQL-Query an alle verfügbaren Geräte schickt.
Im ersten Schritt sendet die Zentrale die Anfrage an alle Server der ersten Ebene. Jeder dieser Server wiederum schickt die Anfrage direkt weiter an seine Kinder.
Sobald der SQL-Befehl bei allen End-Geräten angekommen ist, wird dieser in voller Parallelität prozessiert. Da jedes Gerät eine eigene Datenbank hat, ist auch die Verwertung der SQL-Anfrage schnell bearbeitet, wir gehen in diesem Beispiel von einer Sekunde aus. Das Resultat wird an die jeweilige Vaterinstanz gesendet. Nachdem jeder Server nun bis zu 1000 Resultate von den Geräten bekommt, müssen diese Resultate von dem Server aggregiert werden, was auch ca. 1 Sekunde Zeit benötigt. Dieser Vorgang wiederholt sich nun bis das Gesamtresultat an der Zentralinstanz angekommen ist.
Der gesamte Prozess dauert somit 3 Sekunden. Das Mächtige an diesem Verfahren ist die Skalierung: Möchte man nicht 1 Million, sondern bis zu einer Milliarde Geräte anbinden , so dauert dieser Vorgang lediglich 1 Sekunde länger, also 4 Sekunden.