IoT-Datenspeicherung: Architektur und Optionen

Ein lokales Verlaufsdiagramm, eine Warteschlange für Messwerte an eine Cloud-Plattform und ein Archiv für sieben Jahre sind drei verschiedene Speicher. Sie beantworten unterschiedliche Fragen, benötigen je Messwert unterschiedlich viel Platz und fallen auf unterschiedliche Weise aus. Bemessen, befristen und testen Sie jeden Speicher getrennt.

Für Messwerte mit Zeitstempel ist eine Zeitreihendatenbank oft der Ausgangspunkt. Verwenden Sie eine relationale Datenbank, wenn Messwerte mit Geschäftsdaten verknüpft werden müssen, eine Dokumentendatenbank bei wechselnder Struktur der Nutzdaten und Objektspeicher für Dateien und Analysedatensätze. Jede dieser Lösungen kann vor Ort oder zentral betrieben werden.

Verlauf, Zustellung und Wiederherstellung

Beginnen Sie mit einem Datenvertrag für Sensorwerte: Quellidentität, Wert, Einheit, Mess- und Eintreffzeit, Qualität sowie Herkunft der Verarbeitung. Der Speicher muss davon genug bewahren, damit ein Messwert auch nach einer Geräte- oder Konfigurationsänderung verständlich bleibt.

Die letzte Spalte erklärt viele Überraschungen. Ein Verlauf kann Messwerte löschen, die ein Ziel nie erhalten hat. Eine leere Warteschlange kann bedeuten, dass Zustellung gelang, dass keine Daten eintrafen oder dass ein Filter den Punkt entfernte. Ein Diagramm kann aktuelle Werte zeigen, während der Cloud-Plattform eine Woche fehlt. Prüfen Sie jedes Ergebnis einzeln.

Datenbank- und Speicheroptionen für IoT vergleichen

Zeitreihendatenbanken

Nutzen Sie eine Zeitreihendatenbank, wenn die meisten Abfragen zeitgestempelte Zahlen, Zeitfensteraggregate und Trends betreffen. Testen Sie vor der Auswahl verspätete Werte, Duplikate, Anzahl der Labelkombinationen, Abfragelimits und Aufbewahrungsregeln in der tatsächlich eingesetzten Ausgabe.

VictoriaMetrics auf einem Knoten stellt die zeitbasierte Aufbewahrung mit -retentionPeriod ein; der Standardwert ist ein Monat. Laut Größenplanung benötigt ein Messpunkt nach Kompression rund 1 Byte oder weniger auf dem Datenträger. Häufig wechselnde Zeitreihen verschlechtern die Kompression. Berechnen Sie den Standortwert aus vm_data_size_bytes und der Zahl gespeicherter Zeilen. Halten Sie mindestens 20 % des Datenverzeichnisses frei. VictoriaMetrics braucht diesen Platz zum Zusammenführen von Datenblöcken; ohne Zusammenführung werden Abfragen langsamer.

Die Kardinalität ist die Zahl unterschiedlicher Zeitreihen. In IoT-Systemen wächst sie, wenn ein Label oft wechselt, etwa wenn Firmwareversion oder Signalstärke als Label gespeichert werden. Die Messpunktrate bleibt gleich, aber der Index wächst mit jeder neuen Kombination. Bewahren Sie veränderliche Merkmale im Anlagenspeicher statt in Zeitreihenlabels auf.

Relationale Datenbanken

Nutzen Sie eine relationale Datenbank, wenn Abfragen Messwerte mit Betriebsmitteln, Produktionschargen, Tarifperioden oder Servicedaten verbinden und das Team SQL bereits produktiv betreibt.

Die Partitionierung von PostgreSQL teilt große Tabellen nach Zeitbereichen. Eine alte Partition zu entfernen oder abzuhängen ist deutlich schneller als ein massenhaftes DELETE und erspart die damit verbundene VACUUM-Arbeit. Die Erweiterung TimescaleDB automatisiert dies: Eine Hypertable wird in Zeitblöcke geteilt; eine Aufbewahrungsregel entfernt ganze alte Blöcke. Sie gilt nicht für darauf beruhende kontinuierliche Aggregate. Stündliche Aggregate können die Rohdaten also überdauern. Prüfen Sie Indexgröße und Abfragepläne mit mindestens einem Monat repräsentativer Daten.

Dokumentendatenbanken

Dokumentenspeicher passen zu Geräteakten und Ereignis-Nutzdaten mit wechselnder Struktur. MongoDB-Zeitreihensammlungen speichern Messwerte zeitlich geordnet und spaltenorientiert, gruppiert durch ein metaField, das die Zeitreihe identifiziert. Aktualisierungen sind eingeschränkt: Das Handbuch begrenzt die Filterausdrücke für Updates auf das metaField. Planen Sie die Speicherung korrigierter Werte, bevor Sie auf Aktualisierung am ursprünglichen Ort angewiesen sind. Auch ein flexibles Dokument braucht festgelegte Einheiten, Identitäten und Zeitstempelbedeutungen.

Objektspeicher und analytische Archive

Objektspeicher hält exportierte Messdateien, Auditbelege und Analysedatensätze. Die Abfrage-Engine ist eine getrennte Komponente. Athena liest spaltenorientierte Formate wie Parquet und ORC und lädt nur die für eine Abfrage benötigten Spalten.

Zwei Regeln aus dem Athena-Leitfaden zur Optimierung sind für Sensorarchive wichtig. Erstens: Partitionieren Sie passend zu häufigen Abfragen. Wenn Analysen nach Tagen erfolgen, partitionieren Sie nicht stündlich; sortieren Sie die Datensätze innerhalb einer Datei nach Zeit. Zweitens: Vermeiden Sie viele kleine Dateien. Die Standardgröße einer Parquet-Zeilengruppe beträgt 128 MB. Bei kleinen Dateien übersteigt der Aufwand für das Spaltenformat seinen Nutzen. Ein Standort mit 1.440.000 Messwerten pro Tag erzeugt eine deutlich kleinere tägliche Parquet-Datei. Partitionieren Sie nach Standort und Monat oder bündeln Sie mehrere Standorte in einer Tagesdatei.

Legen Sie Schemaversion und Datenvertrag neben die Dateien. Ein Verzeichnis mit CSV-Dateien ohne diese Angaben ist billig zu schreiben und Jahre später teuer zu verstehen.

Prüfen Sie die Speicherklasse. S3 Glacier Flexible Retrieval und Glacier Deep Archive erfordern vor dem Lesen eines Objekts eine Wiederherstellungsanforderung; Glacier Instant Retrieval nicht. Berücksichtigen Sie Abruf-, Anfrage-, Abfrage- und Übertragungskosten neben dem Preis pro gespeicherten Gigabyte.

Vor-Ort- und Zentralspeicher

Ein eigenständiger Standort kann allein mit lokalem Verlauf arbeiten. Ergänzen Sie einen zentralen Speicher für standortübergreifende Vergleiche, gemeinsame Berichte oder längere Aufbewahrung. Eine hybride Lösung bietet beides, bringt aber eine zweite abzugleichende Kopie, eine zu überwachende Outbox und eine weitere Aufbewahrungsregel mit.

Heiße, warme und kalte Speicherschichten beschreiben Abrufhäufigkeit und erforderliche Abrufgeschwindigkeit. Eine Datenbank mit zwei Aufbewahrungsregeln kann zwei Schichten bereitstellen. Jede weitere Schicht braucht Zuständigkeit, Übertragungsprüfung und eine festgelegte Reaktion bei Übertragungsfehlern.

Wie Edge Verläufe speichert und Daten erneut zustellt

EpiSensor Edge speichert den abfragbaren lokalen Verlauf in VictoriaMetrics und ausstehende Zustellungen getrennt davon in einer SQLite-Outbox. Der lokale Verlaufsmodus zeichnet entweder alle gültigen Messwerte, nur für den Export aktivierte Messwerte oder gar keine auf. Die Aufbewahrungsdauer wird in Tagen eingestellt; der Standardwert ist 30. VictoriaMetrics liest den Wert beim Start. Eine Änderung wird daher nach einem Neustart von Edge wirksam. Wenn Sie den Verlauf einschalten, beginnt die Aufzeichnung ab diesem Zeitpunkt. Nie gespeicherte Messwerte lassen sich nicht nachträglich rekonstruieren.

Bei ungestörter Zustellung bleibt ein Messwert zunächst im Arbeitsspeicher. Edge hält ihn dort, bis das Ziel Erfolg meldet, und verwirft ihn dann ohne Schreibvorgang auf dem Datenträger. Erst wenn die Zustellung fehlschlägt oder das Ziel bereits als offline bekannt ist, schreibt Edge ihn in die Outbox. Ähnlich arbeitet der lokale Verlauf: Edge sammelt Messwerte bis zu 250 ms im Arbeitsspeicher und schreibt den Block in VictoriaMetrics. Nur wenn dieser Schreibvorgang scheitert, nutzt Edge die Outbox. Das verringert Schreibvorgänge auf der eMMC des Gateway. Ein Stromausfall oder Prozessstopp vor der dauerhaften Speicherung kann noch im Arbeitsspeicher liegende Messwerte verlieren lassen.

Ein Erzeuger, der Messwerte über HTTP an Edge sendet, kann die Fälle an der Antwort unterscheiden. 202 bedeutet, dass Edge die Arbeit für die spätere Zustellung auf den Datenträger geschrieben hat. 200 bedeutet Annahme im Arbeitsspeicher. 503 oder 507 bedeutet, dass Edge datenträgergestützte Arbeit wegen nicht verfügbarem Speicher oder aktivierter Schutzgrenze bei wenig freiem Platz abgelehnt hat. Der Erzeuger muss diese Daten behalten und erneut senden.

Wann eine laufende Zustellung als abgeschlossen gilt, hängt vom Transport ab:

• MQTT: Abschluss der Veröffentlichung mit QoS 1.
• HTTP-Export: der konfigurierte Erfolgsstatus, nachdem der gesamte Antwortkörper eingetroffen ist.
• Dateiexport: Schreiben in die Warteschlange ausstehender Exportdateien.
• Modbus Server: Abschluss jedes Registerschreibvorgangs der Nachricht.

Die von Edge verwaltete erneute Zustellung gilt für Ziele, die sie ausdrücklich anfordern, etwa EpiSensor Core. Andere Integrationsabläufe haben eigene Wiederholungsversuche oder stellen nur nach bestem Bemühen zu. Prüfen Sie bei der Inbetriebnahme für jede Integration, welcher Fall gilt.

Für die Outbox gelten andere Regeln als für den Verlauf. Ausstehende Outbox-Einträge haben in der derzeitigen Implementierung keinen zeitbasierten Verfall: Eine Löschung würde unzugestellte Daten verwerfen. Bei einem langen Ausfall wächst die Outbox, bis die Zustellung wieder funktioniert oder die Schutzgrenze bei wenig freiem Speicher neue Arbeit ablehnt. Standardmäßig greift diese Grenze bei 10 % freiem Platz auf dem Dateisystem, begrenzt auf 1 GiB, oder bei 256 MiB. Jedes Ziel hat eigene Einträge. Ein langsames Ziel kann die Daten eines anderen daher weder blockieren noch als zugestellt bestätigen. Erneut gesendete Messwerte behalten ihre ursprünglichen Zeitstempel. Edge sendet sie nur an das Ziel, das sie verpasst hat. Berechnete Geräte und Automationen laufen dabei nicht erneut, weil sie den ursprünglichen Messwert bereits verarbeitet haben. Outbox-Schreibvorgänge verwenden SQLite mit synchronous=FULL; ein bestätigter Commit übersteht damit einen Stromausfall.

Verlauf und Ausfallpuffer bemessen

Zählen Sie meldende Kanäle statt Geräte. Ein Zähler kann mehrere Messgrößen in unterschiedlichen Intervallen senden. Bei festem Intervall gilt:

Messpunkte pro Tag = meldende Kanäle × 86.400 ÷ Meldeintervall in Sekunden

Beispielsweise ergeben 1.000 Kanäle mit je einem Messwert pro Minute 1.440.000 Messpunkte pro Tag oder 43.200.000 Messpunkte in 30 Tagen, vor jeder Filterung. Bei einem Intervall von einer Sekunde ist die Rate 60-mal so hoch. Rechnen Sie Ereignisspitzen und berechnete Werte gesondert hinzu.

Verlauf. Nach dem VictoriaMetrics-Richtwert von etwa 1 Byte je Messpunkt brauchen die Werte aus 30 Tagen in diesem Beispiel ungefähr 43 MB, zusätzlich zu Index und 20 % freiem Platz. Ein Jahr umfasst rund 526 Millionen Messpunkte oder grob 0,5 GB. In einem synthetischen EpiSensor-Benchmark belegten 200.000 regelmäßige Messwerte 35 KB in VictoriaMetrics und 36 MB in einer einfachen SQLite-Tabelle, ein Verhältnis von etwa 1.000 zu 1. Unruhige Feldwerte lassen sich schlechter komprimieren als synthetische. Messen Sie daher mit den Daten Ihres Standorts.

Outbox. Auf einem Gateway im Feld benötigte jeder wartende Messwert einschließlich SQLite-Indizes ungefähr 550 Byte je Ziel. Dieselben 1.000 Kanäle erzeugen bei einem Ausfall von 72 Stunden 4.320.000 wartende Messwerte: ungefähr 2,4 GB für ein Ziel oder 4,8 GB für zwei. Bei einem ZGW-20 mit standardmäßig 16 GB eMMC ist das ein erheblicher Teil des Datenträgers. Damit bestimmt meist die Outbox und nicht der Verlauf, wie lange das Gateway den Ausfall überbrücken kann. Die Rechenmoduloption mit 64 GB eMMC oder die optionale SSD mit 128 GB verlängert den Puffer. So schätzen Sie die mögliche Dauer:

Überbrückbare Ausfallstunden = freier Platz für die Outbox ÷ (Bytes je wartendem Messwert × Messwerte pro Stunde × Ziele)

Ziehen Sie die Schutzgrenze bei wenig freiem Platz sowie Platz für Logs, Updates und Backup-Zwischenspeicherung vom „freien Platz“ ab.

Messen Sie in einem Pilotprojekt diese vier Größen:

1. Wachstum des Verlaufs nach der Datenbankwartung: gespeicherte Messpunkte, Zahl der Zeitreihen, Indexgröße und Datenträgerbelegung.
2. Wachstum der Outbox je Ziel während eines kontrollierten Ausfalls, einschließlich des SQLite-Write-Ahead-Logs.
3. Durchsatz bei der Wiederherstellung: bestätigte Zustellungen je Sekunde, während neue Messwerte weiter eintreffen.
4. Alle übrigen Beleger des Datenträgers: Betriebssystem, Logs, Updates und Backup-Zwischenspeicherung.

Die Entleerungszeit ist ebenso wichtig wie die Kapazität. Angenommen, der Rückstand umfasst 120.000 Einträge, 100 neue Einträge treffen pro Sekunde ein und das Ziel bestätigt 300 pro Sekunde. Netto sinkt der Rückstand um 200 Einträge pro Sekunde und ist frühestens nach 600 Sekunden beziehungsweise 10 Minuten abgebaut. Wiederholungsversuche und Drosselung verlängern dies. Liegt der bestätigte Durchsatz nicht über der Eingangsrate, wird der Rückstand nie leer.

Was eine Bestätigung belegt

Eine Verbindung, ein Sendevorgang, eine Bestätigung und ein gespeicherter Messwert sind getrennte Ereignisse. Legen Sie für jeden Übertragungsschritt fest, welches davon als Abschluss zählt.

Nach dem MQTT-5.0-Standard sendet ein Empfänger bei QoS 1 PUBACK, sobald er die Verantwortung für die Nachricht übernommen hat (Abschnitt 4.3.2). Das belegt weder die Verarbeitung durch Abonnenten noch eine Speicherung in nachgelagerten Datenbanken. Prüfen Sie den PUBACK-Reason-Code (Abschnitt 3.4.2.1): 0x00 steht für Success. Auch 0x10 No matching subscribers gilt als Erfolgscode: Der Broker hat eine Nachricht angenommen, die kein Abonnent empfängt. Codes ab 0x80 sind Fehler, etwa 0x87 Not authorized und 0x97 Quota exceeded. Der Leitfaden zur MQTTS-Inbetriebnahme behandelt Transport- und Identitätsprüfungen.

Bei Wiederholungsversuchen können Duplikate entstehen, wenn ein Empfänger einen Block festschreibt, der Absender den Erfolg aber nicht erfasst. Geben Sie jeder Beobachtung eine stabile Identität und gestalten Sie die Übernahme idempotent. Edge bildet Outbox-Schlüssel aus Ziel, Export-ID, Sensor-ID, Zeitstempel und Wert. Eine wiederholte Fehlermeldung erzeugt damit keinen zweiten Eintrag; ein korrigierter Wert zum selben Zeitstempel ist jedoch ein neuer Datensatz. Der Empfänger braucht eine eigene Regel. Ein Upsert nach Quelle, Kanal und Zeitstempel bewahrt die neueste Korrektur; ein Insert, der Konflikte auf demselben Schlüssel ignoriert, bewahrt den ersten Wert. Wählen Sie dies bewusst und behandeln Sie verspätete und ungeordnet eintreffende Messwerte entsprechend.

Die erneute Zustellung ist nur so gut wie der Zeitstempel jedes Messwerts. Ist die Uhr beim Stempeln falsch, etwa nach einem Stromausfall und vor abgeschlossener Zeitsynchronisierung, stellt Edge die falsche Uhrzeit unverändert zu und das Ziel ordnet den Wert dem falschen Zeitraum zu. Speichern Sie die Eintreffzeit neben der Messzeit, damit die Abweichung sichtbar wird. Ändern Sie den ursprünglichen Zeitstempel eines alten Messwerts niemals, um eine erneute Zustellung aktuell erscheinen zu lassen.

Aufbewahrung, Dauerhaftigkeit und Backup

Aufbewahrung legt fest, wie lange jede Datensatzklasse bestehen bleibt. Definieren Sie dies für Rohwerte, Aggregate, Ereignisse, Konfigurationen, ausstehende Zustellungen und Backups getrennt. Eine verkürzte Frist kann benötigte Belege entfernen; eine verlängerte Frist bringt bereits verfallene Daten nicht zurück.

Wählen Sie Aggregate passend zur Entscheidung, die sie unterstützen sollen. Ein Intervallmittelwert kann eine kurze Spitze verbergen. Ein kumulativer Energiezähler erfordert Behandlung von Rücksetzung und Überlauf; die Summe seiner abgelesenen Zählerstände ergibt keinen Energieverbrauch. Bewahren Sie Einheit, Intervallgrenzen, Abdeckung durch Messwerte und die Version der Umrechnung bei jeder Zusammenfassung auf.

Dauerhaftigkeit legt fest, welche bestätigten Schreibvorgänge einen bestimmten Fehler überstehen. Sie hängt vom gesamten Schreibpfad ab. Die SQLite-Dokumentation zu synchronous zeigt den Unterschied: Im WAL-Modus mit synchronous=FULL synchronisiert SQLite das Write-Ahead-Log nach jedem Commit; eine festgeschriebene Transaktion übersteht einen Stromausfall. Mit synchronous=NORMAL bleibt die Datenbank konsistent, eine unmittelbar vor dem Stromausfall festgeschriebene Transaktion kann nach dem Neustart aber zurückgesetzt sein.

Backup und Wiederherstellung dienen der Erholung nach Beschädigung, Löschung oder Verlust. Eine zweite Kopie auf demselben Datenträger übersteht dessen Ausfall nicht. Replikation übernimmt unerwünschte Änderungen genauso schnell wie erwünschte. Vereinbaren Sie einen Recovery Point Objective (größte zulässige Datenlücke nach Wiederherstellung) und einen Recovery Time Objective (längste zulässige Zeit bis zur Wiederaufnahme des Betriebs).

Sichern Sie einen laufenden Speicher mit seinem eigenen Konsistenzmechanismus. vmbackup kopiert aus sofortigen Snapshots, sodass VictoriaMetrics nicht angehalten werden muss. Ein Backup einer Einzelknoten-Installation von VictoriaMetrics kann nicht in einen Cluster zurückgespielt werden, und umgekehrt. Halten Sie Kopien in einer getrennten Ausfallzone, schützen Sie Zugangsdaten und erproben Sie Wiederherstellungen auf einem isolierten Ziel.

Prüfen Sie bei Edge für die installierte Version, welche Bestandteile der gewählte Backup-Umfang zurückbringt: Telemetrieverlauf, Begleitdienste, Funkstatus und Hostkonfiguration sind nicht in jedem Umfang enthalten. Beweisen Sie die Wiederherstellung mit einem Testlauf. Ein erfolgreicher Upload zeigt nur, dass eine Sicherungsdatei vorhanden ist.

Speicherpfad in Betrieb nehmen

Benennen Sie vor der Ausweitung über ein Pilotprojekt hinaus eine verantwortliche Person für die Speicherarchitektur und führen Sie diese Prüfungen durch:

1. Erfassung und Verlauf nachweisen. Verfolgen Sie eine bekannte Quelle samt Wert, Einheit und Zeitstempel bis in die erforderlichen lokalen und zentralen Abfragen.
2. Zustellung unterbrechen. Sperren Sie ein Ziel. Erfassen Sie Wachstum der Warteschlange, den ältesten ausstehenden Messwert, Datenträgerbelegung und die für Bediener sichtbare Störmeldung.
3. Verbindung wiederherstellen. Prüfen Sie, dass der Rückstand abgebaut wird, während aktuelle Werte weiter eintreffen. Vergleichen Sie danach die Datensätze der Zielplattform für den Ausfallzeitraum mit der Quelle.
4. Duplikate und verspätete Daten testen. Stellen Sie sicher, dass erneute Zustellung Messwerte weder doppelt zählt noch Messzeit durch Eintreffzeit ersetzt.
5. Wiederherstellung erproben. Nutzen Sie ein Testsystem. Halten Sie den Dienst an und trennen Sie dann bei eintreffenden Messwerten die Stromversorgung. Stellen Sie ein Backup wieder her. Erfassen Sie verlorene Zeiträume und die benötigte Zeit.
6. Laufende Zuständigkeit festlegen. Benennen Sie Verantwortliche für fehlende Messwerte, Alter der Warteschlange, Speicherplatz, Backupfehler, Zugriff, Aufbewahrung und Löschung.

Beginnen Sie bei einer EpiSensor-Installation mit den lokalen Funktionen von Edge und den Plattformintegrationen. Sind Zielplattform oder Aufbewahrungsbedarf noch offen, besprechen Sie die Installation anhand der Kanalzahl, Meldeintervalle, erforderlichen Abfragefenster, geplanten Ausfalldauer und Wiederherstellungsziele.