Lesezeit ca. 12 Min.
arrow_back

Gehäusedeckel aufschrauben


Logo von Raspberry Pi Geek
Raspberry Pi Geek - epaper ⋅ Ausgabe 6/2022 vom 07.04.2022

Artikelbild für den Artikel "Gehäusedeckel aufschrauben" aus der Ausgabe 6/2022 von Raspberry Pi Geek. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Raspberry Pi Geek, Ausgabe 6/2022

README Daten sammeln und speichern – das können viele Tools problemlos. Auf diese Daten effizient zuzugreifen ist schon etwas kniffliger. Wir zeigen hier anhand eines skalierbaren, datenbankgestützten Messsystems für Wetter-und Umweltdaten, wie Sie das sauber und vor allem einfach implementieren.

Ausgangspunkt für diesen Beitrag ist ein Raspberry Pi ab Version 2, der als Hardware für eine einzelne Messstation für Wetter-und Umweltdaten fungiert. Michael Bilger hat dazu bereits mehrere Beiträge↪ auf seinem Blog ↪veröffentlicht, die als Anregung zur technischen Umsetzung dienen können. Der Autor experimentiert dabei mit verschiedenen Sensoren sowie mit Python-Skripten, um die erfassten Daten auszulesen und anschließend anzuzeigen. Bei Bedarf ließe sich das Ganze mit einem Feinstaubsensor ↪erweitern, wie Sie ihn etwa vom Projekt Luftdaten.info↪aus Stuttgart beziehen können.

Wir gehen hier aber nicht ...

Weiterlesen
epaper-Einzelheft 9,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Raspberry Pi Geek. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1050 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 6/2022 von 10 tolle Jahre. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
10 tolle Jahre
Titelbild der Ausgabe 6/2022 von Abfrageblocker. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Abfrageblocker
Titelbild der Ausgabe 6/2022 von Log-Auswerter. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Log-Auswerter
Titelbild der Ausgabe 6/2022 von Ausgepackt. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Ausgepackt
Mehr Lesetipps
Blättern im Magazin
Zwergwale
Vorheriger Artikel
Zwergwale
README
Nächster Artikel
README
Mehr Lesetipps

... auf die Hardware und deren Zusammenbau samt Software-Stack ein, sondern betrachten ausschließlich den Anteil für das Datenbankmanagementsystem (DBMS). Das ermöglicht es, mithilfe einzelner Sensoren die empfangenen Daten wie Temperatur, Luftfeuchtigkeit und Staubpartikel zu speichern und danach wieder effektiv auszulesen. Um den Themenbereich Datenbanken zu verstehen, hilft es, sich mit den Grundbegriffen vertraut zu machen (siehe Tabelle Begriffe).

Knackpunkt ist dabei die geschickte Lastverteilung zwischen der Software auf der Messstation und dem DBMS. Neben der Frage, welches DBMS für den konkreten Anwendungsfall das richtige ist, steht die nach der Tabellenanzahl und ‐struktur an, sprich: nach der Anzahl der Spalten, deren Anordnung in der Datenbank, dem pro Spalte verwendeten Datentyp und der Verknüpfung der Tabellen untereinander (Indexe).

Die Qualität der Datenbankabfrage (Query) basiert auf der zuvor festgelegten Tabellenstruktur und bestimmt die Antwortzeit und Datenmenge des DBMS und somit die gesamte Performance der Softwarelösung. Im Beispiel kam das DBMS PostgreSQL ↪ zum Einsatz. Dazu schrauben wir dessen virtuellen Ge-häusedeckel ab und bewegen uns in die Interna von PostgreSQL. Wie Sie sehen werden, sind die Möglichkeiten umfassender als zunächst vielleicht gedacht.

Grundlegende Struktur

Ausschlaggebend für die Performance einer Softwarelösung ist deren Aufbau und Struktur sowie die Art und Weise der Kommunikation mit dem DBMS. Etabliert hat sich das Client-Server-Modell, in dem das DBMS als Server fungiert und die Anwendung als Client, der die Daten an den Server übermittelt oder von dort liest.

Ob Sie als Bedienschnittstelle (Interface) die Kommandozeile oder eine GUI wie PhpMyAdmin↪ oder PgAdmin ↪verwenden, ist insofern relevant, als jede grafische Anwendungsschicht – selbst wenn sie das Bedienen vereinfacht – weitere Zeit kostet und Sie somit das Resultat auf ihre Anfrage später erhalten.

Zu klären ist, welche Funktionalität Sie auf das DBMS abwälzen. Das birgt die Fragen: Was will ich an Daten auslesen? Wie sollen die Daten im Ergebnis angeordnet sein, und was möchte ich mit den erhaltenen Daten tun?

Bei einer einfachen Anfrage brauchen Sie wenig Gehirnschmalz, und das DBMS hat wenig Arbeit damit. In der Regel liefert es dabei aber als Resultat sehr viele Daten an den Client, die Sie dann wieder auseinanderdividieren müssen. Große Datenmengen zwischen dem DBMS und ihrer Softwareanwendung schieben also die Hauptlast auf Letztere und die (Netzwerk-)Verbindung zwischen beiden.

Komplexere Anfragen erfordern zunächst mehr Nachdenken, kitzeln aber mehr Leistung aus dem DBMS heraus und liefern spezialisierte Ergebnisse (Daten). Daraus resultieren geringere Datenmengen zwischen dem DBMS und der Anwendung sowie eine insgesamt ausgeglichenere Lastverteilung zwischen beiden Komponenten.

PostgreSQL ist für komplexe Anfragen ausgelegt und bedient diese mithilfe von eingebauten Funktionen, Indexes, Joins, Subqueries, Triggern, Views sowie Stored Procedures. Damit übernimmt es bei Bedarf einen Großteil der Last und Komplexität ihrer Softwarelösung.

Listing 1 zeigt zwei Anfragen in der Structured Query Language (SQL), die vorwiegend von relationalen DBMS genutzt wird. SQL passt jedoch nicht für alle Anwendungsfälle. Für Graph-Datenbanken existiert eine eigene Anfragesprache namens GraphQL ↪, die auf der Struktur von JSON basiert.

Im Beispiel aus Listing 1 sehen Sie oben eine allgemeine Anfrage nach allen Inhalten aus der Tabelle sensor­ Data, darunter eine sehr spezialisierte Anfrage nach den beiden Spalten timestamp und temperature aus der Tabelle sensorData, wobei timestamp den Wert

2022‐02‐01:*12:30:00 besitzen muss. Somit liefert das DBMS nur die beiden Spalten der Datensätze für den angegebenen Zeitpunkt zurück, die exakt dieser Bedingung entsprechen.

Unsere Empfehlung für ein simples Design des Messnetzes ist, den Client zum Erfassen der Daten jeweils auf einen RasPi zu packen und den Server mit dem DBMS als zentrale Komponente im Netzwerk auszulegen. Infrage kommen dafür etwa ein ALIX-Board von PC Engines ↪, ein Lenovo ThinkEdge ↪, eine kleine virtuelle Maschine oder ein passend vorbereiteter Container via Docker↪oder Podman↪ .

Die Größe der zentralen Komponente hängt davon ab, wie viele Messstationen sich im Netz befinden und wie fleißig diese Daten sammeln. Jeder Client sen-det anschließend seine erfassten Daten in regelmäßigen Abständen über das Netzwerk an das DBMS, etwa via Long Range Wide Area Network (LoRaWAN) .

Passendes DBMS wählen

Ein DBMS unterstützt Sie dabei, Daten strukturiert zu speichern und die Daten mithilfe von Anfragen wieder auszulesen. Wikipedia↪ listet über 40 verschiedene DBMS auf, die über die vergangenen 60 Jahre entwickelt wurden und dabei verschiedenste Prinzipien zur internen Ablage der Daten implementieren – etwa in relationaler oder objektrelationaler Art und Weise, als XML-Datensatz, dokumentenbasiert oder als Graphen (siehe Tabelle DBMS-Typen).

Mitunter werden verschiedene Prinzipien in einem DBMS miteinander kombiniert, das sich dann nicht mehr eindeutig einer einzigen Kategorie zuordnen lässt. Die Systeme unterscheiden sich aber weiterhin anhand der Art und Weise, wie sie die Daten auf dem Datenträger selbst ablegen: Während Oracle Database ein rohes Speichermedium beansprucht, benutzen die anderen DBMS eine dateibasierte Struktur, sprich: Sie benötigen einen Datenträger mit einem bestehenden Dateisystem.

Wie oben schon genannt, spielt es eine Rolle, ob das DBMS nur als lokales Programm läuft (Fall A), verteilt konzipiert ist (Fall B) oder dem Client-Server-Prinzip folgt (Fall C). Im Fall A erfasst und speichert jede Messstation die Daten separat, etwa mithilfe von SQLite ↪. Im Fall B verteilen sich das Erfassen der Daten und das DBMS über mehrere Computer und Speichermedien hinweg. Im Fall C hingegen findet nur die Erfassung auf der jeweiligen Messstation statt, und die Daten laufen auf einem zentralen Knoten zusammen. Hier bieten sich MySQL/​MariaDB↪ , RSQL↪ , PostgreSQL, Zope↪, CouchDB ↪oder MongoDB ↪an.

Zur Budgetierung des Messnetzes sind das Lizenzmodell und die damit verbundenen, möglichen Beschränkungen des DBMS zu klären. Je nach ausgewähltem kommerziellem DBMS regelt unter anderem der Lizenzvertrag, wie viele Instanzen Sie nutzen dürfen, wie viele Datenbanken Sie überhaupt pro DBMS anlegen dürfen und wie viele Benutzer darauf zugreifen können.

Den Preis bestimmen auch die Anzahl der benutzbaren Prozessoren/​Cores, die Zeilen und Spalten pro Tabelle sowie die Anzahl der Transaktionen in einem bestimmten Zeitraum. Hier spielt freie Software ihre Stärken aus, da hier solche Einschränkungen in der Regel nicht bestehen. Ein weiteres Entscheidungskriterium für oder gegen ein bestimmtes DBMS ist zudem, welche Schnittstellen und APIs zwischen der Anwendung und dem DBMS bestehen.

Für PostgreSQL als DBMS spricht hier, dass nahezu alle Programmiersprachen passende, stabile Bibliotheken zum Download oder als fertige Pakete für Pi OS (das auf Debian GNU/​Linux basiert) bereitstellen – sei es für C die Libpq ↪, DBD:pg↪ für Perl oder für Python die Konnektoren Psycopg2↪ , Py-postgresql ↪und Pg8000↪ . Alle Schnittstellen sind dokumentiert, sodass einer individuellen Softwarelösung nichts mehr im Weg steht.

PostgreSQL ist seit Längerem sehr stabil, bietet Transaktionssicherheit, besitzt eine überschaubare Größe, ist flexibel als Einzel-oder verteiltes System benutzbar (Datenbank-Cluster), benutzt standardkonformes SQL und verfügt über alle Funktionen, die im vorliegenden Projekt erforderlich sind. Das ist für den Einsatz hier ausschlaggebend.

Datenmengen abschätzen

Die Messstationen liefern in der Regel eine überschaubare Menge an Daten, das aber in regelmäßigen Intervallen. Das führt zu der Frage, wie viele Sensor-und Netzwerkdaten in einem bestimmten Zeitraum anfallen, wie viel Speicherplatz im DBMS vorgehalten werden muss und wie viele Daten auf dem Weg von der Messstation zum DBMS verloren gehen dürfen.

Die Antwort auf diese Fragen hat direkte Auswirkung auf die Dimensionierung des zentralen Knotens in Bezug auf die Netzwerkanbindung, die Art und Weise der Datenübermittlung (als TCPoder UDP-Paket), den gewählten Typ und die benötigte Größe des Speichermediums, die Ausfallsicherheit sowie den Stromverbrauch. Nachfolgend besprechen wir die erfassten Daten und deren Struktur genauer, was überhaupt erst eine Abschätzung über die einzelnen Größen ermöglicht.

Speicherstrukturen

Eine der Kernfragen besteht darin, ob Sie die Daten in eine oder mehrere Tabellen aufteilen, welche Datentypen am besten für jede Spalte auszuwählen und wie die Spalten am besten anzuordnen sind, sodass sich die Zugriffszeit des DBMS auf die Tabellen minimiert.

Wie oben beschrieben, besteht das Messnetz aus mehreren Stationen, die über das Gebiet verteilt sind. Daher bietet sich eine Zweiteilung an – eine Tabelle station für die Verwaltung der einzelnen Messstationen und eine Tabelle sensor­ Data für die erfassten Messdaten.

Die Tabelle Datenbanktabelle station zeigt die Struktur der gleichnamigen Datenbanktabelle. Die Einteilung erlaubt eine flexible Handhabung des Messnetzes. Jede Station hat eine Kennung in Form einer eigenen ID, über die Sie Daten eindeutig referenzieren.

Das erlaubt es, die Informationen zu den Messstationen zentral zu ändern, falls neue hinzukommen, bestehende entfernt werden oder sich deren Ausstattung oder Position ändert. Jede Messstation liefert die folgenden Daten an das DBMS, die in der Tabelle namens sensorData erfasst werden.

Die in den beiden Tabellen gewählten Datentypen↪sind auf ein Messnetz mit bis zu 32 767 Messstationen zugeschnitten. Sollte das nicht ausreichen, wählen Sie für ID als Datentyp Serial (4 Bytes Länge) oder Bigserial (8 Bytes Länge). Das ermöglicht dann ein Messnetz aus gut 2 Milliarden beziehungsweise über 9 Trillionen Stationen. Beachten Sie dazu die Empfehlungen zur Anordnung der Spalten in den Tabellen (siehe Kasten Nacheinander).

Setzen Sie die ID der Messstation in der Tabelle sensorData an den Anfang der Struktur, vergrößert sich jeder Datensatz aufgrund des Auffüllens der ersten Spalte um 42 Bytes auf insgesamt 148 Bytes. Bei wenigen Messstationen fällt das nicht ins Gewicht, bei 30 000 Stationen schon – diese benötigen dann als Verwaltungsinformationen 4,2 MByte statt 3 MByte, also mehr als ein Drittel zusätzlich.

Bei der gewählten Struktur führt eine Änderung der Reihenfolge der Spalten nicht zu einer Größenänderung des Datensatzes. PostgreSQL benutzt für jede Spalte 8 Bytes. Ergänzen Sie jedoch ein oder mehrere Textfelder, fällt das sofort wesentlich ins Gewicht, insbesondere wenn PostgreSQL Tausende oder gar Millionen Datensätze verwaltet.

Die Verbindung zwischen den beiden Tabellen station und sensorData realisieren Sie über einen Fremdschlüssel namens stationId. Daraus ergeben sich die SQL-Statements zum Erzeugen der beiden Tabellen aus Listing 2.

Nacheinander

Die gewählte Reihenfolge der Spalten in der Tabelle wirkt zunächst willkürlich, ist aber anhand der Größe der Datentypen optimiert. Der Hintergrund: PostgreSQL geht intern von einer Länge von 8 Bytes pro Spalte aus und füllt nachfolgende Spalten mit fester Länge und unterschiedlicher Größe auf ↪Daher ist es vorteilhaft, große Spalten an den Anfang der Datenstruktur zu setzen. Als Datentyp für den Zeitstempel wählten wir TIMESTAMP, was Zeitzonen nicht mit berücksichtigt. Sollte das erforderlich sein, kennt PostgreSQL dafür den Datentyp TIMESTAMPTZ.

Alle SQL-Anweisungen erfolgen als eine abgeschlossene Transaktion. Aus diesem Grund sind sie im Beispiel durch die beiden Anweisungen BEGIN TRANS‐ACTION und COMMIT eingefasst. Erstere leitet die Transaktion ein, Letztere schließt sie ab. Die beiden Create-Anweisungen sind zudem um die Angabe IF NOT EXISTS erweitert. Dadurch legt die Datenbank die Tabellen nur an, wenn sie noch nicht existieren.

Ebenso ist jetzt eine erste Größenabschätzung zum benötigten Speicherplatz möglich. Bei 100 Messstationen benötigen Sie 10 KByte Verwaltungsinformationen in der Datenbank. Liefern die Messstationen alle 15 Minuten Messwerte, fallen etwa 15 KByte Daten pro Stunde an oder etwa 375 KByte pro Tag. In der Kalkulation eines Jahres sind somit Speicher-und Datenübertragungskosten für 135 MByte zu berücksichtigen.

Interne Strukturen

Was ein DBMS außerhalb des profanen Speicherns und Wiederfindens von Daten leistet, hebt es letztendlich aus der Masse hervor. Es gilt als aktiv, sofern es selbst über Views, Trigger, Funktionen, Stored Procedures und Event Handler verfügt. Als passiv gilt es hingegen, wenn solche Funktionen ein zusätzliches Programm erfordern. Zu Ersteren gehört neben PostgreSQL auch Maria DB, zu Letzteren RSQL, das unsere Schwesterzeitschrift LinuxUser in Ausgabe 01/​2018 vorgestellt hat ↪.

Mit einem View stellen Sie eine spezifische Sicht auf die Daten bereit. Den View benennen Sie zunächst und hinterlegen danach dazu eine SQL-Anweisung, die ausgeführt wird, sobald Sie den View aufrufen. Ein View lässt sich mit einem Alias in der Shell vergleichen. Er akzeptiert keine zusätzlichen Parameter im Aufruf.

Listing 3 zeigt einen View namens AverageParticleToday, der den durchschnittlich gemessenen Feinstaubwert für alle Sensoren für den aktuellen Tag ermittelt. Es benutzt dazu die PostgreSQL-eigene Funktion avg(), die den Durchschnitt von numerischen Werten errechnet.

Die beiden Angaben today und tomorrow in der Select-Anweisung sind spezielle Werte für Zeitstempel, die PostgreSQL in „heute, 00:00:00“ und „morgen, 00:00:00“ übersetzt. Das Schlüsselwort BETWEEN sorgt dabei für eine Bereichsbegrenzung von „heute, 00:00:00“ bis „heute, 23:59:59“ („morgen, 00:00:00“ minus 1 Sekunde).

Listing 4 zeigt den Aufruf des Views. Das Ergebnis ist eine Spalte value, die nur eine einzige Zeile besitzt: den vorab berechneten Durchschnittswert. Der Spaltenname wurde in der ersten Zeile von Listing 3 als Parameter in der Anweisung CREATE VIEW definiert.

Soll die Spalte im Ergebnis einen anderen Namen tragen, ändern Sie entweder den View aus Listing 3 oder geben der Spalte in der Select-Anweisung einen Alias. Listing 5 erzeugt durch Übergabe eines Alias eine Ergebnisspalte namens AverageParticles.

Der Nachteil von Views liegt darin, dass sie keine Aufrufparameter akzeptieren. Das schränkt die Flexibilität ein. Hier kommen benutzerdefinierte Funktionen oder Stored Procedures ins Spiel, die diesen Nachteil kompensieren. Beachten Sie aber: Stored Procedures stehen erst ab PostgreSQL 11 bereit. In einer Funktion können Sie zudem keine Transaktion beginnen (BEGIN TRANSACTION), abschließen (COMMIT) oder zurückrollen.

Funktionen und Stored Procedures haben außerdem zunächst keinen Rückgabewert (abgesehen vom Fehlercode zum Aufruf ). In Funktionen definieren Sie dazu eine Variable, in der Stored Procedure einen Cursor. Das Ergebnis ist dann eine Ergebnismenge, die intern als temporäre Tabelle implementiert ist ↪. Bei Funktionen bestimmen Sie den Datentyp der Ergebnismenge, bei Stored Procedures ist es immer der spezielle Datentyp↪ refcursor ↪.

In Listing 6 geht es diesmal nicht um Feinstaubpartikel, sondern um die Durchschnittstemperatur. Sie sehen nun eine Funktion namens AverageTemperatureSensor, die die durchschnittlich gemessene Temperatur für eine bestimmte Messstation für einen von Ihnen angegebenen Zeitraum ermittelt.

Als Parameter akzeptiert die Funktion die ID der Messstation sowie den Beginn und das Ende des Zeitraums (Zeile 2 bis 4). Der Rückgabewert ist ein Zahlenwert vom Datentyp REAL (Zeile 6).

Die Funktion selbst ist in PLPGSQL geschrieben (ab Zeile 7), wobei PostgreSQL auch andere Sprachen wie C oder Python akzeptiert.

Der Funktionsinhalt befindet sich in den Zeilen 9 bis 17 und besteht aus der Deklaration der Variablen AverageTemperature vom Datentyp REAL, aus einer Select-Anweisung und dem Beenden der Funktion samt Rückgabe der Berechnung. Zeile 12 sorgt dafür, dass das Ergebnis der Select-Anweisung in der Variablen AverageTemperature gespeichert wird. In Zeile 16 wird der errechnete Wert zurückgegeben.

Listing 7 zeigt den Aufruf der Funktion in PostgreSQL, der als Ergebnis die Spalte averagetemperature mit nur einer einzige Zeile (dem vorab berechneten Durchschnittswert) liefert. Im Listing sehen Sie zwei Aufrufe für die Messstation mit der ID 1, zuerst mit zwei festen Zeitwerten und danach für den aktuellen Tag mithilfe der beiden Schlüsselwörter today und tomorrow. Beim Aufruf der Funktion ermittelt PostgreSQL darüber den aktuellen Zeitpunkt und ersetzt die beiden Schlüsselwörter mit passenden Werten.

Performance-Tests

Ist die Datenbank fertig strukturiert und das Messnetz eingerichtet, kann es eigentlich mit dem Erfassen der Umweltdaten losgehen. Ratsam ist jedoch noch ein Performance-Test, um herauszufinden, ob die konzipierte Anwendung mit der prognostizierten Last überhaupt umgehen kann. Es wäre ja schlecht, wenn sich ein Flaschenhals offenbart, nachdem Sie Ihr Netz in der freien Wildbahn ausgerollt haben.

Danksagung

Die Autoren bedanken sich bei Julie Göschl und Axel Beckert für ihre Unterstützung bei der Vorbereitung dieses Artikels.

Was es jetzt braucht, sind Testdaten und Werkzeuge wie Pgbench↪ samt Ablauf für automatisierte Tests. Erstere erzeugen Sie entweder selbst oder greifen auf gesammelte Daten zurück. Sofern solche nicht vorrätig sind, bekommen Sie sie etwa von Meteostat ,↪↪ . Dieser spendenfinanzierte Dienst bietet Messwerte für Temperatur, Niederschlag, Windgeschwindigkeit, Windrichtung und Luftdruck zum Herunterladen an. Dazu kombiniert er Messwerte verschiedener Stationen im Umkreis, um ein realistischeres Ergebnis für die Region zu erhalten.

Abbildung1 1 zeigt den Temperaturverlauf für sieben Tage für die Region Neuenburg/​Neuchâtel in der Nordwestschweiz. Einbezogen in die Berechnung werden hier Stationen, die sich im Umkreis von etwa 50 bis 100 Kilometern um den Messpunkt befinden. Benachbarte Stationen sind etwa Payerne im Süden, Bern im Südosten, Grenchen im Nordosten und Montbéliard im Norden.

Fazit

Wie Sie gesehen haben, ist der Betrieb eines Messnetzes aus Datenbanksicht mit überschaubarem Aufwand möglich. Schwachpunkt im Beispiel ist der zentrale Knoten mit dem DBMS. Um die Ausfallsicherheit zu erhöhen, bestünde die Möglichkeit, die Datenbank auf einem

RAID (Redundant Array of Independent Disks) zu betreiben. Der Nachteil ist aber offensichtlich: Befinden sich alle Komponenten des RAIDs am selben Ort und der Strom fällt aus, ist das System trotzdem nicht zu erreichen.

Alternativ richten Sie einen Puffer für 48 Stunden auf den Messstationen ein. Damit überbrücken Sie einen Netzwerkausfall für diesen Zeitraum. Außerdem bietet es sich an, die Daten verteilt zu speichern oder in einem regelmäßigen Abgleich untereinander, über ein Meshnet oder mittels mehrerer Instanzen der PostgreSQL-Datenbank auszutauschen. Ein Raspberry Pi gibt das seitens der Hardware her. Oder Sie verwenden einen Anbieter für Datenspeicherung in der Cloud.

Alle diese Varianten führen zu Themen, die den Rahmen dieses Beitrags sprengen würden und die sich einzeln genauer beleuchten ließen. Geht es Ihnen um ein tieferes Verständnis des DBMS PostgreSQL, sind die Tutorials↪ ein guter Startpunkt zum Nachlesen. (agr) n

Die Autoren

Frank Hofmann arbeitet zumeist von unterwegs aus als Entwickler, Trainer und Autor. Er gehört zu den Verfassern des Debian-Paketmanagement-Buches. Der gebürtige Kanadier Gerold Rupprecht wohnt seit 25 Jahren in Genf und hat sich auf Finanzsoftware sowie die Evaluierung und Optimierung IT-bezogener Prozessabläufe spezialisiert.