• Save
Telegraph Cq Italian
Upcoming SlideShare
Loading in...5
×
 

Telegraph Cq Italian

on

  • 684 views

Workshop on TelegraphCQ:...

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.

Statistics

Views

Total Views
684
Views on SlideShare
683
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Telegraph Cq Italian Presentation Transcript

  • Berkley’sTelegraphCQ
    Generalità di TelegraphCQ
    Adattività con Eddies, SteMs e STAIR
    Routing Policy: Lottery Scheduling
    1
    lunedì 18 luglio 2011
    Alberto Minetti
    Advanced Data Management @ DISI
    Università degli Studi di Genova
  • Data Stream Management System
    Continuous, unbounded, rapid, time-varying streams of data elements
    Occur in a variety of modern applications
    Network monitoring and traffic engineering
    Sensor networks, RFID tags
    Telecom call records
    Financial applications
    Web logs and click-streams
    Manufacturing processes
    DSMS = Data Stream Management System
    2
  • L’inizio del progetto:Telegraph
    Molte continuous query e molti data stream
    Inizialmente in Java
    Poi in C basato su PostgreSQL
    No Scheduling distribuito
    Non varia il livello di adattività per sovraccarichi
    Non considera le risorse del sistema
    Gestione dei dati completamente in memoria
    3
  • ReDesign:TelegraphCQ
    Sviluppato alla Berkeley University
    Scritto in C/C++
    LicenzaOpenBSD
    Basatosulcodice di PostgreSQL
    Versionecorrente: 0.6 suPostgreSQL7.3.2
    Progettochiusonel 2006
    Importantipunti di interesse e caratteristiche
    Software http://telegraph.cs.berkeley.edu
    Papers http://db.cs.berkeley.edu/telegraph
    Spinoff commercialeTruviso
    4
  • TelegraphCQ Architecture
    PostgreSQL backends
    Molti TelegraphCQ front-end
    Un solo TelegraphCQ back-end
    Front-End
    Fork ad ogni connessione client
    Non si occupa degli stream
    Parsing query continue e le mette nella shared memory
    Back-End ha un Eddy
    che combina i query plans in uno
    Può essere condiviso tra le query
    Mette i risultati nella shared memory
    5
  • TelegraphCQ Architecture
    Shared Memory
    Query Plan Queue
    TelegraphCQBack End
    TelegraphCQBack End
    TelegraphCQ Front End
    Eddy Control Queue
    Planner Parser Listener
    Modules
    Modules
    Query Result Queues
    Split
    Mini-Executor
    Proxy
    CQEddy
    CQEddy
    }
    Split
    Split
    Catalog
    Scans
    Scans
    Shared Memory Buffer Pool
    Wrappers
    TelegraphCQ
    Wrapper
    ClearingHouse
    Disk
    6
    Taken from Michael Franklin, UC Berkeley
  • Tipologie di Moduli
    Ingresso e Caching (Relazioni e Stream)
    Interfaccia con i datasource esterni
    Wrapper per HTML, XML, FileSystem, proxy P2P
    Database remoti con supporto caching
    Esecuzione di Query
    Versioni non bloccanti di operatori classici (sel, proj)
    SteMs, STAIRs
    Routing adattivo
    Per riottimizzare il piano durante l’esecuzione
    Eddies: decidono routing tupla per tupla
    Juggle: ordinamento al volo (per value o timestamp),
    Flux: instradamento tra macchine di cluster
    7
    Fjords Framework
  • Fjords
    Framework in Java for Operators on Remote Data Streams
    Interconnette i moduli
    Supporta le code tra i moduli
    Non-blocking
    Supporto a Relazioni e a Stream
    8
  • Stream in TelegraphCQ
    Unarchived Stream
    Mai memorizzati su disco
    Usano la shared memory tra executor e wrapper
    Archived Stream
    Append-only per passare tuple al sistema
    No update, insert, delete; query aggregate con window
    tcqtime di tipo TIMESTAMP per le window query
    Con constraint TIMESTAMPCOLUMN
    9
  • DDL: Create Stream
    10
    CREATE STREAM measurements (
    tcqtime TIMESTAMP TIMESTAMPCOLUMN,
    stationid INTEGER,
    speed REAL)
    TYPE ARCHIVED;
    CREATE STREAM tinydb (
    tcqtime TIMESTAMP TIMESTAMPCOLUMN,
    light REAL,
    temperature REAL)
    TYPE UNARCHIVED;
    DROP STREAM measurements;
  • Acquisizione di Dati
    Le sorgenti devono identificarsi prima di inviare dati
    Wrapper: funzioni user-defined
    Come devono essere processati i dati
    All’interno del Wrapper Clearinghouse process
    Push sources
    Iniziano una connessione con TelegraphCQ
    Pull sources
    Il wrapper inizia la connessione
    Dati da Wrapper differenti possono confluire nello stesso stream
    Heartbeat: tupla Punctuated senza dati, solo timestamp
    Quando arriva una tupla Punctuated non arriveranno dati antecedenti
    11
  • Wrappers nel WCH
    Non-process-blocking over network socket (TCP/IP)
    Wrapper funct chiamata quando ci sono dati sul socket
    O quando ci sono dati nel buffer
    se ritorna una tupla per volta (iteratore classico)
    Ritorna array di PostgreSQL Datum
    Init(WrapperState*) alloca risorse e lo stato
    Next(WrapperState*) tuple in campo di WrapperState
    Done(WrapperState*) libera risorse e distrugge lo stato
    Usano la memoria di infrastruttura di PostgreSQL
    12
  • DDL: Create Wrapper
    13
    CREATE FUNCTION measurements_init(INTEGER)
    RETURNS BOOLEAN
    AS ‘libmeasurements.so,measurements_init’
    LANGUAGE ‘C’;
    CREATE WRAPPER mywrapper (
    init=measurements_init,
    next=measurements_next,
    done=measurements_done);
  • HtmlGet and WebQueryServer
    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.
    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.
    http://telegraph.cs.berkeley.edu/tess/
    14
  • self-monitoring capability
    Tre stream speciali: info sullo stato del sistema
    Supporto a query introspettive
    Dynamic catalog
    Interrogato come se fosse un qualsiasi stream
    tcq_queries(tcqtime, qrynum, qid, kind, qrystr)
    tcq_operators(tcqtime, opnum, opid, numqrs, kind, qid, opstr, opkind, opdesc)
    tcq_queues(tcqtime, opid, qkind, kind)
    15
  • Esempio
    16
    Welcome to psql 0.2, the PostgreSQL interactive terminal.
    # CREATE SCHEMA traffic;
    # CREATE STREAM traffic.measurements
    (stationid INT,
    speed REAL,
    tcqtime TIMESTAMP TIMESTAMPCOLUMN
    ) TYPE ARCHIVED;
    # ALTER STREAM traffic.measurements ADD WRAPPER csvwrapper;
    $ cat tcpdump.log | source.pl localhost 5533 csvwrapper,network.tcpdum
    Script di default TelegraphCQ scritto in Perl per simulare sorgenti che inviano dati CSV
    Porta di default
  • Load Shedding
    CREATE STREAM … TYPE UNARCHIVED ON OVERLOAD ????
    BLOCK: si ferma (default)
    DROP: scarta le tuple
    KEEP
    COUNTS: mantiene il numero di tuple scartate
    REGHIST: costruisce un fixed-grid istog. delle shedded
    MYHIST: costruisce un MHIST (multidimensionale)
    WAVELET wavelet params
    Costruisce un istogramma wavelet
    SAMPLE: mantiene un Reservoir Sample
    17
  • LoadShedding:SummaryStream
    Per uno stream con il nome schema.stream
    Vengono creati automaticamente due stream
    schema.__stream_dropped
    schema.__stream_kept
    Per WAVELET, MYHIST, REHIST, COUNTS
    Schema contenente:
    Dati del summary
    Intervallo del summary
    Per i SAMPLE
    Lo schema è lo stesso con la colonna __samplemult
    Contiene il numero di tuple reali rappresentate
    18
  • Quering TelegraphCQ:StreaQuel
    19
    Query continue per:
    Relazioni standard ereditate da PostgreSQL
    Data stream windowed (sliding, hopping, jumping)
    RANGE BY specifica la dimensione della window
    SLIDE BY specifica quanto spesso si aggiorna
    START AT indica quando iniziare la query
    Opzionale
    SELECT stream.color, COUNT(*)
    FROM stream [RANGE BY ‘9’ SLIDE BY ‘1’]
    GROUP BY stream.color
    window
    START OUPUT!
    1
    1
    1
    1
    1
    2
    2
    1
    2
    1
    2
    2
    1
    2
    1
    2
    1
    2
    1
    Adapted from Jarle Søberg
  • Quering TelegraphCQ:StreaQuel (2)
    wtime(*) ritorna l’ultimo timestamp nella window
    Possiblità di query ricorsive con WITH [SQL 1999]
    StreaQuel non ammette sotto query
    20
    SELECT S.a, wtime(*)
    FROM
    S [RANGE BY ’10 seconds’ SLIDE BY ’10 second’],
    R [RANGE BY ’10 seconds’ SLIDE BY ’10 second’]
    WHERE S.a = R.a;
    Data Stream
    Window

    10 seconds
    10 seconds
  • Net Monitor Windowed Query
    21
    SELECT (CASE when outgoing = true
    then src_ip else dst_ip end) as inside_ip ,
    (CASE when outgoing = true
    then dst_ip else src_ip end) as outside_ip,
    sum(bytes_sent) + sum(bytes_recv) as bytes
    FROM flow [RANGE BY $w SLIDE BY $w]
    GROUP BY inside_ip, outside_ip
    Tutte le connessioni attive
    SELECT src_ip, wtime(*),
    COUNT(DISTINCT(dst_ip||dst_port)) AS fanout,
    FROM flow [RANGE BY $w SLIDE BY $w]
    WHERE outgoing = false
    GROUP BY src_ip ORDER BY fanout DESC
    LIMIT 100 PER WINDOW;
    100 sorgenti con il massimo numero di connessioni
    SELECT sum(bytes_sent), src_ip, wtime(*) AS now
    FROM flow [RANGE BY $w SLIDE BY $w]
    WHERE outgoing = false
    GROUP BY src_ip ORDER BY sum(bytes_sent) DESC
    LIMIT 100 PER WINDOW;
    100 most significant sources of traffic
    Taken from: İlkay Ozan Kay
  • Evolutionary
    Revolutionary
    Adaptive Query Processing:Evoluzione
    Static Late Inter Intra Per
    Plans Binding Operator Operator Tuple
    Traditional Dynamic QEP Query Scrambling Xjoin, DPHJ, Eddies
    DBMS Parametric Mid-query Reopt. Convergent QP
    Competitive Progressive Opt.
    Taken from: AmolDeshpande, Vijayshankar Raman
    22
  • Adaptive Query Processing:Scenario Attuale
    Troppi piani possibili
    Query parametriche
    Query continue
    Focus su output incrementali
    Query complesse (10-20 relazioni in join)
    Data Stream e dati asincroni
    Statistiche non disponibile
    Query interattive e preferenze dell’utente
    Sharing dello stato
    Molti più operatori
    XML data e testo
    Wide area federations
    23
  • Adaptive Query Processing:System R
    Repeat
    Osservare l’ambiente: daily/weekly (runstats)
    Scegliere il comportamento (optimizer)
    Se il piano attuale non è il migliore (analyzer)
    Attuare il piano (executor)
    Ottimizzazione basatasulcostodella query
    Runstats-optimize-execute -> alta granularità
    Adattività settimanale!
    Goal: adattare per tupla
    Unire le 4 funzioni
    Measure
    Actuate
    Analyze
    Plan
    Taken from: Avnur, Hellerstein
    24
  • TelegraphCQ Executor:Eddy
    Concetto preso dalla dinamica dei fluidi
    continuously adaptive query processing mechanism
    Eddy è un routing operator
    Determina quali moduli devono essere visitati prima
    Dopo che una tupla visita tutti i moduli va in output
    Vede le tuple prima e dopo ogni operatore
    25
    Measure
    Eddy
    Analyze
    Actuate
    Plan
    Taken from: Amol Deshpande, Vijayshankar Raman
  • Eddies:Correttezza
    Ogni tupla ha due BitVector
    Ogni posizione corrisponde ad un operatore
    Ready: identifica se la tupla è pronta per un operatore
    Eddy può decidere quali tuple mandare ad un operatore
    Done: identifica se una tupla ha subito un operatore
    Eddy evita di inviare due volte ad un operatore
    Quando tutti i bit di Done sono attivi -> output
    Tuple joined hanno Ready e Done in bitwise-OR
    SempliciselectionhannoReady=complement(Done)
    26
  • Eddies:Simple Selection Routing
    27
    S
    SELECT *FROM SWHERE S.a > 10 AND S.b < 15
    AND S.c = 15
    σa
    σb
    S.b < 15
    S.a > 10
    Eddy
    σc
    S.c = 15
    σaσbσc
    σaσbσc
    15 ; 0 ; 15
    S1
    0 0 0
    1 1 1
    1 0 0
    01 1
    1 1 0
    0 0 1
    1 1 1
    0 0 0
    a
    15
    b
    0
    Ready
    Done
    c
    15
    Adapted from Manuel Hertlein
  • S >< T
    Relation Binary Join:R >< S >< T
    Ordine di join
    (R >< S) >< T
    Va bene se si ha accesso diretto ai dati (indici o seq.)
    28
    R >< S
    T
    R
    S
    Taken from Jarle Søberg
  • Stream Binary JoinR >< S >< T
    29
    Ordine di join
    (R >< S) >< T
    Ma se i dati sono inviati direttamente dalla sorgente...
    S >< T
    R >< S
    Bloccare o gettare via delle tuple è inevitabile!
    Taken from Jarle Søberg
  • Necessaria una riottimizzazione al volo…
    S >< T
    30
    Stream Binary JoinR >< S >< T
    Possono esserci molti cambiamenti in uno stream
    Riottimizzare può richiedere molto tempo
    Non abbastanza dinamica!
    R >< S
    Taken from Jarle Søberg
  • Stream Binary Join:Eddies
    Usando un Eddy
    Modello iniziale di Telegraph
    31
    S >< T
    eddy
    R >< S
    Adattività tuple-based
    Considera cambiamenti dinamici nello stream
    Taken from Jarle Søberg
  • Eddies:Sheduling Join problem
    Sheduling sulla selettività dei join non funziona
    Esempio
    32
    |S E|
    |EC|
    >>
    E and Carrive early; Sis delayed
    S
    E
    C
    time
    Taken from Amol Deshpande
  • 33
    |S E|
    |E C|
    SE
    HashTable
    E.Name
    HashTable
    S.Name
    Eddy
    S
    E
    Output
    C
    HashTable
    C.Course
    HashTable
    E.Course
    Eddy decides to route E to EC
    EC
    >>
    E and Carrive early; Sis delayed
    S0
    sent and received suggest
    S Join E is better option
    S
    S
    E
    S0
    S –S0
    E
    C
    time
    C
    SE
    S0E
    (S –S0)E
    Eddy learns the correct sizes
    Too Late !!
    Taken from Amol Deshpande
  • 34
    State got embedded as a
    result of earlier routing
    decisions
    |S E|
    |EC|
    SE
    HashTable
    E.Name
    HashTable
    S.Name
    EC
    Eddy
    S
    E
    Output
    C
    HashTable
    C.Course
    HashTable
    E.Course
    SE
    EC
    >>
    E and Carrive early; Sis delayed
    S
    E
    C
    C
    SE
    S
    E
    Execution Plan Used
    Query is executed using the worse plan!
    Too Late !!
    Taken from Amol Deshpande
  • STAIRStorage, Transformation and Access for Intermediate Results
    35
    S.Name STAIR
    Build into
    S.Name STAIR
    HashTable
    E.Name STAIR
    HashTable
    Eddy
    S
    Output
    E
    C
    HashTable
    HashTable
    E.Course STAIR
    C.Course STAIR
    Probe into
    E.Name STAIR
    Mostra lo stato interno del join all’eddy
    Fornisce primitive di management dello stato
    Demotion
    Promotion
    Operazioni per
    Inserimento (build)
    Lookup (probe)
    s1
    s1
    s1
    s1
    Taken from Amol Deshpande
  • STAIR: Demotion
    36
    e1
    e1
    e2c1
    e2
    s1e1
    e2c1
    e2
    s1e1
    S.Name STAIR
    HashTable
    E.Name STAIR
    s1
    Demoting di e2c1ae2:
    Semplice proiezione
    HashTable
    e1
    e2c1
    e2
    Eddy
    S
    s1e1
    E
    Output
    C
    HashTable
    e2
    s1e1
    e2c1
    HashTable
    c1
    Può essere pensato come un lavoro disfatto
    E.Course STAIR
    C.Course STAIR
    Adapted from Amol Deshpande
  • STAIR: Promotion
    37
    Promotinge1 using EC
    e1
    e1
    e1c1
    e1
    e1c1
    S.Name STAIR
    HashTable
    E.Name STAIR
    s1
    Due argomenti:
    • Una tupla
    • Un join
    HashTable
    e1
    e1c1
    e2c1
    Eddy
    S
    E
    Output
    C
    HashTable
    e2
    s1e1
    HashTable
    c1
    e1
    Può essere pensato come una precomputazione di lavoro
    E.Course STAIR
    C.Course STAIR
    Adapted from Amol Deshpande
  • Demotion OR Promotion
    38
    Taken from Lifting the Burden of History from Adaptive Query Processing
    Amol Deshpande and Joseph M. Hellerstein
  • Demotion AND Promotion
    Taken from Lifting the Burden of History from Adaptive Query Processing
    Amol Deshpande and Joseph M. Hellerstein
    39
  • 40
    S.Name STAIR
    HashTable
    |S E|
    |EC|
    S0
    E
    E
    E
    HashTable
    E
    E
    E
    C
    C
    C
    S0E
    Eddy decides to route E to EC
    E.Course STAIR
    >>
    E and Carrive early; Sis delayed
    S0
    E.Name STAIR
    HashTable
    S
    E
    E
    Eddy
    S
    C
    E
    Output
    C
    time
    E
    HashTable
    C
    Eddy decides to migrateE
    Eddy learns the correct selectivities
    By promoting E using EC
    C.Course STAIR
    Adapted from Amol Deshpande
  • 41
    |S E|
    |EC|
    HashTable
    E
    C
    S0E
    E.Course STAIR
    >>
    E and Carrive early; Sis delayed
    S.Name STAIR
    HashTable
    S
    S0
    E.Name STAIR
    HashTable
    S
    S –S0
    S –S0
    E
    Eddy
    S
    C
    (S –S0) EC
    E
    Output
    C
    time
    E
    HashTable
    C
    C.Course STAIR
    Adapted from Amol Deshpande
  • 42
    EC
    SE
    C
    S – S0
    SE
    EC
    S0
    E
    E
    C
    HashTable
    E
    C
    SE
    E.Course STAIR
    S.Name STAIR
    HashTable
    S
    E.Name STAIR
    HashTable
    UNION
    Eddy
    S
    E
    Output
    C
    E
    HashTable
    C
    Most of the data is
    processed using the
    correct plan
    C.Course STAIR
    Adapted from AmolDeshpande
  • STAIR:Correttezza
    Theorem [3.1]: An eddy with STAIRs always produces the correct query result in spite of arbitrary applications of the promotion and demotion operations.
    STAIRs producono tutte le tuple
    Non ci sono duplicati aggiunti
    43
    Taken from Lifting the Burden of History from Adaptive Query Processing
    Amol Deshpande and Joseph M. Hellerstein
  • State Module
    Una sorta di repository temporaneo di dati
    Operatore di Half-Join che memorizza tuple omogenee
    Decisioni independenti
    Supporta le operazioni
    Inserimento (build)
    Ricerca (probe)
    Cancellazione (eviction) utili per le window
    Simili a Mjoin ma più adattivi
    Sharing dello stato tra altre query continue
    Non memorizza i risultati intermedi
    Aumento del costo di computazione
    44
  • Eddies Join with SteMs
    45
    T
    R
    S
    eddy
    R
    T
    S
    Maggiore adattività
    Eddy vede half-join
    Diversi access method
    Index access
    Scan access
    Simulano diversi join
    In caso di sovraccarico?
    Hash join (veloce)
    Index join (mem limit)
    Tipologie di Join?
    Hash join (equi-join)
    B-tree join (<, <=, >)
    Query parametrica può essere vista come un join
    Adapted from Jarle Søberg
  • SteMs:Correttezza
    46
    R
    S
    Problema di correttezza
    Possibili duplicati!!
    Sequence number globale unico
    Solo le più giovani possono fare il match
    Taken from Jarle Søberg
  • SteMs sliding Window
    47
    SELECT *
    FROM Str [RANGE BY 5 Second
    SLIDE BY 2 Second],
    Relation,
    WHERE Relation.a = Str.a
    A|…….|18:49:36
    R
    B|…….|18:49:36
    C|…….|18:49:37
    A|…….|18:49:38
    Mantenere lo stato per le sliding window (eviction)
    Siamo al tempo 40, cosa succede al tempo 42?
    Invece che ricreare tutta l’hash table vengono rimosse solo tuple vecchie e aggiunte le nuove
    B|…….|18:49:39
    C|…….|18:49:39
    A|…….|18:49:40
    B|…….|18:49:40
    C|…….|18:49:40
    Eviction!18:49:37
    A|…….|18:49:41
    B|…….|18:49:41
  • Binary Join, STAIR, SteMconfronti
    48
    select *
    from customer c, orders o, lineitem l
    where c.custkey = o.custkey and
    o.orderkey = l.orderkey and
    c.nationkey = 1 and
    c.acctbal > 9000 and
    l.shipdate > date ’1996-01-01’
    Recomputation necessaria
    Non si adatta
    lineitemarriva con shipdate crescente
    Routing iniziale (O >< L) >< C
    Taken from Lifting the Burden of History from Adaptive Query Processing
    Amol Deshpande and Joseph M. Hellerstein
  • Eddies:Routing Policy
    Come scegliere il piano? Usando il Routing
    Ogni tupla è instradata individualmente
    Routing policy determina l’efficienza del sistema
    Eddy ha un buffer di tuple con priorità
    Inizialmente hanno bassa priorità
    Quando escono da un operatore hanno alta priorità
    Una tupla va in output il più presto possibile
    Evita di congestionare il sistema
    Permette un basso consumo di memoria
    49
  • Eddies’ Routing Policy:(old) Back-Pressure
    Approccio Naive:
    operatore più veloce prima
    50
    sel(s1) = sel(s2)
    cost(s2) = 5
    cost(s1) varia
    cost(s1) = cost(s2)
    sel(s2) = 50%
    sel(s1) varia
    Taken from: Avnur, Hellerstein
  • Eddies’ Routing Policy:Lottery Scheduling
    Waldspurger& Weihl nel 1994
    Algoritmo per schedulare risorse condivise
    « rapidlyfocus availableresources»
    Ogni operatore inizia con un numero di ticket fissato
    Operatore riceve un ticket quando prende una tupla
    Favorisce gli operatori che consumano tuple velocemente
    Operatore perde un ticket quando ritorna una tupla
    Favorisce gli operatori con bassa selettività
    Cioè quelli che ritornano poche tuple e ne processano tante
    Quando due operatori concorrono per una tupla
    La tupla viene assegnata all’operatore che vince la lotteria
    Mai lasciare op senza ticket + randomexploration
    51
  • Eddies’ Routing Policy:Lottery Scheduling
    Lottery Scheduling è meglio del Back-Pressure
    52
    cost(s1) = cost(s2)
    sel(s2) = 50%
    sel(s1) varia
    Taken from: Avnur, Hellerstein
  • Experiment
    53
    Stream: x con media 40 e deviazione standard 10
  • 54
    Experiment: variazione Stream
    Stream: x con media 10 e deviazione standard 0
  • 55
    Experiment: variazione Stream (2)
    Stream: x con media 10 e deviazione standard 0
  • Other Works
    Distribuited Eddies
    Freddies: DHT-Based Adaptive Query Processing via Federated Eddies
    Content-based Routing
    Partial Results for Online Query Processing
    Flux: An Adaptive Partitioning Operator for Continuous Query Systems
    Java Support for Data-Intensive Systems: Experiences Building the Telegraph Dataflow System
    Ripple Join for Online Aggregation
    Highly Available, Fault-Tolerant, Parallel Dataflows
    56
  • Bibliografia
    TelegraphCQ: An Architectural Status Report
    Continuous Dataflow Processing for an Uncertain World
    Enabling Real-Time Querying of Live and Historical Stream Data
    Declarative Network Monitoring with an Underprovisioned Query Processor
    Lifting the Burden of History from Adaptive Query Processing [STAIRs]
    Eddies: Continuously Adaptive Query Processing
    Using State Modules for Adaptive Query Processing
    E altri… http://telegraph.cs.berkeley.edu/papers.html
    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
    Lottery Scheduling: Flexible Proportional-Share Resource Management
    Carl A. Waldspurger & William E. Weihl @ MIT
    57