TelegraphCQ Manuel Hertlein.

Präsentation zum Thema: "TelegraphCQ Manuel Hertlein."—  Präsentation transkript:

1 TelegraphCQ Manuel Hertlein

2 Inhalt Einleitung Konzepte und Module Architektur Ausblick

3 Vergleich DBMS  DSMS Database Management System (DBMS)
Data Stream Management System (DSMS) Persistente Daten Einmalige Anfragen Verarbeitung anfragegetrieben Menge der Daten ist potenziell begrenzt Flüchtige Datenströme Kontinuierliche Anfragen Verarbeitung datengetrieben Menge der Daten ist potenziell unbeschränkt

4 Allgemeine Anforderungen an ein DSMS-System
Aktuelle Anfragen in geeigneter Form festhalten und über bestimmten Zeitraum ausführen Eingehende Datenpakte an alle Anfragen leiten, die Daten des entsprechenden Typs beobachten Durch Anfrage dürfen Pakete nicht für andere Anfragen blockiert werden Auf Änderungen des Datenstroms bei laufender Abfrage durch Umstellen des Routing reagieren

5 Inhalt Einleitung Konzepte und Module Architektur Ausblick

6 Kontinuierliche Abfragen mit TelegraphCQ
TelegraphCQ Projekt der Datenbankforschungsgruppe der UC Berkely Framework mit Query-Engine für kontinuierliche, adaptive Abfragen auf Datenströme Vereint die Arbeiten und Erkenntnisse aus CACQ (Continously Adap- tive Continous Queries over Streams) PSoup

7 Eddies (1/4) Operator leitet Tupel aus ver-schiedenen Datenquellen zu Query-Operatoren Operatoren besitzen Eingangs-queue, in die zu bearbeitende Tupel abgelegt werden Anschließend an Eddy zurück-geschickt und von diesem wie-tergeleitet Für jedes Tupel kann indivi-duelle Reihenfolge zum Durch-laufen der Operatoren erstellt werden

8 Eddies (2/4)  Einzelne Abfrage
SELECT * FROM S WHERE S.a > 10 AND S.b < 15 S.a > 10 S.b < 15 Eddy S S1 σaσb σaσb a 15 1 1 0 0 b Ready Done

9 Eddies (2/4)  Einzelne Abfrage
SELECT * FROM S WHERE S.a > 10 AND S.b < 15 S.a > 10 S.b < 15 Eddy S S1 σaσb σaσb a 15 0 1 1 0 b Ready Done

10 Eddies (3/4) Aufbau Continuous Query Tupel Format Data Fields
ready 1 bit x O done 1 bit x O sourceId integer completedQueries 1 bit x Q O = #Operatoren in Eddy Q = #Queries in Eddy Completition Mask Done Queries completed σa σb σc 1 1 0 Q1 Q2 1 0 Completition Mask Q1 a b c Completition Mask Q2 0 1 1 & & 1 1 0 0 1 0

11 Eddies (4/4)  Mehrere Abfragen
SELECT * FROM S WHERE S.a > 10 AND S.b < 15 S.b < 15 S.b < 10 S.a > 10 Q1 Eddy SELECT * FROM S WHERE S.b < 10 AND S.c = 15 σc Q2 S.c = 15 S S2 Ready Done σaσbσc 1 1 1 0 0 0 Queries completed Q1 Q2 0 0 a 15 b c 24

12 Eddies (4/4)  Mehrere Abfragen
SELECT * FROM S WHERE S.a > 10 AND S.b < 15 S.b < 15 S.b < 10 S.a > 10 Q1 Eddy SELECT * FROM S WHERE S.b < 10 AND S.c = 15 σc Q2 S.c = 15 S S2 Ready Done σaσbσc 0 1 1 1 0 0 Queries completed Q1 Q2 0 0 a 15 b c 24

13 Eddies (4/4)  Mehrere Abfragen
SELECT * FROM S WHERE S.a > 10 AND S.b < 15 S.b < 15 S.b < 10 S.a > 10 Q1 Eddy SELECT * FROM S WHERE S.b < 10 AND S.c = 15 σc Q2 S.c = 15 S S2 Ready Done σaσbσc 0 0 1 1 1 0 Queries completed Q1 Q2 1 0 a 15 b c 24

14 > < = ≠ Gruppenfilter Tupel Prädikate Gruppenfilter 6
P1: S.a > 1 P2: S.a > 6 P3: S.a > 11 11 1 > >6 >11 >1 P2 P3 P1 3 S.a 8 P4: S.a < 3 P5: S.a < 5 < <5 <3 P5 P4 P6 6 8 P7 P6: S.a = 6 P7: S.a = 8 = ≠ P8: S.a ≠ 4 4 P8

15 State Modules (SteMs) (1/3)
Baum aus Hash Joins RxS T R S T R S

16 State Modules (SteMs) (2/3)
SteMR SteMS SteMT probe PR PRS build TR PR probe PRS PRST Eddy TR R S T

17 State Modules (SteMs) (3/3)  PSoup-Erweiterung
Date STeM Streaming Data Sources Query STeM Clients Probe Probe Symmetric Join Data Build Queries Build PSoup-Eddy

18 Routing Ziel: Anzahl der Operatoren, die durch-schnittlich durchlaufen werden, soll minimiert werden Operatoren werden je nach Selektivität mit Tickets versehen Jeder Operator bekommt ein Ticket wenn ein Tupel ihn betritt und eines abgezogen, wenn ein Tupel ihn verlässt Operatoren mit mehr Tickets (hoher Selektivität) werden bevorzugt ausgewählt

19 Abfragefenster (1/2) Datenquelle vibration_stream
Tupel location, value, timestamp Snapshot Query SELECT value, timestamp FROM vibration_stream WHERE location = `Golden Gate Bridge´ WINDOW vibration_stream, ST-7, ST) Landmark Query SELECT value, timestamp FROM vibration_stream WHERE location = `Golden Gate Bridge´ AND value > 50 for (t = ST; t <= ST+100; t++) { WINDOW(vibration_stream, ST, t); }

20 Abfragefenster (2/2) Sliding Query SELECT AVG(value)
FROM vibration_stream WHERE location = `Golden Gate Bridge´ for (t = ST; t < ST + 70; t+=7) { WINDOW(vibration_stream, t-6, t); } SELECT s2.* FROM vibration_stream1 AS s1, vibration_stream2 AS s2 WHERE s1.location = `Golden Gate Bridge´ AND s1.value < s2.value AND s1.timestamp = s2.timestamp for (t = ST; t < ST + 70; t++) { WINDOW(vibration_stream1, t-6, t); WINDOW(vibration_stream2, t-6, t); Temporal Band-Join

21 Fjords Schnittstelle für Kom-munikation und Daten-austausch zwischen Eddies, Operatoren, SteMs und Datenquellen Queues die sowohl Pull- (statische Daten) als auch Push-Techni-ken (Datenströme) implementieren S Push σ Push T Pull get

22 Flux Flux = Fault-tolerant, Load-balancing eXchange Ziele Umsetzung
Höhere Ausfallsicherheit Wenn Knoten ausfällt, wird aktueller Input für diesen Knoten automatisch auf andere Knoten umgelenkt Gleichmäßige Auslastung des parallelen Systems Neuaufteilung des Input-Streams auf verschiedene Knoten

23 Inhalt Einleitung Konzepte und Module Architektur Ausblick

24 Design

25 Shared Memory Buffer Pool
Arbeitsweise TelegraphCQ Executor TelegraphCQ Front End Listener Parser Optimizer Catalog Shared Memory Shared Memory Buffer Pool Query Plan Queue Query Result Queue Disk SteMs Eddy TelegraphCQ Wrapper Query & Control Data Tuples

26 Inhalt Einleitung Konzepte und Module Architektur Ausblick

27 Offene Themen Steuerung der Adaptivität
Evaluierung und Weiterentwicklung von Routing-Schemata Gruppierung und Aufteilung von Anfragen auf einzelne Threads Effiziente Verwendung von Festplattenspeicher bei Auswertung von Streams Anpassung der Flux-Module für Cluster-Version Entwicklung einer verteilten Version von TelegraphCQ

28 Zusammenfassung Entwicklung von Pervasive Computing entstehen Unmengen an Daten und Datenströmen Konventionelle Techniken stoßen an ihre Grenzen TelegraphCQ vereint nützliche Techniken für kontinuierliche, adaptive Datenabfragen Baut auf Open-Source-Projekt PostgreSQL auf (traditionelle Datenbanktechnik) Kann von Erfahrungen und Entwicklung profitie-ren, muss aber auch Kompromisse bei Design eingehen Unterscheidet sich von anderen Projekten durch großen Fokus auf Adaptivität TelegraphCQ Version 2.1 auf Projektseite verfügbar:

29 Fragen

30 Quellen S. Chandrasekaran, et al.: TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. in CIDR (2003). S. Madden, et al.: Continouosly Adaptive Continouos Queries over Streams. in SIGMOD (2002). S. Manten: TelegraphCQ. in Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung (2005).