Teil 2 Maßgeschneidertes Datenmanagement

Teil 2
Maßgeschneidertes Datenmanagement
Gunter Saake (Universität Magdeburg)
Christian Kästner (Universität Marburg)
Maßgeschneiderte Datenhaltung

Kommerzielle DBMS



Individuelle Datenhaltungs-Software


Oracle, IBM DB2, SQL Server, …
Obermenge aller denkbaren, kommerziell einsetzbaren
Funktionalität
Selbst „gestrickt“: teuer, schwer wartbar, ..
Maßgeschneiderte Software für Datenhaltung


„Variantenfertigung“, DBMS-Produkt-Familie
Gibt es noch nicht!
Kommerzielle DBMS


Oracle, IBM DB2, Microsoft SQL Server, …
Obermenge aller denkbaren Funktionalität

Oracle Database 11g















Real Application Testing
Advanced Compression
Total Recall
Active Data Guard
Real Application Clusters
Management Packs
Partitioning
Content Database Suite
Warehouse Builder
OLAP
Data Mining
Spatial
Database Vault
Advanced Security, Label Security
In-Memory Database Cache

Microsoft SQL Server 2008










Analysis Services
Data Mining
Hochverfügbarkeit – Always On
Integration Services
Verwaltbarkeit
Leistung und Skalierbarkeit
Entwicklung
Reporting Services
Sicherheit
Standortintelligenz
Embedded Databases

Eingebettete Systeme sind weit verbreitet und sollen
sehr häufig Daten erfassen



z.B. Sensoren im Auto, Biotopüberwachung, Gesundheitskarte,
Wetterstation, RFID, Erdbebenvorhersage, Telefonanlage,
Router, Handy
Ständig wachsendes Datenaufkommen, immer mehr
Daten sollen erfasst werden
Eingebettete Systeme unterliegen starken
Ressourcenbeschränkungn


Senkung von Kosten, Energieverbrauch und Wärme
Oracle im Auto?
Datenmanagement im Auto
Persistenz
Recovery
Konsistenz
Queries
Granularität
SQL
DB
Navigations-system x
x
Fahrtenbuch
x
xx
x
cursor
Tabelle
Kilometerzähler
x
x
xx
fetch
Tupel
Umdrehungszähler (min/ maxWert)
x
int
Informatik im Auto



Wertschöpfungsanteil der Elektronik im Fahrzeug: ca.
40%
Entwicklungskosten eines Steuergeräts: 50% SoftwareErstellungskosten
Speicherbedarf im Oberklassewagen



Um 1995: 1 MB (5 vernetzte Steuergeräte)
Heute: 80 MB (über 70 vernetzte Steuergeräte)
Zukünftig: 10 GB
Smartcards







Chipkarten mit geringer Rechenleistung und geringem
Speicher, z. B. Bankkarte, Mensakarte, SIM-Karte,
Gesundheitskarte
Sehr wenig Speicher (24-48KB)
Externe, unsichere Stromversorgung
Schnelles Lesen aber sehr langsames Schreiben
Beschränkte Rechenleistung
Oft hohe Sicherheitsanforderungen
IBM DB2 auf Bankkarte?
Datenmanagement auf Smartcards




Transaktionen (ACID)
Benutzerverwaltung, Datensicherheit und Datenschutz
Recovery
SQL Anfragen?
Sensornetzwerke




Autarke Sensoren, ohne Zentralcomputer
Kommunikation mittels (drahtlosen) Netzwerk
Kleine Komponenten mit Sensor und eingebettetem
System
Ermöglicht die einfache Installation, Verteilung der
Sensoren
Einsatzbeispiel Sensornetzwerke


Biotopüberwachung auf „Great Duck Island“ zur
Beobachtung des Brutverhalten von Seevögeln, 2002, UC
Berkeley & Intel
50 batteriebetriebene Sensoren
Einsatzbeispiel Sensornetzwerke II


Sensornetzwerk in Erdbebentestzentrum
Mobile, autarke, leicht anzubringende Sensoren statt
zentraler Verkabelung
Alte Zentralverkabelung
Datenmanagement bei Sensornetzwerken


Ad-hoc Anfragen
Aggregation, Anfragen über Raum und Zeit
Besonderheiten Sensornetzwerke

Ressourcenbegrenzung durch Batteriebetrieb






Schwache Rechenleistung
Kein kontinuierliches Senden von Messwerten
Unsichere Übertragung, veränderliches Netzwerk
Wenig Speicher (100-200kB)
Verteiltes System, verteilte Transaktionen
Komplexe Anfragen


Werteaggregation über mehrere Sensoren
Anfragen über Raum und Zeit („Wo war der Höchstwert der
letzten Stunde“)
Eingebettete Datenbanken in der Zukunft

Ubiquitous Computing


Bsp.: vernetzte Computer in Kleidung,
Kühlschrank, Intelligent Home,
Kaffeetasse
Smart Dust
Invarianz-Gesetz: Monotones Wachstum der
Datenhaltung
1 PB
SQL-3
1 TB
1 GB
SQL-1
1 MB
1-Relation
1 KB
1-Tupel
1960
1970
1980
1990
2000
2010
2020
Eingebettete Datenbanken

Immer: Speicherung „geringer“ Datenmengen bei
eingeschränkten Ressourcen





Business-Applikationen in 70ern
Desktop-Anwendungen in 80ern
Handys bis vor kurzem
Sensornetzwerke, Ubiquitous Computing, Smart Dust in der
Zukunft
Immer: maßgeschneidertes Datenmanagement für
Systeme mit vielen Daten unter
Ressourcenbeschränkungen nötig
Von Macro über Mini und Micro zu Nano-DBMS
Mini
Relationales
Datenmodell
SQL 1 (Ad-hoc
Anfragen möglich)
Micro
persistente Tabellen
1-Relationen
Zugriff meist über
eine API
Nano
einfache persistente
Speicherstrukturen
(Array, Hash Map,..)
API
Typische
Systeme
Oracle, IBM, MS
SQL-Server
MySQL, Oracle
Lite
(tief) eingebettete Systeme,
Smartcards
SQL 3
PDA, Smartphones
Macro
Objektrelationales -.
Multidimensionales -,
und Relationales
Datenmodell
Einsatzgebiet
Desktop, Laptop
Anfragen
Serversysteme
Datenmodelle/
Speicherformen
Berkeley DB,
RDM- Embedded,
COMET DBMS
Prevayler
Datenbank-Archäologie


Datenbankforschung vor gut 20 Jahren
DFG SPP Objektbanken für Experten


Themen auf Konferenzen




DBMS-Funktionalität für OO
Baukasten-Architektur
Erweiterbarkeit
Kernsysteme
Effekt auf heutige reale Systeme?


Erweiterbarkeit: ja
Schlanke Systeme für Spezialaufgaben: nein
State-of-the-Art


Wenn überhaupt
Variantenmanagement,
dann mit #ifdef, C++Templates, make, CVS
Beispiel: Berkeley DB
(mutex_int.h)
#ifndef _DB_MUTEX_INT_H_
#define _DB_MUTEX_INT_H_
#ifdef HAVE_MUTEX_PTHREADS
#include <pthread.h>
#define MUTEX_FIELDS
pthread_mutex_t mutex;
pthread_cond_t cond;
#endif
/* Mutex. */
/* Condition variable. */
#ifdef HAVE_MUTEX_UI_THREADS
#include <thread.h>
#endif
#ifdef HAVE_MUTEX_SOLARIS_LWP
#include <synch.h>
#define MUTEX_FIELDS
lwp_mutex_t mutex;
lwp_cond_t cond;
#endif
/* Mutex. */
/* Condition variable. */
#ifdef HAVE_MUTEX_UI_THREADS
#include <thread.h>
#include <synch.h>
#define MUTEX_FIELDS
mutex_t mutex;
cond_t cond;
#endif
/* Mutex. */
/* Condition variable. */
#ifdef HAVE_MUTEX_AIX_CHECK_LOCK
#include <sys/atomic_op.h>
typedef int tsl_t;
#ifdef LOAD_ACTUAL_MUTEX_CODE
#define MUTEX_INIT(x)
0
#define MUTEX_SET(x)
(!_check_lock(x, 0, 1))
#define MUTEX_UNSET(x)
_clear_lock(x, 0)
#endif
#endif …
Heute: SQL-Moloche statt angepasster kleiner
Systeme

Erklärungsversuch: Warum scheiterten alle diese
bisherigen Versuche?


Komplexität des Variantenraums,
z.B. SQL3 als Moloch
Schwer lokalisierbare Funktionalitäten,
z.B. Transaktionseigenschaften
Zerlegung des Molochs



SQL3-DBMS bieten die Obermenge aller sinnvollen (d.h.,
verkaufbaren) Funktionalität
„Kleine“ Datenhaltungskomponenten können nur einen
Teil dieser Funktionalität haben
Zerlegung in Features notwendig



Baukasten für Funktionalität
Bekannt aus Betriebssystemforschung
Maßschneiderung von Software


DBMS-Familien, Produktlinien
Analog zu Variantenfertigung im Ingenieurwesen
… warum jetzt ein neuer Versuch?



Erfahrung aus dem Betriebssystembereich
Vor 25 Jahren: ähnliche Situation wie im DBMS-Bereich
Neue Programmiertechniken (FOP, AOP)



Zum Teil im Betriebssystem-Bereich entwickelt
Dort erfolgreich eingesetzt
Warum nicht auch für andere Infrastruktur-Software
einsetzbar?
Gemeinsame Funktionalität von eingebetteten DBMS

Was wird immer wieder gebraucht









Speichermanagement (z.B. Einpassen auf Seiten)
Katalog
Anfrageverarbeitung (SQL parsen, Pläne erstellen und
optimieren)
Transaktionsverwaltung
Zugriffsrechte
Recovery
Verschlüsselung
DDL/DML/SQL Dialekte
Nicht alle Systeme benötigen alle Features
Optimierung

Unterschiedliche Varianten der gleichen Funktionalität, z.
B.





Optimiert für geringen Stromverbrauch
Optimiert für Performance
Optimiert für minimalen Footprint
Spezielle Implementierung für Systembesonderheiten, z. B.
kein RAM, keine/kaum Schreibzugriffe
Unterschiedliche Architekturen,
z. B. verteilt vs. stand-alone
Produktlinien


Jeweils neu programmieren ist sowohl unwirtschaftlich
als auch gefährlich
Daher maßgeschneidertes Datenmanagement mit
Produktlinien




Aus wiederverwendbaren Teilen
Die alternative Implementierungen haben können
Anpassbar für spezielle Anwendungsfälle
Nutzbar auch unter extremer Ressourcenbeschränkung
Zusammenfassung




Maßgeschneiderte Datenhaltung nötig
Große Datenmenge unter beschränkten Ressourcen
Gemeinsame Funktionalität aber auch viele Unterschiede
Produktlinien als Ausweg?
Ausblick



Modellierung von Produktlinien mit Features
Einfache Implementierungsstrategien
Moderne Programmierparadigmen
Literatur



Marko Rosenmüller, Thomas Leich, Sven Apel und Gunter
Saake. Von Mini- über Micro- bis zu Nano-DBMS:
Datenhaltung in eingebetteten Systemen. Datenbank
Spektrum, 7(20), Feb.2007.
Michael Stonebraker. Technical perspective - One size fits
all: an idea whose time has come and gone.
Communications of the ACM. 51(12), 2008.
Surajit Chaudhuri, Gerhard Weikum. Rethinking Database
System Architecture: Towards a Self-Tuning RISC-Style
Database System. Proc. Int. Conf. Very Large Data Bases,
2000