State-Slice: New Paradigm of Multi-query Optimization of Window-based Stream Queries
Embed Size (px)
Transcript of State-Slice: New Paradigm of Multi-query Optimization of Window-based Stream Queries
State-Slice: New Paradigm of Multi-query Optimization ofWindow-based Stream QueriesSong WangElke Rundensteiner
Database Systems Research GroupWorcester Polytechnic InstituteWorcester, MA, USA.Samrat GangulySudeept Bhatnagar
NEC Laboratories America Inc.Princeton, NJ, USA.
Computation Sharing for Stream ProcessingRegisterContinuous QueriesStreaming DataStreaming ResultNew Challenges: In-memory processing of stateful operators Stateful operators with various window constraintsAggSPJA Query Networkw1w2w3Agg
Window Constraints for Stateful OperatorsTime-based sliding window constraintsEach tuple has a timestampOnly tuples within W timeframe can form an outputObservations: States in the operator dominate memory usage State size is proportional to the input rate and window length Join CPU cost is proportional to the state size
- A Motivation ExampleQ1:SELECT A.*FROM Temperature A, Humidity BWHERE A.LocationId= B.LocationIdWINDOW w1 min Q2:SELECT A.*FROM Temperature A, Humidity BWHERE A.LocationId= B.LocationId AND A.Value>ThresholdWINDOW w2 min Observations: State A[W1] overlaps with state A[W2] State B[W1] overlaps with state B[W2] Joined results of Q1 and Q2 overlapLet: w1
- Sharing with Selection Pull-up [CDF02, HFA+03]Selection pull upUsing larger window (w2)+allQ2 Q1|Ta-Tb |
Sharing with Selection Pull-up [CDF02, HFA+03]ProsSingle Join OperatorConsWasted Computation without Early FilteringWasted State Memory without Early FilteringPer Output-Tuple Routing Cost
- Split stream A by A.ValueRoute shared join resultsStream Partition with Selection Pushdown [KFH04]+A1Router>allBAThreshold
ProsSelection pushdown: no wasted Join ComputationConsMultiple Join OperatorsDuplicated State Memory in Multiple Join OperatorsPer Output-Tuple Routing Cost
Stream Partition with Selection Pushdown [KFH04]
State-Slice: New Sharing Paradigm
Key Ideas:State-Slice Concept for Sliding Window JoinPipelined Chain of Join SlicesProspective Benefit:Fine-grained Selection Push-downPipelined Join OperatorsAvoiding Per-tuple Routing Cost
One-way State Sliced Window JoinIower bound of sliding window: [w1,w2]B tuple only probes A tuples that are older at least W1, but at most W2, than itself
The Chain of One-way State-Sliced JoinsSplit state memory into chain of joinsNo overlap of state memory in chain of joinsJoined-Result =
femalefemaleFrom One-way to Two-way Binary Join
Intuitively a combination of two one-way joinTwo references for each A or B tuplesMale tuples are used to probe statesFemale tuples are inserted and cross-purged to respective statesState of Stream A: [0, w1]State of Stream B: [0, w1]Queue(s)A TupleB TupleJ1J2UUnionJoined-Result State of Stream B: [w1, w2]State of Stream A: [w1, w2]malemale
State-Sliced Join Chain: The ExampleStates of sliced joins in a chain are disjoint with each other Minimize State Memory Usage Selection can be pushed down into middle of join chain Avoid Unnecessary Resource Waste No routing step is needed Avoid Per Output-Tuple Routing Cost CompletelyA1+
Summary: State-Sliced Join ChainPros:Minimized Memory UsageReduced Routing CostNo Need of Operator Synchronization in the ChainCons:Stream traffic between pipelined joinsPurge cost
Sharing via Chains: Memory-Optimal ChainNo Selection:With Selection:
Mem-Optimal Chain CPU-Optimal Chain?Overheads:Too many operators may increase system context switch costToo many sliced states increase purging cost
Merging Sliced JoinsTradeoff:Gain from MergingReduce number of Join operatorsReduce extra purging costLoss from MergingIntroduce routing costIncrease memory usage due to selection pullupCost Model for CPU Usage
CPU-Opt. Chain: Search Space & Solutionv0v1v2v5v3w0w1w2w3w5v4w4Legend:Vi: window start/end timeVi toVj : one slice windowShortest path problem
Summary: Mem-Opt. vs. CPU-Opt. Join ChainMem-Optimal:Minimized Memory UsageHigher System Overhead Higher Purging CostCPU-Optimal:Minimized CPU UsageMore Memory Usage if Selection is Pulled Up to Merge Slices.
Experimental WPI Stream Engine: CAPE
CAPE Query Engine
Stream / QueryRegistrationGUI
Query 2 . .
Experiment Study 1: Memory Consumption
Experiment Study 2: Total Service Rate
Experiment Study 3: Mem-Opt. vs. CPU-Opt.Window Distributions Used for 12 Queries.
Small-Large: 12 QueriesSmall-Large: 24 Queries
ConclusionPipelined state sliced join chainMem-Optimal chain constructionCPU-Optimal chain constructionImplemented in CAPEPerformance evaluation
Thank You!Visit CAPE Homepage
CRI grant CNS 05-51584
The title of this work is:The authors are from wpi and from NECThis work is presented by
Computation sharing is a well known technique for scalable multiple query optimization.In a DSMS, multiple continuous queries may share the input streams and query result.click
computation sharing brings a lot of challenges for the query processing:Memory must be considered, since sharing the in-memory processed stateful operators may need large amount of memory.The stateful operators, eg. joins, may have various window constraints.Our proposed approach aims to tackle such computing sharing problem in streaming multiple query optimization. This is a typical stateful operator: sliding window join.ClickWe have following important observations:1 memory usage is dominated by the states in the operator 2 state size is ... (same in the stuff)3 same....
Lets see an example first.Q1 and Q2 on the left hand side join the same streams. There are two differences between them. The first one is that they have different window constraint, for Q1, the window constraint is W1 and for Q2 it is W2. The second difference is Q2 has a predicate on stream A. (TWO DIFFERENCES)On the right hand side is the query plan of Q1 and Q2 respectively.ClickWe can see that, 12So, by this example we observe that, sharing of the state buffer and the join results is possible. There are a lot of solutions for tackling the computation sharing problem. Let's review some of the state-of-the-art sharing paradigm first.The approach on this slide is called selection pullup. After pulling up the selections in Q2, the Q1 and Q2 can be shared.clickclick (two clicks here!)And the maximum window size of Q1 and Q2 is picked.clickA router is added. The router dispatches result tuples according to the timestamp differenced, Ta-TbClickAlso, the selection is applied at last on Q2.Click
(totally five clicks) let's look at the advantage and disadvantage of the selection pull-up approach
The good side is a single join operatorHowever,without the early filtering the predicates, it waste the computation and state memory, and it brings the cost of output tuple routing (the above sentence shows the 1 2 and 3)Another approach to share the computation between Q1 and Q2 is partitioning the input streams and push the selections down.clickAs the figure on the right hand side, the stream A is partitioned by the threshold and feed to the two join operators.clickThe shared joined result need to be routed to corresponding queries and unioned together.clickThe stream partition and selection push down have following propertiesThe pros are:The cons are:123
Now we proposed a new paradigm for computation sharing.The key ideas are:12We expect that:123We will show the details in the next couple of slides.We first using the one-way join to show the state slice concept.For a state sliced join operator, the window constraint has two parameters: start window (eg. w1) and end window (eg. w2).The state-sliced window is different with other sliding window join as it introduces the lower bound of the window constraint. That is, the state of this join operator will only hold A tuples that are older at least W1, but at most W2, than the probing B tuple.Adding the lower bound of the window does not need extra timestamp checking. This is true since all the state-sliced joins will be used in a chain.The end window of the previous join is exactly equal to the start window of the next join.Each B tuple will first purge, probe the A tuples in the window [0, w1], then purge, probe the A tuples in the window [w1, w2].The correctness of using this chain of state-sliced joins is proved in the papert.This figure shows the binary state-sliced window join.We need two references for each input tuple.One is called male tuple.Male tuples are used to purge and probe the statesThe other is called female tuple, which is used to insert and stay in the join state.
Back to the example queries: Q1 and Q2. Using the state-slice concept, the shared query plan is shown on the right hand side.Two state-sliced joins are used and the selection is pushed between them.We can see that:1 2 3The state-sliced join chain has following properties.The benefit is:1 2 3The cost is:1 2For a centralized system, the doubled traffic may not be a problem, since the tuple access is all in-memory. However, if the chain is distributed to multiple machines, the traffic is a tradeoff to be considered.Give a set of queries, Q1 to QN, this slide shows how to construct a sharing chain by slicing the states as