Echtzeitdaten: Visualisierung & Verarbeitung

Der Vergleich der Echtzeitdatenbanken RethinkDB und Google Firebase Realtime Database beginnt mit einer Analyse ihrer jeweiligen Features. Ein wichtiger Aspekt ist die Abfragesprache. Während Google Firebase eine REST-API und SDKs für Android, iOS und JavaScript (Node.js) bietet, setzt RethinkDB auf die eigene Abfragesprache ReQL. ReQL zeichnet sich dadurch aus, dass es sich an die Programmiersprache des Entwicklers anpasst, Methodenaufrufe statt Text-basierter Abfragen verwendet und somit die Gefahr von böswilligem Code reduziert. Die Dokumentation erwähnt die Möglichkeiten von RethinkDB Schreibbestätigungen (write_acks) mit dem Standardwert 'majority', was bedeutet, dass Schreibabfragen bestätigt werden, sobald die Mehrheit der Replicas erfolgreich geschrieben hat. Weiterhin gibt es die Möglichkeit, den Lese-Modus (readMode) mit den Optionen 'single', 'majority' und 'outdated' zu beeinflussen, um die Konsistenz und Geschwindigkeit der Datenabfrage zu steuern. Der Parameter durability steuert die Dauerhaftigkeit von Schreibvorgängen ('hard' für persistente Speicherung auf Festplatte, 'soft' für Speicherung nur im Arbeitsspeicher). Firebase hingegen bietet setValue() zum Einfügen von Daten, wobei neben Standardtypen auch eigene Java-Objekte (mit Standardkonstruktor und Getter-/Setter-Methoden) akzeptiert werden. Die Unterschiede in der Abfragesprache und den Möglichkeiten zur Steuerung von Konsistenz und Performance bilden einen zentralen Vergleichspunkt.

Ein entscheidender Unterschied liegt in der Umsetzung der Echtzeitfähigkeit. RethinkDB unterstützt Realtime-Anwendungen fundamental durch Changefeeds. Diese ermöglichen die push-basierte Benachrichtigung über Änderungen in Tabellen oder Datensätzen, wodurch unnötige Belastung durch das permanente Abfragen (pulling) vermieden wird. Die Methode changes() erlaubt die Anwendung von Changefeeds auf ganze Tabellen, einzelne Datensätze oder spezifische Abfragen mit Bedingungen. Zusätzliche Parameter wie changefeedQueueSize (maximale Anzahl zwischengespeicherter Änderungen) und includeTypes (Hinzufügen von Typinformationen wie 'add', 'remove', 'change' zum Changefeed) beeinflussen die Funktionsweise. Im Gegensatz dazu bietet Google Firebase Realtime Database addValueEventListener(), welches Datenänderungen überwacht und die Methode onDataChange() bei jeder Änderung aufruft. addListenerForSingleValueEvent() ermöglicht das einmalige Auslesen. ChildEventlistener reagieren auf Änderungen in Kind-Elementen (mit push() oder updateChildren()). Der Vergleich verdeutlicht die unterschiedlichen Ansätze zur Realisierung von Echtzeit-Funktionalität und die damit verbundenen Vor- und Nachteile bezüglich Performance und Programmieraufwand.

Die Skalierbarkeit der beiden Datenbanken ist ein weiterer wichtiger Aspekt des Vergleichs. Der Text beschreibt die Skalierbarkeit von Firebase mit der automatischen Anpassung der Ressourcen in der Google Cloud und der Unterstützung von Millionen Nutzern. Bei RethinkDB wird die Skalierbarkeit durch die Möglichkeit des Shardings und der Replikation angesprochen. Durch das Aktivieren von Sharding werden Daten anhand des Primärschlüssels auf mehrere Tabellen aufgeteilt, was die Performance bei Abfragen verbessert. Die Einrichtung eines Clusters aus zwei RethinkDB Instanzen wird beschrieben, um die Skalierbarkeit zu erhöhen. Beide Datenbanken müssen im Kontext des CAP-Theorems betrachtet werden. Der Text thematisiert die Implikationen des CAP-Theorems für verteilte Systeme und die Notwendigkeit einer Wahl zwischen Konsistenz und Verfügbarkeit bei auftretenden Partitionen. Die Abwägung zwischen Konsistenz und Verfügbarkeit (ACID vs. BASE) spielt eine wichtige Rolle für die Auswahl der geeigneten Datenbank für spezifische Anwendungsszenarien. Eine detaillierte Analyse, wie jede Datenbank das CAP-Theorem handhabt, fehlt im vorliegenden Dokument jedoch.

Die ursprüngliche Idee war ein "Freunde-Tracker", der die Position von Freunden in Echtzeit auf einer Google Maps Karte anzeigt. Diese Idee wurde jedoch angepasst, um die Skalierbarkeit und Echtzeitfähigkeit der verwendeten Datenbank besser zu testen. Die finale Applikation simuliert ein realistischeres Szenario mit mehreren verbundenen Clients, die ihre aktuelle Position als Marker auf der Karte anzeigen. Dies ermöglicht eine realistischere Belastungstests für die Datenbank, da viele gleichzeitige Änderungen in der Datenbanktabelle verarbeitet werden müssen. Die Herausforderung bestand darin, eine Anwendung zu erstellen, die das steigende Nutzeraufkommen realitätsgetreu simuliert und die Echtzeitfähigkeit der gewählten Datenbank, in diesem Fall RethinkDB, effektiv bewertet. Die anfängliche, einfachere Idee eines "Freunde-Trackers" mit nur einem sich ändernden Datensatz wäre für einen umfassenden Test der Echtzeit-Fähigkeiten bei hoher Last unzureichend gewesen.

Für die Entwicklung der App wurde das RemoteUI Framework eingesetzt. RemoteUI ist ein plattformübergreifendes App-Framework, das es ermöglicht, eine App in nur einer Programmiersprache zu entwickeln und diese gleichzeitig als native App für Android und iOS bereitzustellen. Das System besteht aus einem Client auf dem Smartphone und einem RemoteUI-Server, die über eine WebSocket-Verbindung kommunizieren. Die Kommunikation erfolgt im binären Format über ein schnelles, hierarchisches Protokoll, das die wichtigsten Informationen (z.B. das App-Layout) priorisiert. Die Verwendung von RemoteUI vereinfacht den Entwicklungsprozess und ermöglicht die Bereitstellung der App für beide wichtigen mobilen Plattformen ohne separate Implementierungen. Die Wahl von RemoteUI trägt zur Effizienz der App-Entwicklung bei, da nur eine Programmiersprache für beide Plattformen benötigt wird.

Die Implementierung begann mit der Einrichtung der notwendigen Tools: Installation und Konfiguration von Apache Maven, Java und RemoteUI (Version 0.26.1). Ein neues RemoteUI-Projekt wurde mit mvn archetype:generate -Dfilter=remoteui erstellt, gefolgt vom Start des Tomcat-Servers mit mvn tomcat7:run-war. Die Datenbank test und die Tabelle location wurden in der RethinkDB Weboberfläche angelegt. Die Kommunikation mit RethinkDB erfolgte über die Klasse LocationController, die eine REST-API für CRUD-Operationen (Create, Read, Update, Delete) auf der Tabelle location bereitstellt. Die init()-Methode des Controllers stellt die Datenbankverbindung her und erstellt die Tabelle, falls sie nicht existiert. Die Implementierung unterstreicht die praktische Anwendung von RethinkDB im Kontext von Mobile Cloud Computing und betont die Notwendigkeit einer effizienten Integration von Datenbank und App-Framework für die Entwicklung einer performanten Echtzeit-Anwendung. Der Einsatz von Standard-Tools und -Methoden vereinfacht die Reproduzierbarkeit des Projekts.

Die App nutzt Mobile Cloud Computing, um rechenintensive Aufgaben auf einen externen Server auszulagern. Dies spart Rechenleistung und Akkulaufzeit des Smartphones. Die Verarbeitung großer Datenmengen von Sensoren wird auf dem Server durchgeführt, während die App lediglich die Ergebnisse empfängt. Dies ist ein typisches Beispiel für die Vorteile von Mobile Cloud Computing bei der Entwicklung von Echtzeit-Anwendungen, die große Datenmengen verarbeiten. Der Text erwähnt die Herausforderungen von Mobile Cloud Computing wie begrenzte Netzwerkverfügbarkeit und Akkulaufzeit und dass Anwendungen auf plötzliche Umweltänderungen vorbereitet sein müssen. Weiterhin werden die Risiken der Datenhaltung in der Cloud, wie z.B. die Anfälligkeit des Anbieters für Angriffe und technische Probleme, erwähnt. Die Problematik des Datenschutzes durch die Auslagerung von Daten in die Cloud wird ebenfalls angesprochen.

Die Beschreibung der RethinkDB Architektur umfasst wichtige Konzepte wie Sharding und Replikation. Sharding teilt Daten anhand des Primärschlüssels auf mehrere Tabellen auf, was die Performance bei Abfragen verbessert, da jede Tabelle weniger Datensätze enthält. Die Replikation sorgt für die Verfügbarkeit der Daten auf mehreren Servern, was die Ausfallsicherheit erhöht und schnellere Antwortzeiten ermöglicht. Der Aufbau eines RethinkDB-Clusters aus zwei Instanzen wird mit den Befehlen rethinkdb --bind all (für die erste Instanz) und rethinkdb --join IP_ERSTE_INSTANZ:29015 --bind all (für die zweite Instanz) beschrieben. --bind all öffnet den Zugriff für alle externen Verbindungen. Die Architektur von RethinkDB beinhaltet auch das Multiversion Concurrency Control (MVCC) Verfahren. Dieses Verfahren erlaubt die gleichzeitige Ausführung von Lese- und Schreibabfragen, indem bei Bedarf eine Schattenkopie des B-Baums erstellt wird. Dies verhindert Blockierungen und erhöht die Performance. Die Architekturbeschreibung betont die Skalierbarkeit und die Möglichkeiten zur Anpassung der Datenbank an hohe Lasten.

RethinkDB unterstützt Echtzeitanwendungen im Kern durch Changefeeds. Im Gegensatz zu traditionellen Datenbanken, die Daten in regelmäßigen Intervallen abrufen (pullen), bietet RethinkDB eine push-basierte Methode. Changefeeds informieren den Client automatisch über Änderungen in der Datenbank. Die Methode changes() ermöglicht es, diese Changefeeds auf ganze Tabellen, einzelne Datensätze oder auch auf Abfragen mit bestimmten Bedingungen anzuwenden. Die Callback-Funktion wird jedes Mal aufgerufen, wenn sich etwas in der überwachten Tabelle ändert (Hinzufügen, Ändern, Löschen eines Datensatzes). Zusätzliche Parameter wie changefeedQueueSize (zur Begrenzung der Anzahl zwischengespeicherter Änderungen) und includeTypes (zum Hinzufügen von Typinformationen wie 'add', 'remove', 'change' zum Changefeed) erlauben eine feine Steuerung der Echtzeit-Benachrichtigungen. Die Changefeeds sind ein zentrales Element der Echtzeit-Funktionalität in RethinkDB, die für Anwendungen mit dynamischen Daten ideal geeignet ist. Der Text beschreibt ein Beispiel, wie ein Changefeed auf einer users-Tabelle verwendet werden kann, um Änderungen in Echtzeit zu verfolgen.

RethinkDB bietet Parameter zur Steuerung von Konsistenz und Performance. write_acks beeinflusst die Art der Schreibbestätigung; 'majority' (Standard) bestätigt, wenn die Mehrheit der Replicas den Schreibvorgang erfolgreich abgeschlossen hat. readMode steuert den Lesemodus: 'single' liest aus dem Arbeitsspeicher (nicht unbedingt persistent), 'majority' liest nur Daten, die auf der Mehrheit der Replicas persistent gespeichert sind, und 'outdated' liest Daten von einem nahegelegenen Replica im Arbeitsspeicher. durability steuert die Dauerhaftigkeit von Schreibvorgängen ('hard' für persistente Speicherung auf Festplatte, 'soft' für Speicherung nur im Arbeitsspeicher). Diese Parameter ermöglichen es Entwicklern, ein Gleichgewicht zwischen Konsistenz und Performance zu finden. Die Verwendung von 'hard' garantiert Datenpersistenz, verlangsamt aber die Schreibvorgänge. 'soft' erhöht die Geschwindigkeit, birgt aber ein höheres Risiko bei Fehlern. Die Flexibilität bei der Einstellung dieser Parameter ist ein wichtiger Aspekt der RethinkDB Architektur und ermöglicht die Anpassung an die spezifischen Anforderungen der Anwendung. Der Standardmodus von RethinkDB priorisiert die Konsistenz durch sequentielle Abarbeitung der Anfragen am Primary Replica.

Die Google Firebase Realtime Database bietet SDKs für Android, iOS und JavaScript (Node.js), was eine einfache Integration in verschiedene Entwicklungsumgebungen ermöglicht. Die Verfügbarkeit einer REST-API erlaubt die Kommunikation mit der Datenbank auch von anderen Programmiersprachen aus, die HTTP-Anfragen durchführen können. Die nahtlose Integration in Android, da beide von Google entwickelt werden, wird als besonderer Vorteil hervorgehoben. Ein eigener Server ist nicht zwingend erforderlich, da die Daten in der Google Cloud gespeichert werden. Die Datenbank unterstützt setValue() zum Einfügen von Daten, wobei neben Standardtypen auch benutzerdefinierte Java-Objekte als Parameter akzeptiert werden – vorausgesetzt, diese verfügen über einen parameterlosen Konstruktor und Getter- und Setter-Methoden für alle Attribute. Diese Eigenschaften vereinfachen die Datenmodellierung und -verwaltung. Die Methode addValueEventListener() überwacht Datenänderungen und ruft onDataChange() bei jeder Änderung auf. addListenerForSingleValueEvent() ermöglicht das einmalige Auslesen der Daten. ChildEventlistener reagieren auf Änderungen von Kind-Elementen, die mit push() oder updateChildren() hinzugefügt wurden.

Die Google Firebase Realtime Database zeichnet sich durch ihre Echtzeitfunktionalität aus. Änderungen in der Datenbank werden sofort an die verbundenen Clients übertragen. Die Verwendung von addValueEventListener() mit den Methoden onDataChange() und onCancelled() sorgt für die ständige Aktualisierung der Daten beim Client. Die Datenbank bietet aber auch eine intelligente Offline-Funktionalität. Daten werden bei fehlender Netzwerkverbindung auf Wunsch zwischengespeichert und automatisch synchronisiert, sobald wieder eine Verbindung besteht. Diese Offline-Fähigkeit erhöht die Benutzerfreundlichkeit, indem sie auch bei unterbrochener Netzwerkverbindung eine gewisse Datenverfügbarkeit gewährleistet. Der beschriebene ChildEventListener zeigt auf, wie eine Echtzeitliste aller Nutzer dargestellt werden kann, indem der Listener auf Änderungen von Kindselementen reagiert. Die Kombination aus Echtzeit-Updates und Offline-Funktionalität ist ein wichtiges Unterscheidungsmerkmal der Google Firebase Realtime Database.

Die Google Firebase Realtime Database bietet automatische Skalierung ihrer Ressourcen. Dies ist ein entscheidender Vorteil für Anwendungen mit schwankender Benutzerzahl. Der Text erwähnt ein Limit von 10.000 simultanen Verbindungen, das aber auf Anfrage von Google erhöht werden kann. Diese automatische Skalierung und die Unterstützung von weltweit mehreren Millionen Nutzern machen die Datenbank für Anwendungen mit großem Nutzerpotenzial geeignet. Die Datenbank skaliert automatisch die Ressourcen entsprechend der benötigten Kapazität und ermöglicht es, nur für die tatsächlich genutzten Kapazitäten zu bezahlen. Dies vereinfacht das Ressourcenmanagement und minimiert die Kosten. Die Skalierbarkeit und das einfache Ressourcenmanagement sind wichtige Aspekte, die die Google Firebase Realtime Database für den Einsatz in großen, dynamischen Anwendungen attraktiv machen.

Die Arbeit zeigt die wachsende Bedeutung von Echtzeitdatenbanken für Mobile Cloud Computing-Anwendungen auf. Der Vergleich von RethinkDB und der Google Firebase Realtime Database verdeutlicht die unterschiedlichen Ansätze zur Implementierung von Echtzeitfunktionen und Skalierbarkeit. Es wurden die jeweiligen Stärken und Schwächen in Bezug auf Features, Abfragesprachen, die Einhaltung von ACID-Eigenschaften und das CAP-Theorem beleuchtet. Die entwickelte Beispielanwendung einer Flottenmanagement-App demonstriert den praktischen Einsatz von RethinkDB, RemoteUI und Mobile Cloud Computing Prinzipien. Die Wahl der passenden Datenbank hängt stark von den spezifischen Anforderungen der Anwendung ab, wobei Faktoren wie Skalierbarkeit, Konsistenzanforderungen und der Umgang mit Netzwerklatenzen berücksichtigt werden müssen.

Die steigende Anzahl von Smartphone-Nutzern und der damit verbundene Bedarf an Echtzeit-Datenverarbeitung erfordern innovative Lösungen. Echtzeitdatenbanken, die bei entsprechendem Aufbau Millionen von Anfragen pro Sekunde verarbeiten können, sind hierfür essentiell. Zukünftige Entwicklungen sollten sich auf die Optimierung der Echtzeitfähigkeit, die Verbesserung der Skalierbarkeit und den Umgang mit Herausforderungen wie begrenzte Netzwerkverfügbarkeit und Akkulaufzeiten konzentrieren. Die zunehmende Bedeutung des Internet der Dinge (IoT) wird die Entwicklung und den Einsatz von Echtzeitdatenbanken in Mobile Cloud Computing-Architekturen weiter vorantreiben. Die Arbeit regt an, zukünftige Forschungen auf die Verbesserung der Energieeffizienz von Echtzeit-Anwendungen, die Entwicklung robusterer Mechanismen zur Fehlerbehandlung in verteilten Systemen und die Berücksichtigung von Datenschutzaspekten bei der Cloud-basierten Datenverarbeitung zu konzentrieren.