Was sind embedded DBMS? Eingebettete DBMS. Motivation für Embedded Databases. Besonderheiten Smartcards. in Programme eingebettet z.b.

Transkript

1 Eingebettete DBMS Was sind embedded DBMS? in Programme eingebettet z.b. (embedded database management systems) Aktuelle Praxis und Herausforderungen Berkeley DB DB4O embedded systems z.b. Smartcard Christian Kästner, Martin Kuhlemann, Norbert Siegmund, Marko Rosenmüller, Sven Apel, Thomas Leich, Gunter Saake Sensoren, Sensornetzwerke PDAs Handys ITI_DB/MD Datenbanken 2: Embedded DBMS 1 ITI_DB/MD Datenbanken 2: Embedded DBMS 2 Motivation für Embedded Databases Besonderheiten Smartcards 98 % aller im Einsatz befindlichen Rechnersysteme sind eingebettete Systeme Extreme Ressourcenbeschränkung Hohe Heterogenität von Hard- und Software Ubiquitous und Pervasive Computing Sensornetzwerke, Gerätesteuerung Datenaufkommen in diesem Bereich wächst ständig Extrem wenig Speicher 24-48kB Footprint für DBMS Kaum bis gar kein RAM -> neuartige Anfragepläne Schnelles Lesen, aber sehr langsames Schreiben, beschränkte Rechenleistung Externe Stromversorgung -> Transaktionen Sicherheitsmanagment, Privacy, z.b. für den Einsatz als Gesundheitskarte ITI_DB/MD Datenbanken 2: Embedded DBMS 3 ITI_DB/MD Datenbanken 2: Embedded DBMS 4

2 Beispiel Sensor-Datenbanken: Biotop-Überwachung 1000 drahtlose Sensoren : Temperatur, Luftdruck, Vibrationen, Lichtintensität, Feuchtigkeit, Chemische Zusammensetzungen Mikrosensoren: Stark ressourcenbeschränkte eingebettete Systeme Datenkollektoren Zusammenführung von Sensordaten Vorbereitung der Datenauswertung Problem: ressourcenknappe Umgebung Kein kontinuierliches Senden von Messwerten möglich Voraggregation verhindert Ad-hoc-Anfragen Verringerung zu übertragender Daten Besonderheiten Sensornetzwerke Wenig Speicher kB Footprint für DBMS, sehr wenig RAM Verteiltes System mit veränderlicher Anzahl an Teilnehmern Stromversorungsprobleme (Batterie) Kommunikationsstörungen (Funk) Verteilte Transaktionen Abfragen über Zeit Werteaggregation über mehrere Sensoren Komplexe Anfragen über veränderliches Netzwerk ITI_DB/MD Datenbanken 2: Embedded DBMS 5 ITI_DB/MD Datenbanken 2: Embedded DBMS 6 Weitere Anwendungsszenarien Sensoren in Autos (24V) Cisco Router Telefonanlage, Mobiltelefon Jeweils rel. hohe Datenmenge bei rel. schwachen Prozessoren Waerme Energieverbrauch Kosten ITI_DB/MD Datenbanken 2: Embedded DBMS 7 Und in Zukunft? Speicherung geringer Datenmengen untereingeschränkten Ressourcen Ähnliche Situation bereits vor Jahren: Handys noch vor kurzem Desktop Bereich in 80ern Business Applikationen in 70ern Und in Zukunft? Ubiquitous Computing, Smart Dust Immer DM für kleine Datenmengen und extreme Ressourcenbeschränkungen notwendig ITI_DB/MD Datenbanken 2: Embedded DBMS 8

3 Datenmanagement (DM) in Eingebetteten Systemen Breites Anwendungsspektrum Sensoren bis Navigationssysteme Biologie bis Technik Unterschiedliche Daten Einzelne Werte + einfache Strukturen (z.b. Array) Einzelne Tabellen Vollständige Datenbank (z.b. Navigationssystem) Unterschiedliche Hardware Spezielle Anforderungen (z.b. für EEPROM) Ressourcenbeschränkungen (CPU, Speicher, Energie) ITI_DB/MD Datenbanken 2: Embedded DBMS 9 Existierende embedded DBMS Oft gebaut für sehr spezielle Anforderungen Unterstützen nur wenige Systeme z.b. nur Smartcards Kaum Anpassbar Teils unnötiger Overhead ITI_DB/MD Datenbanken 2: Embedded DBMS 10 Von Macro über Mini und Micro zu Nano-DBMS Macro Mini Micro Nano Datenmodelle/ Speicherformen Objektrelationales -. Multidimensionales -, und Relationales Datenmodell Relationales Datenmodell persistente Tabellen einfache persistente Speicherstrukturen (Array, Hash Map,..) Anfragen SQL 3 SQL 1 (Ad-hoc Anfragen möglich) 1-Relationen Zugriff meist über eine API API Einsatzgebiet Serversysteme Desktop, Laptop PDA, Smartphones (tief) eingebettete Systeme, Smartcards Typische Systeme Oracle, IBM, MS SQL-Server MySQL, Oracle Lite Berkeley DB, RDM- Embedded, COMET DBMS Prevayler Maßgeschneiderte Datenhaltung Kommerzielle DBMS Oracle, IBM DB2, SQL Server, -> Eierlegende Wollmilchsäue Obermenge aller denkbaren kommerziell einsetzbarer Funktionalität Aufgrund Ressourcenbeschraenkung nicht einsetzbar Individuelle Datenhaltungs-Software teuer, schwer wartbar, time to market.. Lösung: Maßgeschneidertes DM Für jede Anwendung nur notwendige Funktionalität ITI_DB/MD Datenbanken 2: Embedded DBMS 11 ITI_DB/MD Datenbanken 2: Embedded DBMS 12

4 Brauchen wir alles? 1. Integration 2. Operationen 3. Katalog 4. Benutzersichten 5. Integritätssicherung (Konsistenzüberwachung) 6. Zugriffskontrolle/Datenschutz 7. Transaktionen 8. Synchronisation 9. Datensicherung Was ist gemeinsam/ähnlich? Was wird meist in ähnlicher Form gebraucht Storage Management (Einpassen auf Seiten etc) Anfrageverarbeitung (SQL parsen, Pläne erstellen und optimieren) Transaktionsverwaltung Was ist oft gemeinsam Zugriffsrechte Recovery Logging DDL/DML/SQL Dialekte ITI_DB/MD Datenbanken 2: Embedded DBMS 13 ITI_DB/MD Datenbanken 2: Embedded DBMS 14 Architektur Verteilt Was ist unterschiedlich? Stand-alone Minimaler Footprint Unterschiedliche Implementierung gleicher Funktionalität Optimiert für geringen Stromverbrauch Optimiert für Performance Minimaler Footprint Systemspezifika z.b. kein RAM Idee: Produktlinien Aus einheitlicher Basis eine Vielzahl verschiedener Produkte erstellen Alle Produkte gehoeren zu einer Produktfamilie Unterscheiden sich durch Features (deutsch: Merkmale) Konfiguration durch Auswahl der Features ITI_DB/MD Datenbanken 2: Embedded DBMS 15 ITI_DB/MD Datenbanken 2: Embedded DBMS 16

5 BMW-Produktlinie PC-Produktlinie ITI_DB/MD Datenbanken 2: Embedded DBMS 17 ITI_DB/MD Datenbanken 2: Embedded DBMS 18 Features in MS Office Software-Produktlinien (SPL) Basis-Code enthält nur Grundfunktionalität Alles weitere wird in Features implementiert und kann hinzugefügt werden. ITI_DB/MD Datenbanken 2: Embedded DBMS 19 ITI_DB/MD Datenbanken 2: Embedded DBMS 20

6 Feature-Modell Modellierung einer Produktlinie in einem Feature-Baum Verfeinerung der Funktionalität zu den Blättern im Modell hin Beziehungen zwischen Features werden im Modell durch verschiedene Eltern-Kind Kanten dargestellt r Beispiel p s G H A B mandatory optional and alternative or ITI_DB/MD Datenbanken 2: Embedded DBMS 21 implies ITI_DB/MD Datenbanken 2: Embedded DBMS 22 Feature Modelle Existierende Systeme/Forschungsentwuerfe PicoDBMS Comet DBMS Cougar DBMS Tiny DB Berkeley DB Geplante Systeme/Subsysteme Fame DBMS Für Smartcards PicoDBMS ITI_DB/MD Datenbanken 2: Embedded DBMS 23 ITI_DB/MD Datenbanken 2: Embedded DBMS 24

7 Für Sensornetzwerke Comet DBMS Für Sensornetzwerke Cougar DBMS ITI_DB/MD Datenbanken 2: Embedded DBMS 25 ITI_DB/MD Datenbanken 2: Embedded DBMS 26 Tiny DB Berkeley DB Embedded Java Storage Engine ITI_DB/MD Datenbanken 2: Embedded DBMS 27 ITI_DB/MD Datenbanken 2: Embedded DBMS 28

8 FAME DBMS FAME DBMS: Storage Manager Zusammenfügen der Erfahrungen aus Domainanalyse und Domainwissen zu einem einzigen hochkonfigurierbarem DBMS DFG Projekt FAME Methods and tools for the construction of highly configurable database families for embedded systems (Magdeburg, Erlangen) Modellierung und Implementierung von Modulen Query Processor (SQL) Storage Manager ITI_DB/MD Datenbanken 2: Embedded DBMS 29 ITI_DB/MD Datenbanken 2: Embedded DBMS 30 Implementierung von SPL: Aktuelle Praxis Fallstudie: Berkeley DB Jedes System neuentwickeln Hoher Aufwand, aber ueblich Low-level languages (C, Assembler) #ifdef im code Resultiert teils in schlecht wartbarem Code Beispiel: Berkeley DB Komponenten, Frameworks Unvollständige Konfigurierbarkeit (z.b. Transaktionsverwaltung) Verschachtelte Präprozessoranweisungen Sehr lange Methoden (bis zu ca. 500 Zeilen) Hoher Overhead, im Embedded Bereich oft nicht moeglich ITI_DB/MD Datenbanken 2: Embedded DBMS 31 ITI_DB/MD Datenbanken 2: Embedded DBMS 32

9 Grenzen von OOP Grenzen von OOP Problem: Was wenn beide Eigenschaften benötigt werden? Problem: Was wenn beide Eigenschaften benötigt werden? Codereplikation und exponentiell viele Varianten! ITI_DB/MD Datenbanken 2: Embedded DBMS 33 ITI_DB/MD Datenbanken 2: Embedded DBMS 34 Idee Zusammenbau von Klassen OOP Basis-Struktur OOP Mixins Rollen von Klassen SortedList FindList Unterschiedlich kombinierbar Mixins ITI_DB/MD Datenbanken 2: Embedded DBMS 35 ITI_DB/MD Datenbanken 2: Embedded DBMS 36

10 Mixins Mixins OOP Ungenaue Definition der Basisimplementierung FOP Features Schrittweise Erweiterung der Basisimplementierung durch Verfeinerungen (Refinements) ITI_DB/MD Datenbanken 2: Embedded DBMS 37 Refinements ITI_DB/MD Datenbanken 2: Embedded DBMS 38 Mixins Sortierte Liste Large Scale Refinements Für Software-Produktlinien Skalierung auf ganze Software (mehrere Klassen) notwendig -> Large Scale Refinements Mixin-Schichten fassen Erweiterungen unterschiedlicher Klassen zusammen Bsp.: Bibliothek von Container-Klassen Klassen (List, Array, etc.), werden um Features (Sortierung, Suche, etc.) erweitert. Beliebige Merkmalskombinationen erstellbar ITI_DB/MD Datenbanken 2: Embedded DBMS 39 ITI_DB/MD Datenbanken 2: Embedded DBMS 40

11 Mixin-Schichten Principle of Uniformity Software besteht nicht nur aus Quellcode Build Skripte (xml) Dokumentation (xml, html, txt, pdf) Grammatiken (bali) Modelle (UML,...) Alle Software-Artefakte müssen genauso erweiterbar sein ITI_DB/MD Datenbanken 2: Embedded DBMS 41 ITI_DB/MD Datenbanken 2: Embedded DBMS 42 Beispiel Implementierungsbeispiel class Graph { Vector nv = new Vector(); Vector ev = new Vector(); Edge add(node n, Node m) { Edge e = new Edge(n, m); nv.add(n); nv.add(m); ev.add(e); return e; void print() { for(int i = 0; i < ev.size(); i++) ((Edge)ev.get(i)).print(); class Edge { Node a, b; Edge(Node _a, Node _b) { a = _a; b = _b; void print() { a.print(); b.print(); class Node { int id = 0; void print() { System.out.print(id); refines class Graph { Edge add(node n, Node m) { Edge e = super.add(n, m); e.weight = new Weight(); Edge add(node n, Node m, Weight w) Edge e = new Edge(n, m); nv.add(n); nv.add(m); ev.add(e); e.weight = w; return e; refines class Edge { Weight weight = new Weight(); void print() { super.print(); weight.print(); class Weight { void print() {... ITI_DB/MD Datenbanken 2: Embedded DBMS 43 ITI_DB/MD Datenbanken 2: Embedded DBMS 44

12 Anwendung auf DBMS Ergebnisse: Konfigurierbarkeit in Berkeley DB 35 Features, 24 optional (11 in original Version) ITI_DB/MD Datenbanken 2: Embedded DBMS 45 Ausschnitt der Features in Berkeley DB ITI_DB/MD Datenbanken 2: Embedded DBMS 46 Ergebnisse: Codegröße Ergebnisse: Performance Konfiguration Vollständig 1 Ohne Verschlüsselung 2 Ohne Hash 3 Ohne Replikation 4 Ohne Queue 5 Ohne Verifikation Minimal mit B-Tree Minimal mit Queue Äquivalente Umsetzung bei identischer Konfiguration Minimal FeatureC++ Performance Verbesserung bei Beschränkung auf notwendige Merkmale Konfiguration Vollständig Minimal C ITI_DB/MD Datenbanken 2: Embedded DBMS 47 ITI_DB/MD Datenbanken 2: Embedded DBMS 48

13 Andere Implementierungslösungen in der Forschung Design Pattern Aspect Oriented Programming Multidimensional Separation of Concerns ITI_DB/MD Datenbanken 2: Embedded DBMS 49 Probleme (Auszug) Features sind oft nicht unabhängig, wie geht man damit um? Wie geht man mit der explodierenden Variantenvielfalt um? mit n unabhängigen optionalen Features können 2 n Varianten erstellt werden mit 32 Features eine Variante für jeden Menschen auf dem Planeten mit 320 Features mehr Varianten als Atome im Universum Wie kann ein Nutzer aus hunderten Features noch die richtigen auswählen? ITI_DB/MD Datenbanken 2: Embedded DBMS 50 Problem: Feature Interaktionen Unidirectional Interactions ITI_DB/MD Datenbanken 2: Embedded DBMS 51 ITI_DB/MD Datenbanken 2: Embedded DBMS 52

14 Interaktionen rauslösen Interaktionen rauslösen (2) ITI_DB/MD Datenbanken 2: Embedded DBMS 53 ITI_DB/MD Datenbanken 2: Embedded DBMS 54 Wie viele Interaktionen gibt es? Theoretisch möglich: Paarweise Interaktionen: Alle Interaktionen: i max = n 2 = n2 n 2 n 1 n Beobachtungen langsames quadratisches Wachstum (k*n 2 ; k<<1) scheint typisch, k spezifisch für Produktlinie h max = o=1 Tatsächliche Anzahl: deutlich weniger o 1 =2n n 1 aber immer noch oft mehr als Features im System ITI_DB/MD Datenbanken 2: Embedded DBMS 55 ITI_DB/MD Datenbanken 2: Embedded DBMS 56

15 Halbautomatische Featureauswahl Automatische Selektion von Features Erlaubt optimierte Auswahl von Features mit gleicher Funktionalität, aber unterschiedlicher Implementierung Auswahl basiert auf nicht funktionalen Eigenschaften von Features Footprint Performance Verfügbarkeit Optimierung Benutzer selektiert gewünschte Funktionalität im FM Benutzer definiert nicht funktionale Bedingungen des zu erstellenden Produkts Z.B. 100kB Footprint Z.B. 5.5 Performance Berechnung der besten Auswahl einer Implementation für diese Bedingungen ITI_DB/MD Datenbanken 2: Embedded DBMS 57 ITI_DB/MD Datenbanken 2: Embedded DBMS 58 Optimierung Neue Modelle werden benötigt -> Forschung Noch mehr Probleme (Aktuelle Forschung) Erstellen einer SPL aus legacy Anwendungen Refactoring, Feature Mining Kombinationen verschiedener Ansaetze und Implementierungstechniken Mixins+Aspekte, Mixins+Design Pattern Mixins+SOA, Mixins+MDA Vereinfachung von Designs Werkzeuge fuer SPLs Formalisierung ITI_DB/MD Datenbanken 2: Embedded DBMS 59 ITI_DB/MD Datenbanken 2: Embedded DBMS 60

16 Zerlegung von SQL3 Ausblick Entwicklung einer Datenhaltungsfamilie für Embedded Systems für Automotive-Anwendungen Design-Methoden Korrektheitseigenschaften Modellierung, Visualisierung, Strukturierung, Wiederverwendung großer Feature-Räume Ausblick Vorlesung Moderne Programmierkonzepte für maßgeschneiderte Datenhaltung im Wintersemester, Mittwochs Laborpraktika Refactoring of legacy applications into features Feature IDE (Eclipse Entwicklung) Design Patterns in Eclipse durch Feature- Mechanismen ersetzen Kombination mit adaptiver Datenhaltung ITI_DB/MD Datenbanken 2: Embedded DBMS 61 ITI_DB/MD Datenbanken 2: Embedded DBMS 62 Diplomarbeiten Ausblick Service Oriented Product Lines (MD, Passau oder Spanien) Eine minimale Sprache zur Beschreibung Featureorientierter Software (MD, Passau) Feature Mining - Detecting Feature Code in Legacy Applications Clone-Detection mithilfe von Datenbanktechnologien Automatisierte Transformation von Objektorientiertem in Merkmalsorientierten Quellcode Refaktorisierung von Aspektorientiertem in Merkmalsorientierten Programmcode Vereinfachung des Eclipse-Designs Rückblick/Zusammenfassung Spezielle Herausforderungen für embedded DBMS Software-Produktlinien als mögliche Lösung Feature Modellierung Implementierung durch Mixin-Schichten Offene Probleme, Großes Forschungsfeld ITI_DB/MD Datenbanken 2: Embedded DBMS 63 ITI_DB/MD Datenbanken 2: Embedded DBMS 64