Datenbankinhalte effizient auslesen (Seite 2)

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 [9], ein Lenovo ThinkEdge [10], eine kleine virtuelle Maschine oder ein passend vorbereiteter Container via Docker [11] oder Podman [12].

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 sendet anschließend seine erfassten Daten in regelmäßigen Abständen über das Netzwerk an das DBMS, etwa via Long Range Wide Area Network (LoRaWAN) [13].

Passendes DBMS wählen

Ein DBMS unterstützt Sie dabei, Daten strukturiert zu speichern und die Daten mithilfe von Anfragen wieder auszulesen. Wikipedia [14] 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 [18]. 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 [19], RSQL [20], PostgreSQL, Zope [21], CouchDB [22] oder MongoDB [23] 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 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 [24], DBD:pg [25] für Perl oder für Python die Konnektoren Psycopg2 [26], Py-postgresql [27] und Pg8000 [28]. 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 TCP- oder 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.