25.01.2015 Views

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

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

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

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

3.5 Experimental Evaluation<br />

(a) Cumulative Execution Time<br />

(b) Cumulative <strong>Optimization</strong> Time<br />

Figure 3.22: Use Case Comparison <strong>of</strong> Periodical Re-<strong>Optimization</strong><br />

asynchronous optimization but synchronous exchange <strong>of</strong> plans, where execution is blocked.<br />

As a result both cumulative execution time and elapsed time might have different optimal<br />

∆t configurations. Thus, this parameter is a possibility to fine-tune the optimizer.<br />

Third, with regard to workability, we observed fairly similar results for our other example<br />

plans and statistic variations. Here, we compared the periodical re-optimization with<br />

no-optimization once again. In detail, we executed 20,000 plan instances for each example<br />

plan (P 1 ,P 2 ,P 3 ,P 4 ,P 5 ,P 6 ,P 7 ,P 8 ) and for each execution model. There, we fixed the cardinality<br />

<strong>of</strong> input data sets to d = 1 (100 kB messages) and used a well-balanced workload<br />

configuration (without correlations and without workload changes). Furthermore, we fixed<br />

an optimization interval <strong>of</strong> ∆t = 5 min, a sliding window size <strong>of</strong> ∆w = 5 min and EMA as<br />

the workload aggregation method.<br />

To summarize, we consistently observe execution time reductions (see Figure 3.22(a)).<br />

In the following, we describe in detail how these benefits have been achieved:<br />

• P 1 : This plan was affected by three different optimization techniques. First, the<br />

technique WD1 reordered the two paths <strong>of</strong> Switch operator o 2 . Furthermore, the<br />

operator sequence (o 7 ,o 8 ,o 9 ) has been rewritten to parallel subflows (o 7 ) and (o 8 ,o 9 ).<br />

Finally, the technique WC1 rescheduled the start <strong>of</strong> both subflows in order to start<br />

the most time-consuming subflow (o 8 ,o 9 ) first.<br />

• P 2 : No optimization technique affected this plan.<br />

• P 3 : Similar to plan P 1 , the techniques WC2 and WC1 have been applied on the operator<br />

sequence (o 2 ,o 3 ) in order to rewrite this sequence to parallel subflows and to<br />

reschedule the start <strong>of</strong> these subflows. In addition, the technique WD6 has been applied<br />

in order to pushdown the invariant group-by and thus, exchanged the temporal<br />

order and data dependencies <strong>of</strong> operators o 4 and o 5 .<br />

• P 4 : For this rather complex plan, only the optimization technique WD9 was applied.<br />

In detail the Join operator o 9 was rewritten from a nested loop join to a subplan <strong>of</strong><br />

two (concurrent) Orderby operators and one merge join.<br />

• P 5 : Similar to our first end-to-end comparison scenario, the technique WD4 was applied<br />

for the plan P 5 with the aim <strong>of</strong> reordering the sequence <strong>of</strong> Selection operators<br />

(o 2 ,o 3 ,o 4 ).<br />

• P 6 : This plan was affected by a set <strong>of</strong> techniques. First, the initially given Fork<br />

operator was rescheduled by WC1. Furthermore, the techniques WD11 and WD8<br />

rewrote the two subsequent Setoperation (UNION DISTINCT) operators to a sub-<br />

77

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!