Datenhaltung. Software ubiquitärer Systeme (SuS) Olaf Spinczyk.

Transkript

1 Software ubiquitärer Systeme (SuS) Datenhaltung Olaf Spinczyk AG Eingebettete Systemsoftware Informatik, TU Dortmund

2 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Anwendung/Programmierung Beispiel TinyDB Zusammenfassung Datenhaltung Middleware Betriebssystem Hardware SuS: 5. Datenhaltung

3 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung SuS: 5. Datenhaltung

4 Datenhaltung in ubiquitären Systemen Netzwerk SQL-Schnittstelle Prozess DBMS Prozess? Prozess Cache Datenbank Klassischer Datenbankserver Ubiquitäre Datenhaltung SuS: 5. Datenhaltung

5 Anforderungen Anwendungsfälle Mobiltelefone speichern Adressen, Zeiten für Benachrichtigungen, eingegangene Nachrichten MP-Player verwalten Playlists und Metadaten Kontextinformationen werden gesammelt, entsprechend einer Ontologie kategorisiert und Anwendung zur Verfügung gestellt. Netzwerk-Router verwalten ihre Verbindungen Notwendigkeiten Optimierung bzgl. Speicherplatz und Energieverbrauch Lokale Datenhaltung häufig ausreichend Teils Echtzeitfähigkeit oder Fehlertoleranz nötig Unterschiedliche Speichermedien Kaum Festplatten, sondern FLASH/EEPROM/Hauptspeicher-RAM SuS: 5. Datenhaltung 5

6 Typische Unterschiede () [] Speicher Klassisch: On-Disk Storage Datenbanken verwalten persistent Giga-, Tera-, oder Petabytes Aus Performance-Gründen Einsatz großer Caches im Hauptspeicher Ubiquitär: In-Memory-Storage Daten werden im Hauptspeicher verwaltet und nur bei Bedarf auf dem Hintergrundspeicher gesichert. Hohe Performance und geringer Ressourcenverbrauch, aber geringe Speicherkapazität. SuS: 5. Datenhaltung 6

7 Typische Unterschiede () Programmierschnittstelle Klassisch: SQL API Abfrage, Manipulation und Verwaltung erfolgen deklarativ in SQL Sehr mächtig und überall bekannt zügige Anwendungsentwicklung SQL-Engine ist eine Black Box und inzwischen extrem komplex Ubiquitär: Navigational API C/C++-API, um über die Datensätze zu iterieren Mehr Kontrolle Verbesserte Vorhersagbarkeit, bessere Performance SQL-Engine unnötig weniger Speicherplatzverbrauch SuS: 5. Datenhaltung 7

8 Typische Unterschiede () Architektur Klassisch: Client/Server Anwendungen benutzen Interprozess-Kommunikationsmechanismen, um die Datenbank abzufragen Mehrere Klienten können gleichzeitig mit der Datenbank arbeiten Selbst bei lokalen Betrieb wird IPC verwendet Overhead Ubiquitär: Embedded Datenbank und Anwendung bilden eine Einheit. Die Datenbank ist in die Anwendung eingebettet. Einfache Struktur Weniger Kontextwechsel Geringerer Ressourcenverbrauch Bessere Vorhersagbarkeit bessere Performance Achtung Achtung Mehrdeutigkeit: Mehrdeutigkeit: Eingebettete Eingebettete Datenbanken Datenbanken sind sind nicht nicht notwendigerweise notwendigerweise Datenbanken Datenbanken für für eingebettete eingebettete Systeme. Systeme. SuS: 5. Datenhaltung 8

9 Begriff: Eingebettete Datenbanken Definition nach Margo Seltzer, Sleepycat Software: Embedded Database: A Working Definition Embedded in an application. End-user transparency. Instant recovery required. Database administration is managed by application (not DBA). Not necessarily the same as mobile applications SuS: 5. Datenhaltung 9

10 Datenhaltung in ubiquitären Systemen Applikation Netzwerk Funktion Funktion SQL-Schnittstelle Prozess Prozess Navigational API Prozess Funktion DBMS Funktion Funktion Cache DBMS Datenbank Datenbank Klassischer Datenbankserver Ubiquitäre Datenhaltung SuS: 5. Datenhaltung 0

11 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung SuS: 5. Datenhaltung

12 Oracle Berkeley DB Most widely deployed open source, embeddable database in the world (Oracle) Eine eingebettete Datenbank im doppelten Sinn Sehr klein und effizient Läuft direkt im Anwendungsadressraum Speichert Anwendungsdaten direkt Keine SQL-Zugriffsschicht Open Source Ray van Tassle, Senior Staff Engineer, Motorola Berkeley DB was 0 times faster than other databases. It has the operational speed of a main memory database, the startup and shut down speed of a disk-resident database, and does not have the overhead of a client-server inter-process communication. Quelle: Oracle SuS: 5. Datenhaltung

13 Oracle Berkeley DB: Eigenschaften Schnelle indexbasierte oder sequentielle Suche BTree, Queue, Recno, Hash Transaktionen und Logging Locking bei mehrfädigen Programmen Single Master Replication Unterstützt verteilte Transaktionen (XA-Standard) Optionale AES-Verschlüsselung von Daten auf Platte Sprachen: C, C++, Java und verschiedene Skriptsprachen Plattformen: UNIX, Linux, MacOS X, Windows, VxWorks, QNX, und andere (POSIX-konform) SuS: 5. Datenhaltung

14 Oracle Berkeley DB: Schnittstelle Tabellen sind einfache Key/Value-Paare Key fruit Value apple sport cricket drink water Ein Datum kann auch Key einer anderen DB sein // Anlegen einer Datenbank in C++ DB *dbp; db_create(&dbp, NULL, 0)); dbp->open(dbp, SuS.db, NULL, DB_BTREE, DB_CREATE, 066)); // Einfuegen eines Tupels DBT key, data; memset(&key, 0, sizeof(key)); memset(&data, 0, sizeof(data)); key.data = "fruit"; key.size = sizeof("fruit"); data.data = "apple"; data.size = sizeof("apple"); dbp->put(dbp, NULL, &key, &data, 0)); Erlaubt mehrere Indizes für Daten und Joins SuS: 5. Datenhaltung

15 Oracle Berkeley DB: Codegröße Das System ist für größere ubiquitäre Systeme durchaus geeignet und grobgranular konfigurierbar. Daten von 999: Object Size in Bytes Text Access Methods (total) Data Lines BSS of Code Locking Logging Transactions/Recovery Include Total Quelle: Margo Seltzer, Sleepycat Software Daten von heute (Oracle): Object Size SuS: 5. Datenhaltung 5

16 Oracle Berkeley DB: Fazit Das Beispiel zeigt was eine eingebettete Datenbank ist typische Eigenschaften von Datenhaltungssystemen für ubiquitäre Systeme: Keine SQL-API Datenhaltung im Hauptspeicher Keine Client/Server-Architektur den Stand der Kunst und dass diese auch für viele eingebettete/ubiquitäre Systeme das Mittel der Wahl sind. Berkeley DB findet sich tatsächlich in vielen Anwendungen wieder wie aus einer universitären Entwicklung ein Produkt werden kann Der Kern von Berkeley DB stammt noch vom. BSD UNIX SuS: 5. Datenhaltung 6

17 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Beispiel TinyDB* Zusammenfassung *Folien teils abgeleitet aus diversen Präsentationen von Samuel Madden et al SuS: 5. Datenhaltung

18 TinyDB: Motivation Die Programmierung von Sensornetzwerken ist schwierig Deklarative Anfragen sind einfach Beispiel: Straßenbeobachtung Handgeschriebener Code - Wochen Entwicklungszeit Hunderte von Zeilen C-Code TinyDB-Anfrage Minuten Entwicklungszeit Vergleichbare Funktionalität SELECT nodeid FROM sensors WHERE mag > thresh EPOCH DURATION 6ms SuS: 5. Datenhaltung 8

19 TinyDB: Idee Hohe Abstraktionsebene Datenzentrierte Programmierung Interaktion mit dem Netzwerk als Ganzes SELECT nodeid FROM sensors WHERE mag > thresh EPOCH DURATION 6ms App Unter der Haube Erweiterbarkeit Anfrageoptimierung Effiziente Ausführung Query, Trigger Data TinyDB Sensor Network SuS: 5. Datenhaltung 9

20 TinyDB: Anfragesprache (TinySQL) Die Die Sprache Sprache orientiert orientiert sich sich an an SQL SQL und und ist ist damit damit leicht leicht zu zu erlernen. erlernen. Komplexe Komplexe Spracheigenschaften Spracheigenschaften wurden wurden weggelassen. weggelassen. SELECT <aggregates>, <attributes> [FROM {sensors <buffer>}] [WHERE <predicates>] [GROUP BY <exprs>] [EPOCH DURATION <const> ONCE] [INTO <buffer>] [TRIGGER ACTION <command>] Neuartig Neuartig ist ist der der Ansatz Ansatz des des Acquisitional Acquisitional Data Data Processing, Processing, der der sich sich im im unteren unteren Teil Teil widerspiegelt widerspiegelt (EPOCH (EPOCH DURATION DURATION ). ) SuS: 5. Datenhaltung 0

21 TinyDB: Datenmodell Das gesamte Sensornetzwerk bildet eine einzige, potentiell beliebig lange Tabelle: sensors Spalten bestehen aus Attributen, die für das Netzwerk statisch definiert werden Typische Attribute sind Sensorwerte Meta-Daten: Knoten-ID, Position, Interne Zustände: Routing-Informationen, Zeitstempel, Wenn ein Attribut auf einem Knoten nicht existiert, wird NULL als Wert geliefert SuS: 5. Datenhaltung

22 TinyDB: Beispiele () Finde Sensoren in hellen Nestern SELECT nodeid, nestno, light FROM sensors WHERE light > 00 EPOCH DURATION s Epoch Sensors nodeid nestno light Die Die Epoch Epoch Duration Duration definiert definiert die die Häufigkeit Häufigkeit der der Abfragen. Abfragen. Daten Daten sind sind nicht nicht per per se se vorhanden, vorhanden, sondern sondern werden werden für für die die jede jede Abfrage Abfrage ermittelt ermittelt ( acquisitional ). ( acquisitional ). Das Das Ergebnis Ergebnis ist ist ein ein Datenstrom. Datenstrom SuS: 5. Datenhaltung...

23 TinyDB: Beispiele () SELECT AVG(sound) FROM sensors EPOCH DURATION 0s Zähle die belegten Nester in jeder lauten Region der Insel AVG(<Attribut>) AVG(<Attribut>) aggregiert aggregiert N N Ergebnisse zu deren Durchschnitt. Ergebnisse zu deren Durchschnitt. Regionen Regionen mit mit AVG(sound) AVG(sound) >> SELECT region, CNT(occupied), AVG(sound) FROM sensors GROUP BY region HAVING AVG(sound) > 00 Epoch region CNT(...) AVG(...) 0 North 60 0 South 50 EPOCH DURATION 0s North 70 South SuS: 5. Datenhaltung

24 TinyDB: Anfragen mit Gedächtnis Storage Points erlauben lokale Speicherung von Sensordaten CREATE STORAGE POINT recentlight SIZE 8 AS (SELECT nodeid, light FROM sensors EPOCH DURATION 0s) Anfragen können Inhalte von Storage Points einbeziehen SELECT COUNT(*) FROM sensors AS s, recentlight AS rl WHERE rl.nodeid = s.nodeid AND s.light < rl.light EPOCH DURATION 0s SuS: 5. Datenhaltung Liefert Liefert die die Anzahl Anzahl der der gespeicherten Helligkeiten, gespeicherten Helligkeiten, die die größer größer als als der der aktuelle aktuelle Wert Wert sind. sind.

25 TinyDB: Ereignisse Idee: Anfrage erfolgt, wenn etwas Interessantes passiert ON EVENT bird-detect(loc): SELECT AVG(light), AVG(temp), event.loc FROM sensors AS s WHERE dist(s.loc, event.loc) < 0m EPOCH DURATION s FOR 0s Sobald Sobald ein ein Vogel Vogel in in einem einem Nest Nest landet, landet,sendet sendet der der entsprechende entsprechende Knoten Knoten die die Anfrage Anfrage an an die die umgebenden umgebenden Knoten Knoten (Abstand (Abstand << 0m), 0m), liest liest die die Ergebnisse Ergebnisse für für 'light' 'light' und und 'temp' 'temp' und und liefert liefert die die Durchschnitte zurück. Durchschnitte zurück. Ereignisse können anwendungsspezifisch definiert werden Das passiert unterhalb der TinySQL-Ebene SuS: 5. Datenhaltung 5

26 TinyDB: Innenleben SELECT SELECT AVG(temp) AVG(temp) WHERE WHERE light>00 light>00 Anfragen Resultate Multihop Netzwerk Epoch AVG(...) Anfrageprozessor Aggavg(temp) Filterlight > 00 Name: temp Time to sample: 50 µs get('temp') Tables Samples got('temp') Cost to sample: 90 µj Calibration Table: Schema Units: Deg. F gettempfunc(...) TinyOS Error: ± 5 Deg F Get f : gettempfunc() TinyDB SuS: 5. Datenhaltung 6

27 TinyDB: Innenleben SELECT SELECT AVG(temp) AVG(temp) WHERE WHERE light>00 light>00 Anfragen Resultate Multihop Netzwerk Epoch AVG(...) ~0.000Anfrageprozessor Zeilen C-Code Aggavg(temp) ~5.000 Zeilen Java (PC-Seite) ~00 Bytes (mit 768 Byte Heap) FilterlightRAM > 00 Name: temp ~58 KB übersetzter Code Time to sample: 50 µs get('temp') Tables Samples got('temp') Cost to sample: 90 µj (x größer Schema als das zweitgrößtecalibration TinyOS-Programm) Table: gettempfunc(...) Units: Deg. F Error: ± 5 Deg F Get f : gettempfunc() TinyOS TinyDB SuS: 5. Datenhaltung 7

28 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für Anfrageverarbeitung, Datensammlung und Aggregation Q:SELECT B A C D F E SuS: 5. Datenhaltung 8

29 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für Anfrageverarbeitung, Datensammlung und Aggregation Q:SELECT Q B A Q C D F E SuS: 5. Datenhaltung 9

30 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für Anfrageverarbeitung, Datensammlung und Aggregation Q:SELECT A R:{ } R:{ } Q B C Q Q Q Q D F E SuS: 5. Datenhaltung 0

31 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für Anfrageverarbeitung, Datensammlung und Aggregation Q:SELECT A R:{ } R:{ } B C R:{ } D Q R:{ } Q Q Q F E SuS: 5. Datenhaltung Q

32 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für Anfrageverarbeitung, Datensammlung und Aggregation Q:SELECT A R:{ } R:{ } B C R:{ } D R:{ } R:{ } F E SuS: 5. Datenhaltung

33 TinyDB: Energiesparen Das Sparen von Energie ist das zentrale Thema beim Betrieb von Sensornetzwerken. TinyDB spart Energie durch diverse Techniken [] Anwendungsabhängiger Duty-Cycle Aggregation im Sensornetzwerk Optimierte Ordnung der Messungen und Prädikate Acquisitional Query Processing SuS: 5. Datenhaltung

34 TinyDB: Power Management Grobgranulare, anwendungsgesteuerte Kommunikationsund Schlafphasen Epoche (Sekunden bis Stunden) Knoten ID zzz zzz 5 Zeit wenige Sekunden Wachphase SuS: 5. Datenhaltung

35 TinyDB: Zeitsynchronisation Alle Nachrichten enthalten einen 5-Byte-Zeitstempel (Systemzeit in ms) Aktualisierung der eigenen Zeit bei beliebigen Nachrichten vom Elternknoten jeder neuen Anfrage (auch von anderen Knoten Ereignisbehandlung) Beginn der Wachphase: <Systemzeit> % <Dauer der Epoche> == 0 Zur Synchronisation der Knoten wird die Dauer der Schlafphase angepasst SuS: 5. Datenhaltung 5

36 TinyDB: Aggregation () SELECT SELECT COUNT(*) COUNT(*) FROM FROM sensors sensors erfolgt im Sensornetzwerk Deutliche Reduktion des Kommunikationsaufwandes! Intervall Sensor # Epoche Intervall # SuS: 5. Datenhaltung 5 6

37 TinyDB: Aggregation () SELECT SELECT COUNT(*) COUNT(*) FROM FROM sensors sensors erfolgt im Sensornetzwerk Deutliche Reduktion des Kommunikationsaufwandes! Intervall Sensor # Epoche Intervall # SuS: 5. Datenhaltung 7

38 TinyDB: Aggregation () SELECT SELECT COUNT(*) COUNT(*) FROM FROM sensors sensors erfolgt im Sensornetzwerk Deutliche Reduktion des Kommunikationsaufwandes! Intervall Sensor # Intervall # Epoche SuS: 5. Datenhaltung 5 8

39 TinyDB: Aggregation () SELECT SELECT COUNT(*) COUNT(*) FROM FROM sensors sensors erfolgt im Sensornetzwerk 5 Deutliche Reduktion des Kommunikationsaufwandes! Sensor # Intervall Epoche Intervall # SuS: 5. Datenhaltung 5 9

40 TinyDB: Aggregation () SELECT SELECT COUNT(*) COUNT(*) FROM FROM sensors sensors erfolgt im Sensornetzwerk Deutliche Reduktion des Kommunikationsaufwandes! Intervall Sensor # Epoche Intervall # SuS: 5. Datenhaltung 5 0

41 TinyDB: Aggregation () Zuordnung des Intervalls: Tiefe im Baum = Intervall Die feste Zuordnung erlaubt verlängerte Schlafphasen Sensor # Intervall Epoche Intervall # sc L 5 n e f hla L L 5 sc n e f hla L L: Listen - Der Knoten muss lauschen SuS: 5. Datenhaltung 5

42 TinyDB: Aggregation () Nicht alle Aggregationsfunktionen eignen sich gleich gut Der Partial State Record (PSR) ist unterschiedlich groß Beispiele: MIN: Es muss immer nur ein Wert übertragen werden MEDIAN: Alle Messwerte (eigener + von Kindern) weiterleiten Kategorien: Algebraic PSR = (z.b. MIN) Distributive PSR = c (z.b. AVG) Holistic PSR = n (z.b. MEDIAN) Unique PSR = d (z.b. COUNT DISTINCT) d = Anzahl unterschiedlicher Werte TinyDB erlaubt auch das Definieren eigener Aggregationsfunktionen SuS: 5. Datenhaltung

43 TinyDB: Aggregation () Eine Simulation zeigt das Einsparungspotential Simulation Simulation Results Results Nodes Nodes 50x50 50x50 Grid Grid Depth Depth = = ~0 ~0 Neighbors Neighbors = = ~0 ~0 Uniform Dist. Uniform Dist. Total Bytes Xmitted vs. Aggregation Function Total Bytes X mitted EXTERNAL MAX AVERAGE DISTINCT MEDIAN Aggregation Function SuS: 5. Datenhaltung

44 TinyDB: Optimierung der Ausführung Anhand der Metadaten über Sensoren (Dauer der Messung, Energieverbrauch) wird die Anfrageverarbeitung optimiert. Traditional DBMS SELECT SELECT light, light, mag mag FROM FROM sensors sensors WHERE WHERE pred(mag) pred(mag) AND AND pred(light) pred(light) EPOCH EPOCH DURATION DURATION s s Bei Bei Messung/s Messung/s kann kann die die Ersparnis Ersparnis,5,5 mw mw betragen. betragen. Soviel Soviel benötigt benötigt Richtige Richtige Reihenfolge Reihenfolge auch auch die die CPU CPU ungefähr! ungefähr! pred pred mag teuer pred pred ACQP pred billig mag light light billig SuS: 5. Datenhaltung pred light teuer mag

45 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung SuS: 5. Datenhaltung 5

46 Zusammenfassung Datenhaltung in ubiquitären Systemen weist einige Besonderheiten auf: In-Memory vs. On-Disk-Storage SQL vs. Navigational API Client/Server- vs. Embedded-Architektur Im Bereich der Sensornetzwerke repräsentiert TinyDB den Stand der Kunst Neues Paradigma: Acquisitional Data Processing Anfragen liefern einen Datenstrom statt eines einzelnen Ergebnisses Sensordaten werden auf Anforderung erzeugt Deklarative Anfragesprache TinySQL Tree-based Routing bei der Anfrageverarbeitung Diverse Ansätze zum Energiesparen SuS: 5. Datenhaltung 6

47 Literatur [] [] S. Graves, COTS databases for embedded systems. Embedded Computing Design, Open Systems Publishing, 007. S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. TinyDB: an acquisitional query processing system for sensor networks. ACM Transactions Database Systems 0, (Mar. 005), pages -7, 005. SuS: 5. Datenhaltung 7