Cost-Based Optimization of Integration Flows - Datenbanken ...

3 Fundamentals of Optimizing Integration Flows
cost-based optimization techniques (Plan → Execute; Section 3.4). Fourth, selected experimental
evaluation results are presented in order to illustrate the achieved execution
time improvement as well as the required optimization overhead (Execute → Monitor;
Section 3.5). Finally, we summarize the results of this chapter and discuss advantages and
disadvantages of this approach in Section 3.6.
3.2 Prerequisites for Cost-Based Optimization
Based on the problem of imperative integration flows, the prerequisites of cost-based optimization
are two-fold. On the one side, the operator dependency analysis is required in
order to ensure correctness of plan rewriting. On the other side, an accurate cost model
is required in order to allow for precise cost estimation when comparing alternative plans
of an integration flow. In this section, we address both fundamental requirements.
3.2.1 Dependency Analysis
When rewriting plans, we have to preserve semantic correctness. Here, semantic correctness
is used in the sense of preventing the external behavior from being changed.
This is comparable to snapshot isolation in DBMS [CRF08] or in replication scenarios
[DS06, LKPMJP05]. We introduce the dependency analysis for integration flows that resembles
similar dependency models from areas like compiler construction for programming
languages [Muc97] and computational engineering.
The dependency analysis (based on the analysis of control-flow and data-flow) is executed
once during the initial deployment of a plan in order to generate the so-called
dependency graph DG(P ) of a plan P . All of our optimization techniques use these operator
dependencies in order to determine whether or not rewriting is possible. In detail,
we distinguish three dependency types:
δm D
• Data Dependency o
1
j −→ oi : Operator o j depends on (reads as input) the message
m 1 that has been modified or created by operator o i (read after write).
δm O
• Output dependency o
1
j −→ oi : Both, operator o j and operator o i , write their results
to message m 1 , where operator o j is a temporal successor of o i (m 1 is overwritten
multiple times, write after write). However, the variable might be read in between.
δm −1
• Anti-dependency o
1
j −→ oi : Operator o j modifies the message m 1 , while operator
o i —as a predecessor of o j —depends on this message (before m 1 is written, it is
referenced, write after read).
Based on this distinction of dependency types, the dependency graph DG(P ) is constructed
using three basic rules. First, a data dependency is created if the output variable
of an operator is one of the input variables of a following operator. Second, if two operators
have the same output variable and if this variable is not written in between, an
output dependency is created between the two operators. Third, an anti-dependency is
created if the output variable of an operator is the input variable of a previous operator
and if this variable is not written in between. Hence, an anti-dependency can only occur
if an output dependency exist. It follows that, for example, output dependencies are subsumed
by other output dependencies, i.e., one operator is involved at most in one output
dependency per data object.
36