Datenbanksysteme in der Zukunft Prof T Kudra HTWK
Datenbanksysteme in der Zukunft
© Prof. T. Kudraß, HTWK Leipzig Entwicklungslinien 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Object Relational Arrives Databases in the Cloud Queues, Transactions, Workflows Cubes and Online Analytical Processing Data Mining Column Stores Text, Temporal, and Spatial Data Access No. SQL Data Streams Publish-Subscribe and Replication Data Management on New Hardware Smart Objects: Databases Everywhere Self-Managing and Always Up
l l l – l order_no cust_info line_items amount Sündenfall Cobol: Trennung in Data Division Hold und Procedure Division DB Community hat das übernommen Bemühungen um Wiedervereinigung seit 40 Jahren – l Ship Stored Procedures Objekt-relationale DBMS (seit Mitte 90 er 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 Cancel 1. Object Relational Arrives Check. Status © Prof. T. Kudraß, HTWK Leipzig
© Prof. T. Kudraß, HTWK Leipzig 2. Databases in the Cloud Storage als Ressource des Cloud Computing, verschiedene Kategorien (Weiterentwicklung der Idee: DB as a Service) l BLOB Storage: Virtuelles Dateisystem – – l Table Storage: Big. Table-Ansatz, No. SQL-Datenbank – – l Speicherung von Text- und Binärdaten in der Cloud Zugriff über APIs, SOAP, REST Big. Table-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 l Internet-Anwendung: – – l 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 l Frühe relationale Systeme: – – l Frühe 90 er: Data Cubes als typisches OLAP-Pattern (Aggregation von Daten entlang verschiedener Dimensionen) – – l Indexe als Tabellen-Replikate Frühe Ideen führten zu Materialized Views mit schnellem Zugriff auf Star und Snowflake Schema 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 l l l Daten – Information – Wissen – Weisheit Data Mining = erster Schritt zum Wissen Maschinelles Lernen verbündet sich mit Datenbanken – – l Grundidee: Learning Table – – – l Clustering Entscheidungsbäume Neuronale Netze, Bayes-Netze Zeitreihenanalyse 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 l Tabellen mit Tausenden Spalten (die meisten NULL) z. B. LDAP: 7 geforderte und über 1000 optionale Attribute l Klassischer Ansatz (Row Store) – – l Speicherung als ternäre Relation (Column Store) – – l Jedes Objekt ist Zeile einer Tabelle, aber sehr ineffizient Große – aber dünn besetzte Tabellen 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 l l Datenbanken-Community von Information Retrieval (IR) isoliert Viele Anwendungen – – l l 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. No. SQL Databases l l l 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. Couch. DB) Graphen-DB Key Value Stores
© Prof. T. Kudraß, HTWK Leipzig 9. Stream Processing l Ständige Erzeugung von Daten durch Beobachtung der Umwelt – – – l l l 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 l l Publish-Distribute-Subscribe Modell weit verbreitet bei Massendaten Data Warehouses – – l Real-Time Warehouse (Echtzeitnotifikation bei Datenänderungen), z. B. – – – l l große Datenarchive Publizieren Teilmengen von Daten an Data Marts 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 l Wachsende Kapazität von Platten und Hauptspeicher – – l Bei Terabyte-Datenbanken – – l zur intelligenten Nutzung von Multiprozessoren, die sich massiven Hauptspeicher teilen (Parallelisierung z. B. Map/Reduce) zur intelligenten Nutzung der kostbaren Disk-Bandbreite Neue Speichermedien – l Memory Scans dauern Minuten Terabyte Disk Scans dauern Stunden Neue Algorithmen – l 1 Sekunde zum Lesen des gesamten RAM 20 Minuten zum Lesen der gesamten Disk Solid State Disks (SSD) Neue Ära: In-Memory Databases Green IT Issues
© Prof. T. Kudraß, HTWK Leipzig 12. Smart Objects: Databases Everywhere l Ubiquitäres Computing (überall Sensor-Netzwerke) – – l l l 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 (Moore‘s 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 l Datenbanken sind überall – – l Was müssen Datenbanksysteme sein? – – – l im File-System (z. B. auch E-Mail-System) auf der Platte im Smart Dust Viele, viele Anwendungen Self-managing Self-organizing Self-healing Verteilte Datenspeicher robuster machen in Richtung DBTechnologie – – Datensicherheit Effiziente Anfragebearbeitung
© Prof. T. Kudraß, HTWK Leipzig Schlußfolgerungen: Wie geht’s weiter? l l l 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
- Slides: 16