Teil 2 Maßgeschneidertes Datenmanagement. Gunter Saake (Universität Magdeburg) Christian Kästner (Universität Marburg)

Transkript

1 Teil 2 Maßgeschneidertes Datenmanagement Gunter Saake (Universität Magdeburg) Christian Kästner (Universität Marburg)

2 Maßgeschneiderte Datenhaltung Kommerzielle DBMS Oracle, IBM DB2, SQL Server, Obermenge aller denkbaren, kommerziell einsetzbaren Funktionalität Individuelle Datenhaltungs-Software Selbst gestrickt : teuer, schwer wartbar,.. Maßgeschneiderte Software für Datenhaltung Variantenfertigung, DBMS-Produkt-Familie Gibt es noch nicht!

3 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

4 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?

5 Datenmanagement im Auto Persistenz Recovery Konsistenz Queries Granularität Navigations-system x x SQL DB Fahrtenbuch x xx x cursor Tabelle Kilometerzähler x x xx fetch Tupel Umdrehungszähler (min/ max- Wert) x int

6 Informatik im Auto Wertschöpfungsanteil der Elektronik im Fahrzeug: ca. 40% Entwicklungskosten eines Steuergeräts: 50% Software- Erstellungskosten Speicherbedarf im Oberklassewagen Um 1995: 1 MB (5 vernetzte Steuergeräte) Heute: 80 MB (über 70 vernetzte Steuergeräte) Zukünftig: 10 GB

7 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?

8 Datenmanagement auf Smartcards Transaktionen (ACID) Benutzerverwaltung, Datensicherheit und Datenschutz Recovery SQL Anfragen?

9 Sensornetzwerke Autarke Sensoren, ohne Zentralcomputer Kommunikation mittels (drahtlosen) Netzwerk Kleine Komponenten mit Sensor und eingebettetem System Ermöglicht die einfache Installation, Verteilung der Sensoren

10 Einsatzbeispiel Sensornetzwerke Biotopüberwachung auf Great Duck Island zur Beobachtung des Brutverhalten von Seevögeln, 2002, UC Berkeley & Intel 50 batteriebetriebene Sensoren

11 Einsatzbeispiel Sensornetzwerke II Sensornetzwerk in Erdbebentestzentrum Mobile, autarke, leicht anzubringende Sensoren statt zentraler Verkabelung Alte Zentralverkabelung

12 Datenmanagement bei Sensornetzwerken Ad-hoc Anfragen Aggregation, Anfragen über Raum und Zeit

13 Besonderheiten Sensornetzwerke Ressourcenbegrenzung durch Batteriebetrieb Schwache Rechenleistung Kein kontinuierliches Senden von Messwerten Unsichere Übertragung, veränderliches Netzwerk Wenig Speicher ( kB) Verteiltes System, verteilte Transaktionen Komplexe Anfragen Werteaggregation über mehrere Sensoren Anfragen über Raum und Zeit ( Wo war der Höchstwert der letzten Stunde )

14 Eingebettete Datenbanken in der Zukunft Ubiquitous Computing Bsp.: vernetzte Computer in Kleidung, Kühlschrank, Intelligent Home, Kaffeetasse Smart Dust

15 Invarianz-Gesetz: Monotones Wachstum der Datenhaltung 1 PB 1 TB 1 GB 1 MB 1 KB SQL-3 SQL-1 1-Relation 1-Tupel

16 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

17 Von Macro über Mini und Micro zu Nano-DBMS Datenmodelle/ Speicherformen Anfragen Einsatzgebiet Typische Systeme Macro Mini Micro Nano Objektrelationales -. Multidimensionales -, und Relationales Datenmodell Relationales Datenmodell persistente Tabellen einfache persistente Speicherstrukturen (Array, Hash Map,..) SQL 3 SQL 1 (Ad-hoc Anfragen möglich) 1-Relationen Zugriff meist über eine API API Serversysteme Desktop, Laptop PDA, Smartphones (tief) eingebettete Systeme, Smartcards Oracle, IBM, MS SQL-Server MySQL, Oracle Lite Berkeley DB, RDM- Embedded, COMET DBMS Prevayler

18 Datenbank-Archäologie Datenbankforschung vor gut 20 Jahren DFG SPP Objektbanken für Experten DBMS-Funktionalität für OO Themen auf Konferenzen Baukasten-Architektur Erweiterbarkeit Kernsysteme Effekt auf heutige reale Systeme? Erweiterbarkeit: ja Schlanke Systeme für Spezialaufgaben: nein

19 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; /* Mutex. */ pthread_cond_t cond; /* Condition variable. */ #endif #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #endif #ifdef HAVE_MUTEX_SOLARIS_LWP #include <synch.h> #define MUTEX_FIELDS lwp_mutex_t mutex; /* Mutex. */ lwp_cond_t cond; /* Condition variable. */ #endif #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #include <synch.h> #define MUTEX_FIELDS mutex_t mutex; /* Mutex. */ cond_t cond; /* Condition variable. */ #endif #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

20 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

21 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

22 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?

23 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

24 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

25 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

26 Zusammenfassung Maßgeschneiderte Datenhaltung nötig Große Datenmenge unter beschränkten Ressourcen Gemeinsame Funktionalität aber auch viele Unterschiede Produktlinien als Ausweg?

27 Ausblick Modellierung von Produktlinien mit Features Einfache Implementierungsstrategien Moderne Programmierparadigmen

28 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 Michael Stonebraker. Technical perspective - One size fits all: an idea whose time has come and gone. Communications of the ACM. 51(12), Surajit Chaudhuri, Gerhard Weikum. Rethinking Database System Architecture: Towards a Self-Tuning RISC-Style Database System. Proc. Int. Conf. Very Large Data Bases, 2000