Datenhaltung - Embedded System Software Group
Werbung
Software ubiquitärer Systeme Datenhaltung Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund [email protected] http://ess.cs.uni-dortmund.de/~os/ http://ess.cs.tu-dortmund.de/DE/Teaching/SS2012/SuS/ 1 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.1 – Datenhaltung 2 Inhalt ● Datenhaltung in ubiquitären Systemen ● Stand der Kunst ● ● Datenhaltung auf kleinsten Systemen ● ● Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung 05.1 – Datenhaltung 3 Datenhaltung in ubiquitären Systemen ● Wo liegen die Unterschiede? Netzwerk SQL-Schnittstelle Prozess DBMS Prozess Prozess Cache ? Datenbank Klassischer Datenbankserver 05.1 – Datenhaltung Ubiquitäre Datenhaltung 4 Anforderungen ● ● Anwendungsfälle ● Mobiltelefone speichern Adressen, Zeiten für Benachrichtigungen, eingegangene Nachrichten ● MP3-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.1 – Datenhaltung 5 Typische Unterschiede (1) [1] ● 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.1 – Datenhaltung 6 Typische Unterschiede (2) ● 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.1 – Datenhaltung 7 Typische Unterschiede (3) ● 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.1 – Datenhaltung 8 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.1 – Datenhaltung 9 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.1 – Datenhaltung Ubiquitäre Datenhaltung 10 Inhalt ● Datenhaltung in ubiquitären Systemen ● Stand der Kunst ● ● Datenhaltung auf kleinsten Systemen ● ● Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung 05.1 – Datenhaltung 11 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 20 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.1 – Datenhaltung 12 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.1 – Datenhaltung 13 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, 0664)); // 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.1 – Datenhaltung 14 Oracle Berkeley DB: Codegröße ● ● Das System ist für größere ubiquitäre Systeme durchaus geeignet und grobgranular konfigurierbar. Daten von 1999: Access Methods (total) Locking Logging Transactions/Recovery Include Total Object Size in Bytes Text Data BSS 108.697 52 12.533 0 37.367 0 26.948 8 0 0 0 4 185.545 4 60 Lines of Code 22.000 2.500 8.000 5000 15.000 52.500 Quelle: Margo Seltzer, Sleepycat Software ● Daten von heute (Oracle): Object Size 400.000 05.1 – Datenhaltung 15 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 4.3 BSD UNIX 05.1 – Datenhaltung 16 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.1 – Datenhaltung 17 TinyDB: Motivation ● Die Programmierung von Sensornetzwerken ist schwierig Deklarative Anfragen sind einfach ● Beispiel: Straßenbeobachtung ● ● Handgeschriebener Code - 1-2 Wochen Entwicklungszeit - Hunderte von Zeilen C-Code ● TinyDB-Anfrage - 2 Minuten Entwicklungszeit - Vergleichbare Funktionalität SELECT nodeid FROM sensors WHERE mag > thresh EPOCH DURATION 64ms 05.1 – Datenhaltung 18 TinyDB: Idee ● ● Hohe Abstraktionsebene ● Datenzentrierte Programmierung ● Interaktion mit dem Netzwerk als Ganzes SELECT nodeid FROM sensors WHERE mag > thresh EPOCH DURATION 64ms App Unter der Haube ● Erweiterbarkeit ● Anfrageoptimierung ● Effiziente Ausführung Query, Trigger Data TinyDB Sensor Network 05.1 – Datenhaltung 19 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 unter unter Teil Teil widerspiegelt widerspiegelt (EPOCH (EPOCH DURATION DURATION ...). ...). 05.1 – Datenhaltung 20 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.1 – Datenhaltung 21 TinyDB: Beispiele (1) „Finde Sensoren in hellen Nestern“ SELECT nodeid, nestNo, light Epoch Sensors nodeid nestNo light FROM sensors 0 1 17 455 WHERE light > 400 0 2 25 389 EPOCH DURATION 1s 1 1 17 422 1 2 25 405 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.1 – Datenhaltung ... 11 22 TinyDB: Beispiele (2) 22 SELECT AVG(sound) FROM sensors EPOCH DURATION 10s 33 „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) >> 200 200 FROM sensors Epoch region CNT(...) AVG(...) GROUP BY region 0 North 3 360 HAVING AVG(sound) > 200 0 South 3 520 EPOCH DURATION 10s 1 North 3 370 1 South 3 520 05.1 – Datenhaltung 23 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 10s) ● 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 10s 05.1 – 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. 24 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) < 10m EPOCH DURATION 2s FOR 30s 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 << 10m), 10m), 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.1 – Datenhaltung 25 TinyDB: Innenleben SELECT AVG(temp) WHERE light>400 Anfragen Resultate Epoch AVG(...) 0 225 1 250 Multihop Netzwerk Anfrageprozessor Aggavg(temp) Filterlight > 400 Name: temp get('temp') Tables Samples got('temp') Time to sample: 50 µS Cost to sample: 90 µJ Schema Calibration Table: 3 getTempFunc(...) Units: Deg. F TinyOS Error: ± 5 Deg F Get f : getTempFunc()… TinyDB 05.1 – Datenhaltung 26 TinyDB: Innenleben SELECT AVG(temp) WHERE light>400 Anfragen Resultate Epoch AVG(...) 0 225 1 250 Multihop Netzwerk ~10.000Anfrageprozessor Zeilen C Code Aggavg(temp) ~5.000 Zeilen Java (PC-Seite) Filterlight ~3200 Bytes RAM Heap)temp > 400 (mit 768 Byte Name: got('temp') Time to sample: 50 µS get('temp') Samples ~58 KB Tables übersetzter Code (3x größer Schema als das zweitgrößte getTempFunc(...) TinyOS TinyDB 05.1 – Datenhaltung Cost to sample: 90 µJ Calibration Table: 3 TinyOS-Programm) Units: Deg. F Error: ± 5 Deg F Get f : getTempFunc()… 27 TinyDB: Anfrageverarbeitung ● basiert auf „Tree-based Routing“ für ... ● Anfrageverbreitung, ● Datensammlung und ● Aggregation Q:SELECT … B A C D F E 05.1 – Datenhaltung 28 TinyDB: Anfrageverarbeitung ● basiert auf „Tree-based Routing“ für ... ● Anfrageverbreitung, ● Datensammlung und ● Aggregation Q:SELECT … Q B A Q C D F E 05.1 – Datenhaltung 29 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.1 – Datenhaltung 30 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.1 – Datenhaltung Q 31 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.1 – Datenhaltung 32 TinyDB: Energiesparen ● Das Sparen von Energie ist das zentrale Thema beim Betrieb von Sensornetzwerken. ● TinyDB spart Energie durch diverse Techniken [2] ● Anwendungsabhängiger Duty-Cycle ● Aggregation im Sensornetzwerk ● Optimierte Ordnung der Messungen und Prädikate - Acquisitional Query Processing ● ... 05.1 – Datenhaltung 33 TinyDB: Power Management ● Grobgranulare, anwendungsgesteuerte Kommunikationsund Schlafphasen Knoten ID 1 … zzz … Epoche (Sekunden bis Stunden) … zzz … 2 3 4 5 Zeit wenige Sekunden Wachphase 05.1 – Datenhaltung 34 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.1 – Datenhaltung 35 TinyDB: Aggregation (1) … erfolgt im Sensornetzwerk ● Deutliche Reduktion des Kommunikationsaufwandes! SELECT COUNT(*) FROM sensors Intervall 4 Sensor # 1 Intervall # ● 4 2 3 4 1 Epoche 5 2 3 1 3 4 2 1 4 1 1 05.1 – Datenhaltung 5 36 TinyDB: Aggregation (1) … erfolgt im Sensornetzwerk ● Deutliche Reduktion des Kommunikationsaufwandes! SELECT COUNT(*) FROM sensors Intervall 3 Sensor # 1 Intervall # ● 2 3 4 4 3 1 Epoche 5 2 3 1 2 2 4 2 1 4 5 05.1 – Datenhaltung 37 TinyDB: Aggregation (1) … erfolgt im Sensornetzwerk ● Deutliche Reduktion des Kommunikationsaufwandes! SELECT COUNT(*) FROM sensors Intervall 2 Sensor # 1 1 1 Intervall # ● 2 3 4 4 2 3 1 3 2 5 3 Epoche 2 1 4 3 1 4 1 05.1 – Datenhaltung 5 38 TinyDB: Aggregation (1) … erfolgt im Sensornetzwerk ● Deutliche Reduktion des Kommunikationsaufwandes! 5 SELECT COUNT(*) FROM sensors Sensor # 1 Intervall # ● 2 3 4 4 4 Epoche 5 2 3 2 2 1 1 1 3 Intervall 1 1 4 3 5 1 05.1 – Datenhaltung 5 39 TinyDB: Aggregation (1) … erfolgt im Sensornetzwerk ● Deutliche Reduktion des Kommunikationsaufwandes! SELECT COUNT(*) FROM sensors Intervall 4 Sensor # 1 Intervall # ● 2 3 4 4 5 2 3 2 2 4 Epoche 1 3 1 1 1 4 3 5 1 1 05.1 – Datenhaltung 5 40 TinyDB: Aggregation (2) ● Zuordnung des Intervalls: Tiefe im Baum = Intervall Die feste Zuordnung erlaubt verlängerte Schlafphasen Intervall 4 Sensor # 1 Intervall # ● 4 3 sc 2 L 1 5 4 2 fen a l h 1 3 L 1 Epoche 4 5 L 1 2 3 2 4 3 en f a l sch L 1 1 5 L: „Listen“ - Der Knoten muss lauschen 05.1 – Datenhaltung 41 TinyDB: Aggregation (3) ● 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| = 1 (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.1 – Datenhaltung 42 TinyDB: Aggregation (4) Eine Simulation zeigt das Einsparungspotential Simulation Simulation Results Results 2500 Nodes 2500 Nodes 50x50 50x50 Grid Grid Depth Depth == ~10 ~10 Neighbors Neighbors == ~20 ~20 Uniform Dist. Uniform Dist. Total Bytes Xmitted vs. Aggregation Function 100000 90000 80000 Total Bytes Xmitted ● 70000 60000 50000 40000 30000 20000 10000 0 EXTERNAL MAX AVERAGE DISTINCT MEDIAN Aggregation Function 05.1 – Datenhaltung 43 TinyDB: Optimierung der Ausführung Anhand der Metadaten über Sensoren (Dauer der Messung, Energieverbrauch) wird die Anfrageverarbeitung optimiert. SELECT light, mag FROM sensors WHERE pred1(mag) AND pred2(light) EPOCH DURATION 1s Traditional DBMS ● Richtige Richtige Reihenfolge Reihenfolge pred1 pred1 pred2 mag teuer pred2 Bei Bei 11 Messung/s Messung/s kann kann die die Ersparnis Ersparnis 3,5 3,5 mW mW betragen. betragen. Soviel Soviel benötigt benötigt auch auch die die CPU CPU ungefähr! ungefähr! ACQP pred2 billig mag light billig light 05.1 – Datenhaltung pred1 light teuer mag 44 Inhalt ● Datenhaltung in ubiquitären Systemen ● Stand der Kunst ● ● Datenhaltung auf kleinsten Systemen ● ● Beispiel Berkeley DB Beispiel TinyDB Zusammenfassung 05.1 – Datenhaltung 45 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.1 – Datenhaltung 46 Literatur [1] [2] S. Graves, COTS databases for embedded systems. Embedded Computing Design, Open Systems Publishing, 2007. 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 30, 1 (Mar. 2005), pages 122-173, 2005. 05.1 – Datenhaltung 47
