Telegraph Cq Italian

771 views

Published on

Workshop on TelegraphCQ:
Concept of Data Stram Management System.
TelegraphCQ: the DSMS developped at Berkley, internal architecture.
Differences between tradition database.
Adaptive QUery Processing using the new concept of Eddies like a routing operator.
Troubles about join Streams (with no statistical data) and Relations; and the two solution: STAIR and SteMs.
STAIR: a join operator that allow internal state changing using primite function visible to eddies.
SteMs: helf-join operator that keep homogeneous tuples, internal state is decision-indipendent.
Eddies Routing Policy implemented with the (Waldspurger & Weihl [1994]) Lottery Scheduling.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
771
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • DBMS Open Source, PostgreSQL, da cui partire per implementare TelegraphCQ.
  • Flux instradano le tuple fra le macchine di un cluster per supportare il parallelismo, il bilanciamento del carico e la tolleranza ai guasti
  • Pull, per esempio si connette ad un server mail e controlla la posta ogni minuto
  • I dati arrivati possono essere solo parti di tuple quindi è necessario bufferizzarle, ad ogni chiamata non è detto che avremo una tuplaWrapperState serve per fare comunicare funzioni utente con il WCH,Se arrivano meno campi saranno di default a NULL, e se ne arrivano troppi saranno troncati
  • The opportunity to impove:Optimizers pick a single plan for a queryHowever, different subsets of data may have very different statistical propertiesMay be more efficient to use different plans for different subsets of data
  • Telegraph Cq Italian

    1. 1. Berkley’sTelegraphCQ<br />Generalità di TelegraphCQ<br />Adattività con Eddies, SteMs e STAIR<br />Routing Policy: Lottery Scheduling<br />1<br />lunedì 18 luglio 2011<br />Alberto Minetti<br />Advanced Data Management @ DISI<br />Università degli Studi di Genova<br />
    2. 2. Data Stream Management System<br />Continuous, unbounded, rapid, time-varying streams of data elements<br />Occur in a variety of modern applications<br />Network monitoring and traffic engineering<br />Sensor networks, RFID tags<br />Telecom call records<br />Financial applications<br />Web logs and click-streams<br />Manufacturing processes<br />DSMS = Data Stream Management System<br />2<br />
    3. 3. L’inizio del progetto:Telegraph<br />Molte continuous query e molti data stream<br />Inizialmente in Java<br />Poi in C basato su PostgreSQL<br />No Scheduling distribuito <br />Non varia il livello di adattività per sovraccarichi<br />Non considera le risorse del sistema<br />Gestione dei dati completamente in memoria<br />3<br />
    4. 4. ReDesign:TelegraphCQ<br />Sviluppato alla Berkeley University<br />Scritto in C/C++<br />LicenzaOpenBSD<br />Basatosulcodice di PostgreSQL<br />Versionecorrente: 0.6 suPostgreSQL7.3.2<br />Progettochiusonel 2006<br />Importantipunti di interesse e caratteristiche<br />Software http://telegraph.cs.berkeley.edu<br />Papers http://db.cs.berkeley.edu/telegraph<br />Spinoff commercialeTruviso<br />4<br />
    5. 5. TelegraphCQ Architecture<br />PostgreSQL backends<br />Molti TelegraphCQ front-end<br />Un solo TelegraphCQ back-end<br />Front-End<br />Fork ad ogni connessione client<br />Non si occupa degli stream<br />Parsing query continue e le mette nella shared memory<br />Back-End ha un Eddy<br />che combina i query plans in uno<br />Può essere condiviso tra le query<br />Mette i risultati nella shared memory<br />5<br />
    6. 6. TelegraphCQ Architecture<br />Shared Memory<br />Query Plan Queue<br />TelegraphCQBack End<br />TelegraphCQBack End<br />TelegraphCQ Front End<br />Eddy Control Queue<br />Planner Parser Listener<br />Modules<br />Modules<br />Query Result Queues<br />Split<br />Mini-Executor<br />Proxy<br />CQEddy<br />CQEddy<br />}<br />Split<br />Split<br />Catalog<br />Scans<br />Scans<br />Shared Memory Buffer Pool<br />Wrappers<br />TelegraphCQ <br />Wrapper <br />ClearingHouse<br />Disk<br />6<br />Taken from Michael Franklin, UC Berkeley<br />
    7. 7. Tipologie di Moduli<br />Ingresso e Caching (Relazioni e Stream)<br />Interfaccia con i datasource esterni<br />Wrapper per HTML, XML, FileSystem, proxy P2P<br />Database remoti con supporto caching<br />Esecuzione di Query<br />Versioni non bloccanti di operatori classici (sel, proj)<br />SteMs, STAIRs<br />Routing adattivo<br />Per riottimizzare il piano durante l’esecuzione<br />Eddies: decidono routing tupla per tupla<br />Juggle: ordinamento al volo (per value o timestamp),<br />Flux: instradamento tra macchine di cluster<br />7<br />Fjords Framework<br />
    8. 8. Fjords<br />Framework in Java for Operators on Remote Data Streams<br />Interconnette i moduli<br />Supporta le code tra i moduli<br />Non-blocking<br />Supporto a Relazioni e a Stream<br />8<br />
    9. 9. Stream in TelegraphCQ<br />Unarchived Stream<br />Mai memorizzati su disco<br />Usano la shared memory tra executor e wrapper<br />Archived Stream<br />Append-only per passare tuple al sistema<br />No update, insert, delete; query aggregate con window<br />tcqtime di tipo TIMESTAMP per le window query<br />Con constraint TIMESTAMPCOLUMN<br />9<br />
    10. 10. DDL: Create Stream<br />10<br /> CREATE STREAM measurements (<br /> tcqtime TIMESTAMP TIMESTAMPCOLUMN, <br /> stationid INTEGER, <br /> speed REAL) <br /> TYPE ARCHIVED;<br /> CREATE STREAM tinydb (<br /> tcqtime TIMESTAMP TIMESTAMPCOLUMN,<br /> light REAL,<br /> temperature REAL)<br /> TYPE UNARCHIVED;<br />DROP STREAM measurements;<br />
    11. 11. Acquisizione di Dati<br />Le sorgenti devono identificarsi prima di inviare dati<br />Wrapper: funzioni user-defined<br />Come devono essere processati i dati<br />All’interno del Wrapper Clearinghouse process<br />Push sources<br />Iniziano una connessione con TelegraphCQ<br />Pull sources<br />Il wrapper inizia la connessione<br />Dati da Wrapper differenti possono confluire nello stesso stream<br />Heartbeat: tupla Punctuated senza dati, solo timestamp<br /> Quando arriva una tupla Punctuated non arriveranno dati antecedenti<br />11<br />
    12. 12. Wrappers nel WCH<br />Non-process-blocking over network socket (TCP/IP)<br />Wrapper funct chiamata quando ci sono dati sul socket<br />O quando ci sono dati nel buffer<br />se ritorna una tupla per volta (iteratore classico)<br />Ritorna array di PostgreSQL Datum<br />Init(WrapperState*) alloca risorse e lo stato<br />Next(WrapperState*) tuple in campo di WrapperState<br />Done(WrapperState*) libera risorse e distrugge lo stato<br />Usano la memoria di infrastruttura di PostgreSQL<br />12<br />
    13. 13. DDL: Create Wrapper<br />13<br /> CREATE FUNCTION measurements_init(INTEGER)<br /> RETURNS BOOLEAN<br /> AS ‘libmeasurements.so,measurements_init’<br /> LANGUAGE ‘C’;<br /> CREATE WRAPPER mywrapper (<br />init=measurements_init,<br />next=measurements_next,<br />done=measurements_done);<br />
    14. 14. HtmlGet and WebQueryServer<br />HtmlGet allows the user to execute a series of Html GET or POST requests to arrive at a page, and then to extract data out of the page using a TElegraph Screen Scrapperdefinition file. Once extracted, this data can be output to a CSV file.<br />Welcome to the TESS homepage. TESS is the TElegraph Screen Scrapper. It is part of The Telegraph Project at UC Berkeley. TESS is a program that takes data from web forms (like search engines or database queries) and turns it into a representation that is usable by a database query processor.<br />http://telegraph.cs.berkeley.edu/tess/<br />14<br />
    15. 15. self-monitoring capability<br />Tre stream speciali: info sullo stato del sistema<br />Supporto a query introspettive<br />Dynamic catalog<br />Interrogato come se fosse un qualsiasi stream<br />tcq_queries(tcqtime, qrynum, qid, kind, qrystr)<br />tcq_operators(tcqtime, opnum, opid, numqrs, kind, qid, opstr, opkind, opdesc)<br />tcq_queues(tcqtime, opid, qkind, kind)<br />15<br />
    16. 16. Esempio<br />16<br />Welcome to psql 0.2, the PostgreSQL interactive terminal.<br /># CREATE SCHEMA traffic;<br /># CREATE STREAM traffic.measurements<br />(stationid INT,<br /> speed REAL,<br />tcqtime TIMESTAMP TIMESTAMPCOLUMN<br />) TYPE ARCHIVED;<br /># ALTER STREAM traffic.measurements ADD WRAPPER csvwrapper;<br />$ cat tcpdump.log | source.pl localhost 5533 csvwrapper,network.tcpdum<br />Script di default TelegraphCQ scritto in Perl per simulare sorgenti che inviano dati CSV<br />Porta di default<br />
    17. 17. Load Shedding<br /> CREATE STREAM … TYPE UNARCHIVED ON OVERLOAD ????<br />BLOCK: si ferma (default)<br />DROP: scarta le tuple<br />KEEP<br />COUNTS: mantiene il numero di tuple scartate<br />REGHIST: costruisce un fixed-grid istog. delle shedded<br />MYHIST: costruisce un MHIST (multidimensionale)<br />WAVELET wavelet params<br /> Costruisce un istogramma wavelet<br />SAMPLE: mantiene un Reservoir Sample<br />17<br />
    18. 18. LoadShedding:SummaryStream<br />Per uno stream con il nome schema.stream<br />Vengono creati automaticamente due stream<br />schema.__stream_dropped<br />schema.__stream_kept<br />Per WAVELET, MYHIST, REHIST, COUNTS<br />Schema contenente:<br />Dati del summary<br />Intervallo del summary<br />Per i SAMPLE<br />Lo schema è lo stesso con la colonna __samplemult<br />Contiene il numero di tuple reali rappresentate<br />18<br />
    19. 19. Quering TelegraphCQ:StreaQuel<br />19<br />Query continue per:<br />Relazioni standard ereditate da PostgreSQL<br />Data stream windowed (sliding, hopping, jumping)<br />RANGE BY specifica la dimensione della window<br />SLIDE BY specifica quanto spesso si aggiorna<br />START AT indica quando iniziare la query<br />Opzionale<br />SELECT stream.color, COUNT(*)<br />FROM stream [RANGE BY ‘9’ SLIDE BY ‘1’]<br />GROUP BY stream.color<br />window<br />START OUPUT!<br />1<br />1<br />1<br />1<br />1<br />2<br />2<br />1<br />2<br />1<br />2<br />2<br />1<br />2<br />1<br />2<br />1<br />2<br />1<br />Adapted from Jarle Søberg<br />
    20. 20. Quering TelegraphCQ:StreaQuel (2)<br />wtime(*) ritorna l’ultimo timestamp nella window<br />Possiblità di query ricorsive con WITH [SQL 1999]<br />StreaQuel non ammette sotto query<br />20<br />SELECT S.a, wtime(*)<br />FROM<br /> S [RANGE BY ’10 seconds’ SLIDE BY ’10 second’],<br /> R [RANGE BY ’10 seconds’ SLIDE BY ’10 second’]<br />WHERE S.a = R.a;<br />Data Stream<br />Window<br />…<br />10 seconds<br />10 seconds<br />
    21. 21. Net Monitor Windowed Query<br />21<br />SELECT (CASE when outgoing = true<br /> then src_ip else dst_ip end) as inside_ip ,<br /> (CASE when outgoing = true<br /> then dst_ip else src_ip end) as outside_ip,<br />sum(bytes_sent) + sum(bytes_recv) as bytes<br />FROM flow [RANGE BY $w SLIDE BY $w]<br />GROUP BY inside_ip, outside_ip<br />Tutte le connessioni attive<br />SELECT src_ip, wtime(*),<br />COUNT(DISTINCT(dst_ip||dst_port)) AS fanout,<br />FROM flow [RANGE BY $w SLIDE BY $w]<br />WHERE outgoing = false<br />GROUP BY src_ip ORDER BY fanout DESC<br />LIMIT 100 PER WINDOW;<br />100 sorgenti con il massimo numero di connessioni<br />SELECT sum(bytes_sent), src_ip, wtime(*) AS now<br />FROM flow [RANGE BY $w SLIDE BY $w]<br />WHERE outgoing = false<br />GROUP BY src_ip ORDER BY sum(bytes_sent) DESC<br />LIMIT 100 PER WINDOW;<br />100 most significant sources of traffic<br />Taken from: İlkay Ozan Kay<br />
    22. 22. Evolutionary<br />Revolutionary<br />Adaptive Query Processing:Evoluzione<br />Static Late Inter Intra Per<br />Plans Binding Operator Operator Tuple<br />Traditional Dynamic QEP Query Scrambling Xjoin, DPHJ, Eddies<br />DBMS Parametric Mid-query Reopt. Convergent QP <br /> Competitive Progressive Opt.<br />Taken from: AmolDeshpande, Vijayshankar Raman<br />22<br />
    23. 23. Adaptive Query Processing:Scenario Attuale<br />Troppi piani possibili<br />Query parametriche<br />Query continue<br />Focus su output incrementali<br />Query complesse (10-20 relazioni in join)<br />Data Stream e dati asincroni<br />Statistiche non disponibile<br />Query interattive e preferenze dell’utente<br />Sharing dello stato<br />Molti più operatori<br />XML data e testo<br />Wide area federations<br />23<br />
    24. 24. Adaptive Query Processing:System R<br />Repeat<br />Osservare l’ambiente: daily/weekly (runstats)<br />Scegliere il comportamento (optimizer)<br />Se il piano attuale non è il migliore (analyzer)<br />Attuare il piano (executor)<br />Ottimizzazione basatasulcostodella query<br />Runstats-optimize-execute -> alta granularità<br />Adattività settimanale!<br />Goal: adattare per tupla<br />Unire le 4 funzioni<br />Measure<br />Actuate<br />Analyze<br />Plan<br />Taken from: Avnur, Hellerstein<br />24<br />
    25. 25. TelegraphCQ Executor:Eddy<br />Concetto preso dalla dinamica dei fluidi<br />continuously adaptive query processing mechanism<br />Eddy è un routing operator<br />Determina quali moduli devono essere visitati prima<br />Dopo che una tupla visita tutti i moduli va in output<br />Vede le tuple prima e dopo ogni operatore<br />25<br />Measure<br />Eddy<br />Analyze<br />Actuate<br />Plan<br />Taken from: Amol Deshpande, Vijayshankar Raman<br />
    26. 26. Eddies:Correttezza<br />Ogni tupla ha due BitVector<br />Ogni posizione corrisponde ad un operatore<br />Ready: identifica se la tupla è pronta per un operatore<br />Eddy può decidere quali tuple mandare ad un operatore<br />Done: identifica se una tupla ha subito un operatore<br />Eddy evita di inviare due volte ad un operatore<br />Quando tutti i bit di Done sono attivi -> output<br />Tuple joined hanno Ready e Done in bitwise-OR<br />SempliciselectionhannoReady=complement(Done)<br />26<br />
    27. 27. Eddies:Simple Selection Routing<br />27<br />S<br />SELECT *FROM SWHERE S.a > 10 AND S.b < 15<br /> AND S.c = 15<br />σa<br />σb<br />S.b < 15 <br />S.a > 10<br />Eddy<br />σc<br />S.c = 15 <br />σaσbσc<br />σaσbσc<br />15 ; 0 ; 15<br />S1<br />0 0 0<br />1 1 1<br />1 0 0<br />01 1<br />1 1 0<br />0 0 1<br />1 1 1<br />0 0 0<br />a<br />15<br />b<br />0<br />Ready<br />Done<br />c<br />15<br />Adapted from Manuel Hertlein<br />
    28. 28. S >< T<br />Relation Binary Join:R >< S >< T<br />Ordine di join<br />(R >< S) >< T<br />Va bene se si ha accesso diretto ai dati (indici o seq.)<br />28<br />R >< S<br />T<br />R<br />S<br />Taken from Jarle Søberg<br />
    29. 29. Stream Binary JoinR >< S >< T<br />29<br />Ordine di join<br />(R >< S) >< T<br />Ma se i dati sono inviati direttamente dalla sorgente...<br />S >< T<br />R >< S<br />Bloccare o gettare via delle tuple è inevitabile!<br />Taken from Jarle Søberg<br />
    30. 30. Necessaria una riottimizzazione al volo…<br />S >< T<br />30<br />Stream Binary JoinR >< S >< T<br />Possono esserci molti cambiamenti in uno stream<br />Riottimizzare può richiedere molto tempo<br />Non abbastanza dinamica!<br />R >< S<br />Taken from Jarle Søberg<br />
    31. 31. Stream Binary Join:Eddies<br />Usando un Eddy<br />Modello iniziale di Telegraph<br />31<br />S >< T<br />eddy<br />R >< S<br />Adattività tuple-based<br />Considera cambiamenti dinamici nello stream<br />Taken from Jarle Søberg<br />
    32. 32. Eddies:Sheduling Join problem<br />Sheduling sulla selettività dei join non funziona<br />Esempio<br />32<br />|S E|<br />|EC|<br />>><br />E and Carrive early; Sis delayed<br />S<br />E<br />C<br />time<br />Taken from Amol Deshpande<br />
    33. 33. 33<br />|S E|<br />|E C|<br />SE<br />HashTable<br />E.Name<br />HashTable<br />S.Name<br />Eddy<br />S<br />E<br />Output<br />C<br />HashTable<br />C.Course<br />HashTable<br />E.Course<br />Eddy decides to route E to EC<br />EC<br />>><br />E and Carrive early; Sis delayed<br />S0<br />sent and received suggest<br />S Join E is better option<br />S<br />S<br />E<br />S0<br />S –S0<br />E<br />C<br />time<br />C<br />SE<br />S0E<br />(S –S0)E<br />Eddy learns the correct sizes<br />Too Late !!<br />Taken from Amol Deshpande<br />
    34. 34. 34<br />State got embedded as a<br />result of earlier routing <br />decisions<br />|S E|<br />|EC|<br />SE<br />HashTable<br />E.Name<br />HashTable<br />S.Name<br />EC<br />Eddy<br />S<br />E<br />Output<br />C<br />HashTable<br />C.Course<br />HashTable<br />E.Course<br />SE<br />EC<br />>><br />E and Carrive early; Sis delayed<br />S<br />E<br />C<br />C<br />SE<br />S<br />E<br />Execution Plan Used<br />Query is executed using the worse plan!<br />Too Late !!<br />Taken from Amol Deshpande<br />
    35. 35. STAIRStorage, Transformation and Access for Intermediate Results<br />35<br />S.Name STAIR<br />Build into<br />S.Name STAIR<br />HashTable<br />E.Name STAIR<br />HashTable<br />Eddy<br />S<br />Output<br />E<br />C<br />HashTable<br />HashTable<br />E.Course STAIR<br />C.Course STAIR<br />Probe into <br />E.Name STAIR<br />Mostra lo stato interno del join all’eddy<br />Fornisce primitive di management dello stato<br />Demotion<br />Promotion<br />Operazioni per<br />Inserimento (build)<br />Lookup (probe)<br />s1<br />s1<br />s1<br />s1<br />Taken from Amol Deshpande<br />
    36. 36. STAIR: Demotion<br />36<br />e1<br />e1<br />e2c1<br />e2<br />s1e1<br />e2c1<br />e2<br />s1e1<br />S.Name STAIR<br />HashTable<br />E.Name STAIR<br />s1<br />Demoting di e2c1ae2:<br />Semplice proiezione<br />HashTable<br />e1<br />e2c1<br />e2<br />Eddy<br />S<br />s1e1<br />E<br />Output<br />C<br />HashTable<br />e2<br />s1e1<br />e2c1<br />HashTable<br />c1<br />Può essere pensato come un lavoro disfatto<br />E.Course STAIR<br />C.Course STAIR<br />Adapted from Amol Deshpande<br />
    37. 37. STAIR: Promotion<br />37<br />Promotinge1 using EC<br />e1<br />e1<br />e1c1<br />e1<br />e1c1<br />S.Name STAIR<br />HashTable<br />E.Name STAIR<br />s1<br />Due argomenti:<br /><ul><li>Una tupla
    38. 38. Un join</li></ul>HashTable<br />e1<br />e1c1<br />e2c1<br />Eddy<br />S<br />E<br />Output<br />C<br />HashTable<br />e2<br />s1e1<br />HashTable<br />c1<br />e1<br />Può essere pensato come una precomputazione di lavoro<br />E.Course STAIR<br />C.Course STAIR<br />Adapted from Amol Deshpande<br />
    39. 39. Demotion OR Promotion<br />38<br />Taken from Lifting the Burden of History from Adaptive Query Processing<br />Amol Deshpande and Joseph M. Hellerstein<br />
    40. 40. Demotion AND Promotion<br />Taken from Lifting the Burden of History from Adaptive Query Processing<br />Amol Deshpande and Joseph M. Hellerstein<br />39<br />
    41. 41. 40<br />S.Name STAIR<br />HashTable<br />|S E|<br />|EC|<br />S0<br />E<br />E<br />E<br />HashTable<br />E<br />E<br />E<br />C<br />C<br />C<br />S0E<br />Eddy decides to route E to EC<br />E.Course STAIR<br />>><br />E and Carrive early; Sis delayed<br />S0<br />E.Name STAIR<br />HashTable<br />S<br />E<br />E<br />Eddy<br />S<br />C<br />E<br />Output<br />C<br />time<br />E<br />HashTable<br />C<br />Eddy decides to migrateE<br />Eddy learns the correct selectivities<br />By promoting E using EC<br />C.Course STAIR<br />Adapted from Amol Deshpande<br />
    42. 42. 41<br />|S E|<br />|EC|<br />HashTable<br />E<br />C<br />S0E<br />E.Course STAIR<br />>><br />E and Carrive early; Sis delayed<br />S.Name STAIR<br />HashTable<br />S<br />S0<br />E.Name STAIR<br />HashTable<br />S<br />S –S0<br />S –S0<br />E<br />Eddy<br />S<br />C<br />(S –S0) EC<br />E<br />Output<br />C<br />time<br />E<br />HashTable<br />C<br />C.Course STAIR<br />Adapted from Amol Deshpande<br />
    43. 43. 42<br />EC<br />SE<br />C<br />S – S0<br />SE<br />EC<br />S0<br />E<br />E<br />C<br />HashTable<br />E<br />C<br />SE<br />E.Course STAIR<br />S.Name STAIR<br />HashTable<br />S<br />E.Name STAIR<br />HashTable<br />UNION<br />Eddy<br />S<br />E<br />Output<br />C<br />E<br />HashTable<br />C<br />Most of the data is<br />processed using the<br />correct plan<br />C.Course STAIR<br />Adapted from AmolDeshpande<br />
    44. 44. STAIR:Correttezza<br />Theorem [3.1]: An eddy with STAIRs always produces the correct query result in spite of arbitrary applications of the promotion and demotion operations.<br />STAIRs producono tutte le tuple<br />Non ci sono duplicati aggiunti<br />43<br />Taken from Lifting the Burden of History from Adaptive Query Processing<br />Amol Deshpande and Joseph M. Hellerstein<br />
    45. 45. State Module<br />Una sorta di repository temporaneo di dati<br />Operatore di Half-Join che memorizza tuple omogenee<br />Decisioni independenti<br />Supporta le operazioni<br />Inserimento (build)<br />Ricerca (probe)<br />Cancellazione (eviction) utili per le window<br />Simili a Mjoin ma più adattivi<br />Sharing dello stato tra altre query continue<br />Non memorizza i risultati intermedi<br />Aumento del costo di computazione<br />44<br />
    46. 46. Eddies Join with SteMs<br />45<br />T<br />R<br />S<br />eddy<br />R<br />T<br />S<br />Maggiore adattività<br />Eddy vede half-join<br />Diversi access method<br />Index access<br />Scan access<br />Simulano diversi join<br />In caso di sovraccarico?<br />Hash join (veloce)<br />Index join (mem limit)<br />Tipologie di Join?<br />Hash join (equi-join)<br />B-tree join (<, <=, >)<br />Query parametrica può essere vista come un join<br />Adapted from Jarle Søberg<br />
    47. 47. SteMs:Correttezza <br />46<br />R<br />S<br />Problema di correttezza<br />Possibili duplicati!!<br />Sequence number globale unico<br />Solo le più giovani possono fare il match<br />Taken from Jarle Søberg<br />
    48. 48. SteMs sliding Window<br />47<br />SELECT * <br />FROM Str [RANGE BY 5 Second<br /> SLIDE BY 2 Second],<br /> Relation,<br />WHERE Relation.a = Str.a<br />A|…….|18:49:36<br />R<br />B|…….|18:49:36<br />C|…….|18:49:37<br />A|…….|18:49:38<br />Mantenere lo stato per le sliding window (eviction)<br />Siamo al tempo 40, cosa succede al tempo 42?<br />Invece che ricreare tutta l’hash table vengono rimosse solo tuple vecchie e aggiunte le nuove<br />B|…….|18:49:39<br />C|…….|18:49:39<br />A|…….|18:49:40<br />B|…….|18:49:40<br />C|…….|18:49:40<br />Eviction!18:49:37<br />A|…….|18:49:41<br />B|…….|18:49:41<br />
    49. 49. Binary Join, STAIR, SteMconfronti<br />48<br />select *<br />from customer c, orders o, lineitem l<br />where c.custkey = o.custkey and<br /> o.orderkey = l.orderkey and<br /> c.nationkey = 1 and<br /> c.acctbal > 9000 and<br /> l.shipdate > date ’1996-01-01’<br />Recomputation necessaria<br />Non si adatta<br />lineitemarriva con shipdate crescente<br />Routing iniziale (O >< L) >< C<br />Taken from Lifting the Burden of History from Adaptive Query Processing<br />Amol Deshpande and Joseph M. Hellerstein<br />
    50. 50. Eddies:Routing Policy <br />Come scegliere il piano? Usando il Routing<br />Ogni tupla è instradata individualmente<br />Routing policy determina l’efficienza del sistema<br />Eddy ha un buffer di tuple con priorità<br />Inizialmente hanno bassa priorità<br />Quando escono da un operatore hanno alta priorità<br />Una tupla va in output il più presto possibile<br />Evita di congestionare il sistema<br />Permette un basso consumo di memoria<br />49<br />
    51. 51. Eddies’ Routing Policy:(old) Back-Pressure<br />Approccio Naive:<br />operatore più veloce prima<br />50<br />sel(s1) = sel(s2)<br />cost(s2) = 5<br />cost(s1) varia<br />cost(s1) = cost(s2)<br />sel(s2) = 50%<br />sel(s1) varia<br />Taken from: Avnur, Hellerstein<br />
    52. 52. Eddies’ Routing Policy:Lottery Scheduling<br />Waldspurger& Weihl nel 1994<br />Algoritmo per schedulare risorse condivise<br />« rapidlyfocus availableresources»<br />Ogni operatore inizia con un numero di ticket fissato<br />Operatore riceve un ticket quando prende una tupla<br />Favorisce gli operatori che consumano tuple velocemente<br />Operatore perde un ticket quando ritorna una tupla<br />Favorisce gli operatori con bassa selettività<br />Cioè quelli che ritornano poche tuple e ne processano tante<br />Quando due operatori concorrono per una tupla<br />La tupla viene assegnata all’operatore che vince la lotteria<br />Mai lasciare op senza ticket + randomexploration<br />51<br />
    53. 53. Eddies’ Routing Policy:Lottery Scheduling<br />Lottery Scheduling è meglio del Back-Pressure<br />52<br />cost(s1) = cost(s2)<br />sel(s2) = 50%<br />sel(s1) varia<br />Taken from: Avnur, Hellerstein<br />
    54. 54. Experiment<br />53<br />Stream: x con media 40 e deviazione standard 10<br />
    55. 55. 54<br />Experiment: variazione Stream<br />Stream: x con media 10 e deviazione standard 0<br />
    56. 56. 55<br />Experiment: variazione Stream (2)<br />Stream: x con media 10 e deviazione standard 0<br />
    57. 57. Other Works<br />Distribuited Eddies<br />Freddies: DHT-Based Adaptive Query Processing via Federated Eddies<br />Content-based Routing<br />Partial Results for Online Query Processing<br />Flux: An Adaptive Partitioning Operator for Continuous Query Systems<br />Java Support for Data-Intensive Systems: Experiences Building the Telegraph Dataflow System<br />Ripple Join for Online Aggregation<br />Highly Available, Fault-Tolerant, Parallel Dataflows<br />56<br />
    58. 58. Bibliografia<br />TelegraphCQ: An Architectural Status Report<br />Continuous Dataflow Processing for an Uncertain World<br />Enabling Real-Time Querying of Live and Historical Stream Data<br />Declarative Network Monitoring with an Underprovisioned Query Processor<br />Lifting the Burden of History from Adaptive Query Processing [STAIRs]<br />Eddies: Continuously Adaptive Query Processing<br />Using State Modules for Adaptive Query Processing<br />E altri… http://telegraph.cs.berkeley.edu/papers.html<br />Telegraph team @ UC Berkley: Mike Franklin, Joe Hellerstein, Bryan Fulton, Sirish Chandrasekaran, Amol Deshpande, Ryan Huebsch, Edwin Mach, Garrett Jacobson,Sailesh Krishnamurthy, Boon Thau Loo, Nick Lanham, Sam Madden, Fred Reiss, Mehul Shah, Eric Shan, Kyle Stanek, Owen Cooper, David Culler, Lisa Hellerstein, Wei Hong, Scott Shenker, Torsten Suel, Ion Stoica, Doug Tygar, Hal Varian, Ron Avnur, David Yu Chen, Mohan Lakhamraju, Vijayshankar Raman<br />Lottery Scheduling: Flexible Proportional-Share Resource Management<br />Carl A. Waldspurger & William E. Weihl @ MIT <br />57<br />

    ×