Datenbanksysteme in der Zukunft

© Prof. T. Kudraß, HTWK Leipzig Entwicklungslinien 1. Object Relational Arrives 2. Databases in the Cloud 3. Queues, Transactions, Workflows 4. Cubes and Online Analytical Processing 5. Data Mining 6. Column Stores 7. Text, Temporal, and Spatial Data Access 8. NoSQL 9. Data Streams 10. Publish-Subscribe and Replication 11. Data Management on New Hardware 12. Smart Objects: Databases Everywhere 13. Self-Managing and Always Up

© Prof. T. Kudraß, HTWK Leipzig 1. Object Relational Arrives Sündenfall Cobol: Trennung in Data Division und Procedure Division DB Community hat das übernommen Bemühungen um Wiedervereinigung seit 40 Jahren – Stored Procedures – Objekt-relationale DBMS (seit Mitte 90er Jahre) Objektorientierte Sprachen: Java, C# Zusammenwachsen OO Sprachen + SQL – Felder sind Objekte (Werte oder Referenzen) – Sätze (Records) sind Vektoren von Objekten (Feldern) – Tabellen bestehen aus Record-Objekten – Voraussetzung: Modularisierung der DBMS-Architektur – Objektrelationale Mapper (Hibernate, Java Persistence API) – Mehrschichtenarchitekturen order_nocust_infoline_itemsamount Hold CheckStatus Cancel Ship

© Prof. T. Kudraß, HTWK Leipzig 2. Databases in the Cloud Cloud Storage als Ressource des Cloud Computing, verschiedene Kategorien (Weiterentwicklung der Idee: DB as a Service) BLOB Storage: Virtuelles Dateisystem – Speicherung von Text- und Binärdaten in der Cloud – Zugriff über APIs, SOAP, REST Table Storage: BigTable-Ansatz, NoSQL-Datenbank – BigTable-Konzept (eine riesige Tabelle ohne feste Struktur) – Zugriff über SOAP & REST, APIs (echter) DB-Server – virtueller Datenbankserver zur eigenen Verwendung – übliche APIs

© Prof. T. Kudraß, HTWK Leipzig 3. Queues, Transactions, Workflows Internet-Anwendung: – asynchrone Tasks, bilden Workflow – arbeiten mit autonomen Agenten Alle DBMS bieten Queuing Systeme – über einfache ACID Transaktionen hinaus – implementieren Publish-Subscribe und Workflow- Systeme – WFS = Applikation on top of a Queuing System

© Prof. T. Kudraß, HTWK Leipzig 4. Cubes & OLAP Frühe relationale Systeme: – Indexe als Tabellen-Replikate – Frühe Ideen führten zu Materialized Views mit schnellem Zugriff auf Star und Snowflake Schema Frühe 90er: Data Cubes als typisches OLAP-Pattern (Aggregation von Daten entlang verschiedener Dimensionen) – Algorithmen für Cube-Design und Implementation – Optimierung für effiziente Verwaltung von Cubes (z.B. Multi- Terabyte Faktentabelle in einigen Gigabytes) Bestandteil vieler DBMS Aktuelles Forschungsgebiet: Verbesserung der Visualisierung und Abfragen auf Cubes

© Prof. T. Kudraß, HTWK Leipzig 5. Data Mining Daten – Information – Wissen – Weisheit Data Mining = erster Schritt zum Wissen Maschinelles Lernen verbündet sich mit Datenbanken – Clustering – Entscheidungsbäume – Neuronale Netze, Bayes-Netze – Zeitreihenanalyse Grundidee: Learning Table – Wird gefüllt in Trainingsphase – Genutzt zur Generierung synthetischer Daten (mit Wahrscheinlichkeiten) – Überprüfung von Werten (mit Unsicherheit) Forschung: bessere Mining-Algorithmen, Behandlung ungenauer und unsicherer Antworten

© Prof. T. Kudraß, HTWK Leipzig 6. Column Stores Tabellen mit Tausenden Spalten (die meisten NULL) z.B. LDAP: 7 geforderte und über 1000 optionale Attribute Klassischer Ansatz (Row Store) – Jedes Objekt ist Zeile einer Tabelle, aber sehr ineffizient – Große – aber dünn besetzte Tabellen Speicherung als ternäre Relation (Column Store) – Schlüssel, Attribute, Wert (Key-Value-Store) – Decomposition Storage Model – Außergewöhnliche Kompression (oft als Bitmap) – Erlaubt bessere Optimierung Forschung: automatische Algorithmen für Column Stores

© Prof. T. Kudraß, HTWK Leipzig 7. Text, Temporal, Spatial Data Access Datenbanken-Community von Information Retrieval (IR) isoliert Viele Anwendungen – Große Textbestände – Daten mit temporale und räumlichen Eigenschaften Stores Neue Datentypen in erweiterbaren DBMS – Erweiterung des SQL-Standards Ungenaue Antworten, probabilistisches Schließen (vor allem beim Text Retrieval) Herausforderung für traditionelle Datenbanken Noch keine klare Algebra für Integration dieser neuen Datentypen

© Prof. T. Kudraß, HTWK Leipzig 8. NoSQL Databases Nicht alle Daten relational Glaubenskrieg bei DB-Profis: Wieviel Struktur muss eine Datenbank haben? Integration von DB-Systemen mit File-Systemen Traditionelle File-Systeme nicht mehr ausreichend (in großen Unternehmen Milliarden von Dateien) Weiterentwicklung zu Datenbanksystemen Alternative Datenbankmodelle: – Dokumentenorientierte DB (z.B. CouchDB) – Graphen-DB – Key Value Stores

© Prof. T. Kudraß, HTWK Leipzig 9. Stream Processing Ständige Erzeugung von Daten durch Beobachtung der Umwelt – Teleskope – Bar-Code-Leser, die Frachtgut kontrollieren – Verkehrsdaten – RFID Scanner – Sensoren (z.B. Smart Dust) Abfragen auf diesen Daten (z.B. Historie) gewünscht Datenströme (Streams): verbieten persistente Speicherung und zeitaufwendige Verarbeitung innerhlab eine traditionellen DBMS Ziel: Datengetriebene Verarbeitung der potenziell unbeschränkten Datenströme, bei der sich ein System adaptiv verhalten sollte (z.B. in Bezug auf Datenankunftsrate) Klassische DBMS: bedarfsgesteuerte Verarbeitung endlicher Eingabemengen (im Allgemeinen Relationen) Entwicklung dezidierter Systeme = Datenstrommanagementsysteme (DSMS)

© Prof. T. Kudraß, HTWK Leipzig 10. Publish-Subscribe & Replication Publish-Distribute-Subscribe Modell weit verbreitet bei Massendaten Data Warehouses – große Datenarchive – Publizieren Teilmengen von Daten an Data Marts Real-Time Warehouse (Echtzeitnotifikation bei Datenänderungen), z.B. – Finanzapplikationen – Preisänderungen – Inventory Management – Bestandsänderungen – Information Retrieval – Content-Änderungen Ideen von aktiven Datenbanken Forschung: anspruchsvolle standing queries und bessere Optimierung für große Anzahl Queries and großes Datenvolumen

© Prof. T. Kudraß, HTWK Leipzig 11. Data Management on New Hardware Wachsende Kapazität von Platten und Hauptspeicher – 1 Sekunde zum Lesen des gesamten RAM – 20 Minuten zum Lesen der gesamten Disk Bei Terabyte-Datenbanken – Memory Scans dauern Minuten – Terabyte Disk Scans dauern Stunden Neue Algorithmen – zur intelligenten Nutzung von Multiprozessoren, die sich massiven Hauptspeicher teilen (Parallelisierung z.B. Map/Reduce) – zur intelligenten Nutzung der kostbaren Disk-Bandbreite Neue Speichermedien – Solid State Disks (SSD) Neue Ära: In-Memory Databases Green IT Issues

© Prof. T. Kudraß, HTWK Leipzig 12. Smart Objects: Databases Everywhere Ubiquitäres Computing (überall Sensor-Netzwerke) – Wearable Computing – Smart Dust Vom block-orientierten Disk-Interface zum File Interface zum Service Interface (in den nächsten 3 Jahrzehnten) Früher: Spezial-Hardware benötigt Heute: Disks haben schnelle Allzweck-Prozessoren (Moores Law) Wiedergeburt der Database Machines Verteilte Anfragetechnologie für Sensor-Netzwerke Konsequenz: Mini-Datenbanksysteme in Smart Dust

© Prof. T. Kudraß, HTWK Leipzig 13. Self Managing and Always Up Datenbanken sind überall – im File-System (z.B. auch -System) – auf der Platte – im Smart Dust – Viele, viele Anwendungen Was müssen Datenbanksysteme sein? – Self-managing – Self-organizing – Self-healing Verteilte Datenspeicher robuster machen in Richtung DB- Technologie – Datensicherheit – Effiziente Anfragebearbeitung

© Prof. T. Kudraß, HTWK Leipzig Schlußfolgerungen: Wie gehts weiter? Zusammenführen von exaktem und probabilistischem Schließen Modularität von DBMS (Web Service-Schnittstelle, Integration mit Programmiersprachen) Wiedervereinigung von Code und Daten hat entscheidende Bedeutung neue Algorithmen und neue Subsysteme ins DBMS Aus Datenbanksystemen werden Datenbankbetriebssysteme (Data Integrator, Mediator) Hardwareentwicklung treibt Entwicklung von DBMS voran (RAM, Speicher, Netzwerke) Informationslawine rollt weiter neue Herausforderungen für die Datenbanktechnologien