100.000 Maschinen senden im Sekundentakt Daten. Parallel dazu greifen Fachabteilungen und KI-Modelle auf denselben Bestand zu, um historische Muster zu analysieren und Ad-hoc-Abfragen auf Live-Daten zu fahren. Massives Schreiben und komplexes Lesen treffen damit auf derselben Datenbank aufeinander.
Für dieses Szenario wird in vielen Projekten erheblicher Aufwand betrieben: eigene Serverlandschaften, ausgedehnte Kafka-Cluster, mehrere NoSQL-Datenbanken nebeneinander. Alles mit dem Ziel, die Performance unter Last stabil zu halten.
Wir gehen einen anderen Weg. Unser Standard-Speicherort für sämtliche IoT-Rohdaten ist Google BigQuery. Warum diese Entscheidung für uns aufgeht, wo ihre Grenzen liegen und wie wir damit umgehen, beschreibt dieser Artikel.
Das eigentliche Problem: schreiben und lesen zur gleichen Zeit
Industrielle IoT-Daten sind anspruchsvoll im Umgang. Sie fallen kontinuierlich an, in großer Menge, und nehmen keine Rücksicht darauf, ob gerade eine Auswertung läuft. Klassische Architekturen trennen deshalb die beiden Lasten: ein System nimmt die Daten entgegen, ein zweites wertet sie aus, dazwischen liegen Pipelines.
Dieser Ansatz funktioniert. Er bindet aber dauerhaft Hardware, Lizenzen und vor allem Betriebsaufwand, der an Personen hängt.
Warum das Konzept für IoT passt: Streaming Engine und Columnar Storage
Das architektonische Konzept hinter BigQuery passt für IoT-Szenarien ungewöhnlich gut. BigQuery verbindet eine integrierte Streaming-Engine, die Daten direkt beim Eintreffen verarbeitet, mit verteilt gespeichertem Spalten-Storage.
Für den Betrieb bedeutet das im Einzelnen:
Serverless. Ob 10 oder 100.000 Maschinen gleichzeitig senden, ist ohne Belang. Die Streaming-Schnittstelle nimmt die Last auf und skaliert im Hintergrund. Es bleibt keine Hardware zu warten.
Unmittelbare Verfügbarkeit. Gestreamte Daten stehen sofort für SQL-Abfragen bereit, ohne vorgelagerte Batch-Prozesse oder ETL-Strecken.
Spaltenweise Speicherung. Hohe Kompression bei minimalen Abfragekosten. Abgerechnet wird die tatsächliche Nutzung.
Automatisches Cold Storage. Der Speicher macht etwa 10 bis 15 Prozent der Gesamtkosten aus. Selten genutzte Daten wandern automatisch in günstigere Speicherklassen, historische Bestände bleiben dauerhaft wirtschaftlich archivierbar.
Während anderswo noch an Pipelines gearbeitet und über Lizenzmodelle verhandelt wird, fließen die Daten bei uns bereits standardmäßig und hochverfügbar in den Data Lake.
Wo die Grenzen liegen
Eine Lösung für alle Anforderungen gibt es auch in der Cloud nicht. BigQuery ist ein analytisches System, also OLAP-orientiert. Es ist ausdrücklich keine transaktionale Echtzeit-Datenbank für den Live-Betrieb.
Der entscheidende Punkt ist die Latenz: Eine Abfrage benötigt systembedingt etwa zwei bis vier Sekunden, weitgehend unabhängig davon, ob zehn oder zehn Millionen Zeilen abgefragt werden.
Für ein Dashboard, das im Millisekundentakt aktualisiert, oder für automatisierte Rückmeldungen an die Maschine ist das zu langsam. Diese Einschränkung sollte man kennen, bevor man sich für die Architektur entscheidet, und nicht erst im Projekt.
Unser Umgang damit: Technologie nicht gegen ihren Zweck einsetzen
Genau deshalb nutzen wir BigQuery nicht für Aufgaben, für die es nicht
