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

4 Vectorizing Integration Flows
• Intra-Operator (Horizontal): First, the operator implementations can be changed
such that they split input messages, work on data partitions of input messages in
parallel, and finally merge the results. For example, this type of parallelism is used
in the XPEDIA system [BABO + 09]. In the context of processing tree-structured
messages (XML), the benefit is limited due to a high serial fraction required for
splitting and merging of messages.
• Inter-Operator (Horizontal): Second, there are the already mentioned techniques
on rewriting sequences and iterations to parallel subflows (Subsection 3.4.1), where
the scope is intra-instance (or synonymously inter-operator) only. However, in the
absence of iterations and due to restrictive dependencies between operators, the
benefit of these techniques is limited. Nevertheless, they are valid because they can
be applied to all types of flows, while the following two techniques are limited to
data-driven integration flows.
• Inter-Instance (Horizontal): Third, we could execute multiple plan instances in parallel.
Unfortunately, due to the need for logical serialization of plan instances (Section
2.3.2), simple multi-threaded plan execution is not applicable because expensive
global serialization would be required at the outbound side. If no serialization is required,
this technique has the highest optimization potential.
• Inter-Operator/Inter-Instance (Vertical): Fourth, there is the possibility of pipeline
parallelism with a scope that stretches across multiple instances of a plan.
In order to overcome the problem of low CPU utilization, we introduce the vectorization
of integration flows that uses the fourth possibility by applying pipelining to integration
flows. Instance-based plans (that use an one-operator-at-a-time execution model)
are transparently rewritten into pipelined plans (that use the pipes-and-filters execution
model, where multiple operators represent a pipeline and thus, are executed in parallel).
This concept of vectorization applies to data-driven integration flows (that include at least
one Receive operator). More specifically, it is designed for asynchronous data-driven integration
flows, where the client source systems are not blocked during execution of a
plan instance. However, it is also extensible for synchronous data-driven integration flows
by employing call-back mechanisms in combination with the concept of correlation IDs
[OAS06], where waiting clients are logically mapped to asynchronously processed messages.
Due to the control-flow semantics of integration flows and the need for ensuring
semantic correctness, transparent pipelining as an internal optimization technique (not
visible to the user) poses a hard challenge.
With regard to this challenge, in Section 4.2, we introduce the full vectorization of
plans, where each operator is executed as a single thread. There, we discuss the rewriting
algorithm as well as the rewriting with control-flow-awareness in detail. While, this typically
already increases throughput, the full vectorization exhibits a fundamental problem:
namely, this execution model might require a high number of threads.
Problem 4.2 (High Number of Required Threads). If each operator is executed as a single
thread, the number of operators determine the number of threads required for a vectorized
plan. Thus, the throughput improvement of a concrete plan achieved by vectorization
strongly depends on the number of operators of this plan. In dependence on the concrete
workload (runtime of a single operator) and the available parallelism of the used hardware
platform, a number of threads that is too high can also hurt performance due to additional
88