TelegraphCQ Manuel Hertlein

Inhalt Einleitung Konzepte und Module Architektur Ausblick

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

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

Inhalt Einleitung Konzepte und Module Architektur Ausblick

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

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

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

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

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

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

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

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

> < = ≠ 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

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

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

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

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

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); }

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

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

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

Inhalt Einleitung Konzepte und Module Architektur Ausblick

Design

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

Inhalt Einleitung Konzepte und Module Architektur Ausblick

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

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: http://telegraph.cs.berkeley.edu

Fragen

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).