1 / 23

Vorstellung des Streamkonzepts

Vorstellung des Streamkonzepts. Datenbanken und Informationssysteme Technische Universität Kaiserslautern Lehrgebiet Datenverwaltungssysteme Sommersemester 2005 Benjamin Mock. Inhalt. Anwendungsgebiete von Datenströmen Eigenschaften von Datenströmen Anfragen an Datenströme

elmer
Download Presentation

Vorstellung des Streamkonzepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Vorstellung des Streamkonzepts Datenbanken und Informationssysteme Technische Universität Kaiserslautern Lehrgebiet Datenverwaltungssysteme Sommersemester 2005 Benjamin Mock

  2. Inhalt • Anwendungsgebiete von Datenströmen • Eigenschaften von Datenströmen • Anfragen an Datenströme • Sliding Windows • Datenstrom-Management-Systeme (DSMS) • STREAM, AURORA, SPEX • Load Shedding 2

  3. Anwendungsgebiete • Nachrichtenüberwachung • Presse • Börse • Meteorologie • Multimediaströme • Netzwerkverwaltung • Verkehrsüberwachung 3

  4. Datenströme • potentiell unendlich • Ankunftsraten • unvorhersagbar • unbeeinflussbar • benötigen Echtzeit-Verarbeitung • Unterscheidung zwischen • Punkt- / Tupelströme • XML-Ströme Speicherung nur eingeschränkt möglich! 4

  5. Datenströme II • push-Kommunikation • Daten durch mehrere externe Quellen (Sensoren, …) • Ergebnisse ebenfalls als Datenstrom • Information des Benutzers • zu bestimmten Zeitpunkten • bei anormalen Werten • bei jedem Tupel • DBMS-Active, Human-Passive = DAHP 5

  6. DSMS DBMS persistent transient beliebig Daten exakt beliebig transient persistent nur hinzufügen Anfragen Evtl. angenähert Einpass-Verfahren Daten Anfragen Änderungen Indizierung Ergebnisse Datenzugriff 6

  7. Anfragen • einmalige Anfragen • wird aktiv vom Benutzer einmalig gestellt • Schnappschuss des Zustands zu einemZeitpunkt • kontinuierliche Anfragen • befindet sich im System und wird kontinuierlich an neu ankommende Daten gestellt • Auswertung über einen Zeitraum 7

  8. Anfragen II • Ad-hoc-Anfrage • zu beliebigem Zeitpunkt gestellt • frühere Daten? • ignorieren • Zusammenfassungen speichern • vordefinierte Anfrage • bekannt, bevor Daten ankommen • kontinuierliche oder geplante einmalige Anfrage 8

  9. Sliding Windows • Problem: blockierende Operationen • join, avg, max, min … • Lösung: Sliding Windows • zeitbasiert • tupelbasiert • partitioniert 9

  10. Sliding Windows II • selbstbeschreibende Technik • deterministisch: Anfrage über die selben Daten bringt gleiches Ergebnis • nur neue Daten in Auswertung • Benutzer • versteht die Erstellung des Ergebnisses • kann Qualität und Exaktheit in etwa abschätzen • gute Möglichkeit angenäherte Ergebnisse zu produzieren 10

  11. DSMS: STREAM • STanford stREam datAManager • Anfragesprache: CQL continuous query language • Bearbeitung kontinuierlicher Anfragen über Datenströme und Relationen • Anfrageplan aus 3 Komponenten • Anfrage-Operatoren • Inter-Operator-Warteschlangen • Synopsen • Beispiel: • SELECT * • FROM R, S • WHERE R.name = S.name 11

  12. DSMS: STREAM-Komponenten • Operatoren • ähneln denen in DBMS • lesen Eingabeströme • erstellen Ausgabestrom • Warteschlangen • verbinden Operatoren untereinander • Synopsen • Zusammenfassung bisheriger Daten • Trade-off zwischen Präzision und Speicher • Sliding Windows als Synopsen 12

  13. DSMS: STREAM III • Zusammenspiel der Operatoren 13

  14. DSMS: AURORA • Kollaboration von Brandeis University, Brown University, MIT • unterstützt kontinuierliche / Ad-hoc-Anfragen, Sichten • Anfragesprache: SQuAl für Stream Query Algebra • Box-and-Arrow-Modell • sieben Operatoren • filter, map, union, bsort, aggregate, join, resample 14

  15. DSMS: AURORA II • Box-and-Arrow-Modell 15

  16. XPATH • Adressierung von Teilen eines XML-Dokuments mittels Pfad-Notation <journal> <title>databases</title> <editor>anna</editor> <authors> <name>anna</name> <name>bob</name> </authors> <price /> </journal> Kontextknoten: journal Lokalisierungspfad: child::* title, editor, authors, price 16

  17. XPATH Achsensymmetrie 17

  18. DOM = Document Object Model SAX = Simple API for XML XML-Parser: DOM vs. SAX • programmiersprachenunabhängiger Zugriff auf XML-Dokumente • hoher Bedarf an • Hauptspeicher • + beliebiger Zugriff • nicht geeignet für Datenströme geeignet + geringerer Bedarf an Hauptspeicher - nur sequentieller Zugriff 18

  19. XML-Parser: SAX Beispiel • Jedes XML-Token ist SAX-Ereignis • öffnende Markierung <impressum> • Text • schließende Markierung </impressum> • entsprechender Eventhandler für jedes Ereignis <impressum> Version 1.0 of the Simple API for XML (SAX) </impressum> 19

  20. DSMS: SPEX • Streamed and Progressive Emulator for XPATH • wertet vorwärtsgerichtete XPATH-Anfragen gegen XML-Ströme aus • überführt diese Anfragen in Automatennetzwerke • Auswertung in 4 Schritten Forward XPATH Anfrage Ausgabe- strom XPATH Anfrage logischer Anfrageplan physischer Anfrageplan 20

  21. DSMS: SPEX Anfrageplan /descedant::a[child::b[descendant::d or child::e]]following-sibing::c • Jedes Token des Eingabestroms entspricht SAX Ereignis • Automaten • nutzen Stack um Position der XML-Elemente zu bestimmen • führen genau einen Lokalisierungsschritt durch • annotieren Strom um Kontextknoten zu markieren, oder leiten unverändert weiter 21

  22. Load Shedding • Problem: CPU zu langsam, Hauptspeicher zu klein für ankommenden Datenstrom = Überlast • Lösung: kontrolliertes Verwerfen von Daten ohne hohen Genauigkeitsverlust = Load Shedding • am Beispiel Aurora: Daten verwerfen, aber • wann • wo im Anfrageplan • wie viel • zufällig • semantisch mit QoS Graphen • Latency-Graph • Loss-Tolerance-Graph • Value-Based-Graph 22

  23. Zusammenfassung bekannte Techniken aus traditionellen DBMS nicht einfach übertragbar • keine Speicherung vor Verarbeitung möglich • push-Kommunikation • Einpass-Verfahren, weil nur einmaliger sequentieller Zugriff auf Daten • Echtzeitverarbeitung • exakte Anfrageauswertung nicht möglich bei • Ad-hoc-Anfragen bezüglich vergangener Daten • Überlast • aggregierenden oder sortierenden Operationen 23

More Related