Software ubiquitärer Systeme

Transkript

1 Software ubiquitärer Systeme Datenhaltung Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik TU Dortmund

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

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

4 Datenhaltung in ubiquitären Systemen Wo liegen die Unterschiede? Netzwerk SQL-Schnittstelle Prozess DBMS Prozess Prozess Cache? Datenbank Klassischer Datenbankserver 05. Datenhaltung Ubiquitäre 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 05. 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. 05. 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 05. Datenhaltung 7

8 Typische Unterschiede () Architektur Klassisch: Client/Server - Anwendungen benutzen Interprozesskommunikationsmechanismen, 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 - Geringerer Ressourcenverbrauch - Bessere Vorhersagbarkeit - Weniger Kontextwechsel Achtung Achtung Mehrdeutigkeit: Mehrdeutigkeit: Eingebettete Eingebettete Datenbanken Datenbanken sind sind nicht nicht notwendigerweise notwendigerweise Datenbanken Datenbanken für für eingebettete eingebettete Systeme. Systeme. - bessere Performance 05. 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. 05. Datenhaltung 9

10 Datenhaltung in ubiquitären Systemen Wo liegen die Unterschiede? Applikation Netzwerk Funktion Funktion SQL-Schnittstelle Prozess Prozess Navigational API Prozess Funktion DBMS Funktion Funktion Cache DBMS Datenbank Datenbank Klassischer Datenbankserver 05. Datenhaltung Ubiquitäre Datenhaltung 0

11 Inhalt Datenhaltung in ubiquitären Systemen Stand der Kunst Datenhaltung auf kleinsten Systemen Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung 05. 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 diskresident database, and does not have the overhead of a client-server interprocess communication. Quelle: Oracle 05. 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) 05. Datenhaltung

14 Oracle Berkeley DB: Schnittstelle Tabellen sind einfache Key/Data-Paare Key fruit Data apple sport cricket drink water // 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)); Ein Datum kann auch Key einer anderen DB sein Erlaubt mehrere Indizes für Daten und Joins 05. 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: Access Methods (total) Locking Logging Transactions/Recovery Include Total Object Size in Bytes Text Data BSS Lines of Code Quelle: Margo Seltzer, Sleepycat Software Daten von heute (Oracle): Object Size Datenhaltung 5

16 Oracle Berkeley DB: Fazit Das Beispiel zeigt was eine eingebettete Datenbank ist und dass diese auch für viele eingebettete/ubiquitäre Systeme das Mittel der Wahl sind. typische Eigenschaften von Datenhaltungssystemen für ubiquitäre Systeme Keine SQL-API Datenhaltung im Hauptspeicher Keine Client/Server-Architektur den Stand der Kunst 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 05. 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 05. Datenhaltung 7

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 05. 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 05. 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...)....). 05. 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. 05. Datenhaltung

22 TinyDB: Beispiele () Finde Sensoren in hellen Nestern SELECT nodeid, nestno, light Epoch Sensors nodeid nestno light FROM sensors WHERE light > EPOCH DURATION s 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. 05. 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 Ergebnisse zu zu deren deren Durchschnitt. Durchschnitt. SELECT region, CNT(occupied), AVG(sound) Regionen Regionen mit mit AVG(sound) AVG(sound) >> FROM sensors Epoch region CNT(...) AVG(...) GROUP BY region 0 North 60 HAVING AVG(sound) > 00 0 South 50 EPOCH DURATION 0s North 70 South 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 05. 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 sind. Wert 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 Durchschnitte zurück. zurück. Ereignisse können anwendungsspezifisch definiert werden Das passiert unterhalb der TinySQL-Ebene 05. Datenhaltung 5

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

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

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

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

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

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

32 TinyDB: Anfrageverarbeitung basiert auf Tree-based Routing für... Anfrageverbreitung, Datensammlung und Aggregation Q:SELECT A R:{ } R:{ } B C R:{ } D R:{ } R:{ } F E 05. 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 Datenhaltung

34 TinyDB: Power Management Grobgranulare, anwendungsgesteuerte Kommunikationsund Schlafphasen Knoten ID zzz Epoche (Sekunden bis Stunden) zzz 5 Zeit wenige Sekunden Wachphase 05. 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. 05. Datenhaltung 5

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

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

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

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

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

41 TinyDB: Aggregation () Zuordnung des Intervalls: Tiefe im Baum = Intervall Die feste Zuordnung erlaubt verlängerte Schlafphasen Intervall Sensor # Intervall # sc L 5 fen a l h L Epoche 5 L en f a l sch L 5 L: Listen - Der Knoten muss lauschen 05. Datenhaltung

42 TinyDB: Aggregation () Nicht alle Aggregationsfunktionen eignen sich gleich gut Der Partial State Record (PSR) ist unterschiedlich groß Beispiel 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 05. Datenhaltung

43 TinyDB: Aggregation () Eine Simulation zeigt das Einsparungspotential Simulation Simulation Results Results 500 Nodes 500 Nodes 50x50 50x50 Grid Grid Depth Depth == ~0 ~0 Neighbors Neighbors == ~0 ~0 Uniform Dist. Uniform Dist. Total Bytes Xmitted vs. Aggregation Function Tot al Byt es X mit t ed EXTERNAL MAX AVERAGE DISTINCT MEDIAN Aggregation Function 05. Datenhaltung

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