the raindrop engine: continuous query processing at wpi · the raindrop engine: continuous query...

The Raindrop Engine: Continuous Query Processing at WPI

Elke A. RundensteinerDatabase Systems Research Lab, WPI

2003

This talk is based on joint work with students at DSRG lab.

Invited Talk at Database Seminar Series @ Univ. of Waterloo, Canada.

2

Monitoring Applications

Monitor troop movements during combat and warn when soldiers veer off courseSend alert when patient’s vital signs begin to deteriorate Monitor incoming news feeds to see stories on “Iraq”Scour network traffic logs looking for intruders (this is our focus in Raindrop)

3

Properties of Monitoring Applications

Queries and monitors run continuously, possibly unendingApplications have varying service preferences:

Patient monitoring only wants freshest data Remote sensors have limited memory News service wishes maximal throughputTaking 60 seconds to process vital signs and sound an alert may be too long

4

Properties of Streaming Data

Possibly never ending stream of dataUnpredictable arrival patterns:

Network congestionWeather (for external sensors)Sensor moves out of range

5

DBMS Approach to Continuous Queries

Insert each new tuple into the database, encode queries as triggers [MWA03]Problems:

High overhead with inserts [CCC02]Triggers do not scale well [CCC02]Uses static optimization and execution strategies that cannot adapt to unpredictable streamsSystem is less utilized if data streams arrive slowlyNo means to input application service requirements

6

Hence, New Class of Query Systems

CQ Systems emerged recently (Aurora, Stream, NiagaraCQ, Telegraph, et al.)Generally work as follows:

System subscribes to some streams End users issued continuous queries against streamsSystem processes queries continuouslySystem returns the results to the user as a stream

All CQ systems use adaptive techniques to cope with unpredictability of streams and environment

7

Overview of Adaptive Techniques in CQ Systems

Improve ill-performing query plansReorganize query plans on the fly by using using synchronization packets to tell operators to finish up their current work.

Tukwila [IFF99][UF98]

Maximize throughput to clientsSchedule streams with the highest rate[UF01]

Keep Join and system running at full capacity at all times

Break Join into 3 stages and make use of memory and disk storage

XJoin [UF00]

Keep system constantly busy, improve throughput

Dynamically route tuples among JoinsEddies [AH00](Telegraph)

Efficiently share computation between multiple queries, highly scalable system, maximize output rate

Generate near-optimal query plans for multiple queries

NiagaraCQ[CDT00]

Maintain high quality of serviceLoad shedding, batch tuple processing to reduce context switching

Aurora[CCC02]

Adaptive scheduling algorithm (Chain) [BBM03], Load shedding

Technique(s)

Minimize memory requirements during periods of bursty arrival

STREAM[MWA03]

GoalResearch Work

8

The WPI Stream Project: Raindrop

CAPE Runtime Engine

Runtime Engine

OperatorConfigurator

QoS Inspector

OperatorScheduler

PlanMigrator

ExecutionEngineStorage

Manager StreamReceiver

StreamProvider

DistributionManager

Query PlanGenerator

Stream / QueryRegistration

GUI

QueriesResults

9

Raindrop Project GoalOur goal is to bring adaptability into all components of the system;Without reniging on the requested accuracy of answer;While optimizing for a given set of quality of service requirements.

Quality of service requirements are multi-faceted, such as memory usage, timeliness, output rate, etc., and can even be modified at run-time.

Plus, we support self-inspection of components tp observe the effect of their actions on environment, and respond appropriately.

10

Adaption in All Components

Scalable Query Operators (Punctuations)Cooperative Plan OptimizationAdaptive Operator SchedulingOn-line Query Plan MigrationDistributed Plan Execution

11

Adaption in All Components Scalable Query Operators (Punctuations)

Adapt and select among tasks such as memory purging, stream reading, memory-to-disk shuffling, punctuation propagation, etc.

Cooperative Plan OptimizationOperators request and selectively provide punctuations (meta-knowledge) to improve their performance

Adaptive Operator SchedulingSelector scores alternate scheduling algorithm based on their effect on QoS requirements, and selects candidate.

On-line Query Plan MigrationOn-line plan restructuring and then online migration to the new plan even for stateful operators.

Distributed Plan Execution Adaptively distribute computations across multiple machines to optimize QoS requirements without information loss

12

Topics Studied in Raindrop Project

PLUS, Bring XML into Stream Engine (!?)Scalable Query Operators (Punctuations)Cooperative Plan OptimizationAdaptive Operator SchedulingOn-line Query Plan MigrationDistributed Plan Execution

13

Raindrop

Let’s now focus on putting XML into Raindrop, as each of the other topics is a separate story to be told at another time.

PART II: XQueries on XML Streams(Automaton Meets Algebra)

Based on CIKM’03 and ER’03Joint work with Hong Su and Jinhui Jian

15

What’s Special for XML Stream Processing?<Biditems>

<book year=“2001">

<title>Dream Catcher</title>

<author><last>King</last><first>S.</first></author>

<publisher>Bt Bound </publisher>

<price> 30 </initial>

</book>

…

<biditems> <book> <title> Dream Catcher </title> …

Token-by-Token access manner

timeline

Pattern retrieval + Filtering + RestructuringFOR $b in stream(biditems.xml) //bookLET $p := $b/price

$t := $b/titleWHERE $p < 20Return <Inexpensive> $t </Inexpensive>

Token: not a direct counterpart of a tuple

30Bt BoundS.KingDream2001

pricepublisherfirstlasttitleyear

Pattern Retrieval on Token Streams

16

Two Computation Paradigms

Automata-based [yfilter02, xscan01, xsm02, xsq03, xpush03…]

Algebraic [niagara00, …]

This Raindrop framework intends to integrate both paradigms into one

17

Automata-Based Paradigm

Auxiliary structures for:

1. Buffering data

2. Filtering

3. Restructuring

…

FOR $b in stream(biditems.xml) //bookLET $p := $b/price


book*

2

4title

price

3

//book/title

1//book //book/price

18

Algebraic ComputationFOR $b in stream(biditems.xml) //bookLET $p := $b/price


Navigate $b, /price->$p

Navigate $b, /title-> $t

Tagger

Select $p < 30

Logic Plan

Navigate //$b, /title->$t

Rewrite by “pushing down selection”

Navigate $b,/price->$p

Select $p < 30

Tagger

Rewritten Logic Plan

book book book

publisher

Text

authortitle price

Text Text

Navigate-Index $b, /price -> $p

Select $p < 30

Tagger

Navigate-Scan $b, /title -> $t

Physical Plan

Choose low-level implementation alternatives

firstlast

Text Text

<book> …</book>

<title>…</title>

<book>…</book>

$b $t

…

Navigate$b, /title -> $t

$b

…

19

Observations

Support multiple descriptive levels (declarative->procedural)

Present all details on same low level

Well studied as query process paradigm

Little studied as query processing paradigm

Good for filtering and restructuringNeed patches for filtering and restructuring

Does not support token inputsGood for pattern retrieval on tokens

Algebra ParadigmAutomata Paradigm

Either paradigm has deficiencies

Both paradigms complement each other

20

How to Integrate Two Paradigms

21

How to Integrate Two Models?

Design choicesExtend algebraic paradigm to support automata?Extend automata paradigm to support algebra?Come up with completely new paradigm?

Extend algebraic paradigm to support automata Practical

Reuse & extend existing algebraic query processing engines

Natural Present details of automata computation at low level Present semantics of automata computation (target patterns) at high level

22

Raindrop: Four-Level Framework

SemanticsSemantics--focused Planfocused PlanHigh (Declarative)

Stream Logic PlanStream Logic Plan

Stream Physical PlanStream Physical Plan

Stream Execution PlanStream Execution PlanLow (Procedural)

Abstraction Level

23

Level I: Semantics-focused Plan [Rainbow-ZPR02]

Express query semantics regardless of stored or stream input sources Reuse existing techniques for stored XML processing

Query parserInitial plan constructorRewriting optimization

DecorrelationSelection push down…

24

Example Semantics-focused PlanFOR $b in stream(biditems.xml) //bookLET $p := $b/price


<Biditems>

<book year=“2001">

<title>Dream Catcher</title>

<author><last>King</last><first>S.</first></author>

<publisher>Bt Bound </publisher>

<price> 30 </initial>

</book>

…

$S1<Biditems> …</Biditems>

$S1<Biditems>…</Biditems>

$b<book> …</book>

<Biditems> …</Biditems>

<book> …</book>

$S1<Biditems>…</Biditems>

$b<book>…</book>

$p

30<Biditems> …</Biditems>

<book>…</book> …

$S1<Biditems>…

</Biditems>

$b<book>…</book>

$p30

$tDream Catcher

<Biditems>…</Biditems>

<book>. .. </book>

… …

NavUnnest$S1, //book ->$b

NavNest$b, /price/text() ->$p

NavNest$b, /title ->$t

Select$p<30

Tagger“Inexpensive”, $t->$r

25

Level II: Stream Logical Plan

Extend semantics-focused plan to accommodate tokenized stream inputs

New input data format: contextualized tokens

New operators:StreamSource, Nav, ExtractUnnest, ExtractNest, StructuralJoin

New rewrite rules:Push-into-Automata

26

One Uniform Algebraic ViewAlgebraic Stream Logical Plan

Token-based plan (automata plan)

Tuple-based plan

Tuple stream

Query answer

XML data stream

27

Modeling the Automata in Algebraic Plan:Black Box[XScan01] vs. White Box



$b := //book$p := $b/price$t := $b/title

XScan

StructuralJoin$b

ExtractNest$b, $p

ExtractNest$b, $t

White Box

Navigate$b, /price->$p

Navigate$b, /title->$t

Navigate$S1, //book ->$b

Black Box

28

Example Uniform Algebraic Plan



Tuple-based plan


29




Tuple-based plan

StructuralJoin$b

ExtractNest$b, $p

ExtractNest$b, $t




30




Select$p<30


StructuralJoin$b

ExtractNest$b, $p

ExtractNest$b, $t




31

From Semantics-focused Plan to Stream Logical Plan

StructuralJoin$b

ExtractNest$b, $p

ExtractNest$b, $t

Nav$b, /price/text()->$p

Nav$b, /title->$t

Nav$S1, //book ->$b

Select$p<30



NavNest$b, /price/text() ->$p


Select$p<30


Apply “push into automata”


32

Level III: Stream Physical Plan

For each stream logical operator, define how to generate outputs when given some inputs

Multiple physical implementations may be provided for a single logical operatorAutomata details of some physical implementation are exposed at this level

Nav, ExtractNest, ExtractUnnest, Structural Join

33

One Implementation of Extract/Structural Join

1book

title*

4price

3

2

ExtractNest$b, $t

ExtractNest/$b, $p

SJoin//book

<price>…</price><title>…</title>

<price>…</price><title>…</title>

Nav$b, /price->$p

Nav$b, /title->$t

Nav., //book ->$b

<biditems> <book> <title> Dream Catcher </title> … </book>…

34

Level IV: Stream Execution Plan

Describe coordination between operators regarding when to fetch the inputs

When input operator generates one output tupleWhen input operator generates a batchWhen a time period has elapsed…

Potentially unstable data arrival rate in stream makes fixed scheduling strategy unsuitable

Delayed data under scheduling may stall engineBursty data not under scheduling may cause overflow

35

Raindrop: Four-Level Framework (Recap)

SemanticsSemantics--focused Planfocused Plan

Express the semantics of query regardless of

input sources

Accommodatetokenized

input streamsStream Logic PlanStream Logic Plan


Describe how operators manipulate

given data

Stream Execution PlanStream Execution PlanDecides the Coordination

among operators

36

Optimization Opportunities

37

Optimization Opportunities

SemanticsSemantics--focused Planfocused Plan

General rewriting (e.g., selection push down)

Stream Logic PlanStream Logic Plan


Stream Execution PlanStream Execution Plan

Break-linear-navigation rewriting

Physical implementations choosing

Execution strategy choosing

38

From Semantics-focused to Stream Logical Plan: In or Out?

Tuple stream


Query answer Tuple-based Plan

Pattern retrieval in Semantics-focused plan


XML data stream

39

Plan Alternatives

Nav $b, /price->$p

ExtractNest $b, $p

ExtractNest $b, $t

SJoin //book

Select price < 30

Tagger

Nav $b, /title->$t

Nav $S1, //book->$b

In


NavNest$b, /price ->$p


Select$p<30


ExtractNest$S1, $b

Navigate /price

Select price<30

Navigate book/title

Tagger

Nav $S1, //book->$b

Out

40

Experimentation Results

Execution Time on 85M XML Stream Under Various Selectivity

250003000035000400004500050000

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Selectivity of Selection

Exe

cutio

n Ti

me

(ms)

1 Nav2 Navs3 Navs4 Navs5 Navs

41

Contributions Thus Far

Combined automata and algebra based paradigms into one uniform algebraic paradigmProvided four layers in algebraic paradigm

Query semantics expressed at high layerAutomata computation on streams hidden at low layer

Supported optimization at an iterative manner (from high abstraction level to low abstraction level) Illustrated enriched optimization opportunities by experiments

42

Automaton Meets Algebra: On-Going Issues To be Tackled

Exploit XML schema constraints for query optimizationCosting/query optimization of plansOn-the-fly migration into/out of automatonPhysical implementation strategies of operatorsLoad-shedding from an automaton

43

Plus, Other Topics in Raindrop

Bring XML into Stream EngineScalable Query Operators (Punctuations)Cooperative Plan OptimizationAdaptive Operator SchedulingOn-line Query Plan MigrationDistributed Plan Execution

To be told on another day …

44

Overall Blizz . . .

Many interesting problems arise in this new stream contextThere is room for lot’s of fun research

45

Email: [email protected]

the raindrop engine: continuous query processing at wpi · the raindrop engine: continuous query...

Documents