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

4.2 Plan Vectorization
thread monitoring and synchronization efforts as well as increased cache displacement.
This problem is strengthened in the presence of multiple deployed plans because there, the
total number of operators and thus, the number of threads is even higher. In addition, the
higher the number of threads, the higher the latency time of single messages.
To tackle this problem of a possibly high number of required threads, in Section 4.3, we
introduce the cost-based vectorization of integration flows that assigns groups of operators
to execution buckets and thus, to threads. This reduces the number of required threads
and achieves higher throughput. In addition, Section 4.4 discusses how to compute the
optimal assignment of threads to multiple deployed plans. Finally, Section 4.5 illustrates
how this cost-based vectorization of integration flows, as an optimization technique for
throughput maximization, is embedded into our overall optimization framework that was
described in Chapter 3.
In contrast to related work on throughput optimization by parallelization of tasks
in DBMS [HA03, HSA05, GHP + 06], DSMS [SBL04, BMK08, AAB + 05] or ETL tools
[BABO + 09, SWCD09], our approach allows the rewriting of procedural integration flows to
pipelined (vectorized) execution plans. Further, existing approaches [CHK + 07, CcR + 03,
BBDM03, JC04] that also distribute operators across a number of threads or server nodes,
compute this distribution in a static manner during query deploy time. In contrast, we
compute the cost-optimal distribution during periodical re-optimization in order to achieve
the highest throughput and to allow the adaptation to changing workload characteristics.
4.2 Plan Vectorization
As a prerequisite, we give an overview of the core concepts of our plan vectorization
approach [BHP + 09b]. We define the vectorization problem, explain the required modifications
of the integration flow meta model, sketch the basic rewriting algorithm, describe
context-specific rewriting rules and analyze the costs of vectorized plans.
4.2.1 Overview and Meta Model Extension
The general idea of plan vectorization is to transparently rewrite the instance-based plan—
where each instance is executed as a thread—into a vectorized plan, where each operator
is executed as a single execution bucket and hence, as a single thread. Thus, we model a
standing plan of an integration flow. Due to different execution times of the single operators,
transient inter-bucket message queues (with constraints 8 on the maximum number
of messages) are required for each data flow edge. With regard to our classification of
execution approaches, we change the execution model from control-flow semantics with
instance-local, materialized intermediates to data-flow semantics with a hybrid instanceglobal
data granularity (pipelining of materialized intermediates from multiple instances),
while still enabling complex procedural modeling. We illustrate this idea of plan vectorization
with an example.
Example 4.1 (Full Plan Vectorization). Assume the instance-based example plan P 2 as
shown in Figure 4.1(a). Further, Figure 4.1(b) illustrates the typical instance-based plan
8 Queues in front of cost-intensive operators include larger numbers of messages. In order to overcome the
high memory requirements, typically, the (1) maximal number of messages or (2) the maximal total
size of messages per queue is constrained. It is important to note that finally, this constraint leads to
a work-cycle of the whole pipeline that is dominated by the most time-consuming operator.
89