Datenhaltung - Embedded System Software Group

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