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

4 Vectorizing Integration Flows
execution, where each incoming message initiates a new plan instance. All operators of
one instance are executed before the next instance is started.
plan instance pid=3
plan instance pid=2
plan instance pid=1
Receive (o1)
[service: s5, out: msg1]
Assign (o2)
[in: msg1, out: msg2]
Invoke (o3)
[service: s4, in: msg2, out: msg3]
Join (o4)
[in: msg1,msg3, out: msg4]
Assign (o5)
[in: msg4, out: msg5]
Invoke (o6)
[service s3, in: msg5]
msg1
msg2
msg3
msg4
msg5
Message
Queue
Receive (o1)
[service: s5, out: msg1]
Assign (o2)
[in: msg1, out: msg2]
Invoke (o3)
[service: s4, in: msg2, out: msg3]
Join (o4)
[in: msg1,msg3, out: msg4]
Assign (o5)
[in: msg4, out: msg5]
Invoke (o6)
[service s3, in: msg5]
msg1
msg2
msg3
msg4
msg5
time t
(a) Example Plan P 2
(b) Instance-Based Plan Execution of P 2
Figure 4.1: Example Instance-Based Execution of Plan P 2
In contrast, Figure 4.2 shows the fully vectorized plan, where each operator is executed
within an execution bucket. Note that we also emphasized the changed operator parameters.
Vectorized plan P’
Assign (o2)
[in: msg1, out: msg2]
Invoke (o3)
[service: s4, in: msg2, out: msg3]
Message
Queue
Copy (oc)
[in: msg1, out: msg1]
Join (o4)
[in: msg1,msg3, out: msg4]
Assign (o5)
[in: msg4, out: msg5]
Invoke (o6)
[service s3, in: msg5]
inter-bucket message queue
execution bucket bi (thread)
Figure 4.2: Example Fully Vectorized Execution of Plan P ′ 2
We can leverage pipeline parallelism (within a single pipeline) and parallel pipelines. In
this model, each edge of a data flow graph includes a message queue for inter-operator
communication. Dashed arrows represent dequeue (read) operations, while normal arrows
represent enqueue (write) operations. Additional operators (e.g., the Copy operator for
data flow splits) are required, while the Receive operator is not needed anymore.
Major challenges have to be tackled when transforming P into P ′ in order to preserve
the control-flow semantics and prevent the external behavior from being changed. Based
on the mentioned requirement of ensuring semantic correctness in the form of serialized
external behavior, we now formally define the plan vectorization problem. Figure 4.3(a)
illustrates the temporal aspects of the example instance-based plan (assuming a sequence
of operators). In this case, different instances of this plan are serialized in incoming order.
Such an instance-based plan is the input of our vectorization problem. In contrast to this,
Figure 4.3(b) shows the temporal aspects of a vectorized plan for the best case. Here,
only the external behavior (according to the start time t 0 and the end time t 1 of plan
and operator instances) must be serialized. Such a vectorized plan is the output of the
vectorization problem. The plan vectorization problem is then defined as follows.
90