Algorithm 2. HC-SA M-OLAP algorithm.
As we apply a per node space constraint, the hill
climbers’ moves may produce invalid solutions, as
when the materializing space is higher than the
maximal allowed space. In this work, we employ a
repair method, with the reposition of the HC by
randomly turning 1 positions to 0 until the HC’s
proposal is valid.
Input: L // Lattice (all granularity’s combinations and subcubes’ dependencies)
S=(S
1
... S
n
.) ; Q=(Q
1
... Q
n
) // Max. storage nodes’ space, query set (freq., dist.)
Pb // Base Parameters: Tf (type of Hc fixing), nOSN (number of OSNs),
MaximalSizeMaintWindow
Psa // Parameters of simulated annealing algorithm (NumHC, NumIter,
DefMovim, T
0
, α, tpGerac)
Mt // maintenance costs’ dependencies
P=(P
1
... P
n
.); X=(X
1
... X
n
.) // Nodes’ processing power; connections’ param.
Output: M // Materialized subcubes selected and allocated
Begin
1. Initialization:
M← { c
0
} // initialize with all empty nodes; node 0 has the base virtual relation
E← { }; d← NSCubes * nOSN // HC’ expedit. empty; d=dim. of search space
2. Generation, repairing, evaluation and showing the state of the initial HC’
expedit.
Repeat NumHC Times: // NumHC is the number of HCs of the expedition
While (MaintCost(hc))>MaximalSizeMaintWindow Do: // while position of
// generated hill climber (HC) doesn’t satisfy the maintenance constraint
hc ← GenerateHC(d) // generates the HC into a random position in d
For Each n Into MOLAP, Do: // for each OSN in MOLAP architecture
If (size(pos(hc),n)) >S
n
Then // if size of materialized subcubes proposed
// by solution of HC for node n > available mat. space in node n (S
n
)
Reposition(hc); // relocate HC into the dimensions mapped to node n
// to observe the space constraint
Next n
End While
E ←E
∪
hc; // add the hill climber to the expedition
fitness(hc)= f (hc, Q, M, X);
If fitness(hc)>hcBest Then hcBest ←fitness(hc); // updates hcBest (not really
// necessary, but interesting to show the initial best position)
End Repeat
ShowState(E); // shows the instant state of all hill climbers and hcBest
3. Expedition’s movement, fitness evaluation of each solution and state show:
Iter ←0; // iterations counter
While (Itr < NumIter) Do: // final condition is the number of iterations
T ← update (T); // T varies from T
0
until T→ 0 at each fuT iterations;
If iter>frozenI OR T<frozenT Then frozen ← true; // after frozenI
// iterations or when T is lower than a given value, the system is frozen
interv_Max_Unmat ←update(interv_Max_UnMat); // updates maximal
// number of bits which represent the position of each HC that was allowed
// to change from 1 to 0 in each iteration
intervMaxRemat ←update(intervMaxRemat) ; // updates maximal number of
// bits which represent the position of each HC that was allowed to change
// from 0 to 1 in each iteration
wU←rnd(interv_Max_UnMat); // generates the number of bits
// to change from 1 to 0 (un-materialize)
wR←rnd(interv_Max_ReMat); // generates the number of bits
// to change from 0 to 1 (materialize corresponding subcubes)
// Moves each HC according to the defined movement scheme
For Each hc Into E, Do:
While (MaintCost(hc))>MaximalSizeMaintWindow Do: // while new
// position of HC doesn’t verify the maintenance cost constraint
Repeat wU Times: // un-materilize wU sbcubes (changing bits - 1 to 0)
d ← select (D); // randomly selects node and subcube to un-materialize
hc(d) ← 0; // turns the bit (which represents the HC’s position) - 1 to 0
End Repeat
Repeat wR Times: // rematerilize wR sbcubes (changing bits - 0 to 1)
d ← select (D);// selects node and subcube to un-materialize with a
// prob. proportional to the available space into each node or to the
// relation available space x total space of each node; the subcube to
// rematerialize cannot imply the break of imposed space constraint
hc(d) ← 1; // turns the bit (which represents the HC’s pos. from 0 to 1)
End Repeat
End While
// Accepting or rejecting HC’s movement
delta ← f (hc (iter-1), Q, M, X) – f (hc (iter), Q, M, X); // computes the
// delta (loss of quality) concerning to HC movement,
// f is the fitness function
If delta > 0 AND frozen=true OR delta > 0 AND rnd([0,1))>e
-Δ/T
Then
hc(iter) ← hc(iter-1); // restore prev. pos. of the HC, reject. the new pos.
fitness(hc)= f (hc, Q, M, X);
If fitness(hc)>hcBest Then hcBest ←fitness(hc); // updates hcBest
Next hc;
ShowState(E); // shows the instant state of all hill climbers and hcBest
iter ← iter ++; // increments iterations’ counter
End While
4. Returning of result:
Return M(hcBest) // ret. M corresp. to the best posit. ever achieved by any HC
End
5 EXPERIMENTAL
PERFORMANCE STUDY
To perform the experimental study of the algorithms
we used the test set of Benchmark’s TPC-R (TPC-
R), selecting the smallest database (1 GB), from
which we used 3 dimensions (customer, product and
supplier). To broaden the variety of subcubes, we
added additional attributes to each dimension,
generating hierarchies, as follows: customer (c-n-r-
all); product (p-t-all) and (p-s-all); supplier (s-n-r-
all). Whenever the virtual subcube (base relation) is
scanned, this has a cost three times the subcube of
lower granularity.
We have used a 3 and 6 nodes’ M-OLAP
architecture (plus the base node), several randomly
generated query sets (of different sizes), and we
considered incremental maintenance costs. With this
environment we intend to evaluate the impact of the
following parameters onto the algorithm’s
performance: 1) the number of iterations, 2) the
value of T, 3) the number of HCs, 4) the number of
queries, and 5) the scalability of the algorithm
relating to the number of M-OLAP architecture’s
nodes. Given the stochastic nature of the algorithms,
all presented values are the average of 10 runs.
5.1 Parameters Tuning
Several preliminary tests were performed to tune
some parameters, whose selected values are shown
in Table 1. Other parameters, as fudri, the frequency
of T updating, and the iteration of the freezing of the
simulated annealing (when the simulated annealing
mechanism stops acting, thus the algorithm starts
behaving like a local search algorithm), are changed
accordingly to the selected values, for the associated
parameters. To make things clear, in this table, all
parameters are described.
As said above, the balance of the relation
exploration versus exploitation is changed along the
search process, by decreasing dsc and rsc range (at
each fudri – update frequency of dematerialization
and rematerialization interval). Reducing the range
of each HC’s journey with the running of the
algorithm implies that, in the beginning, the
exploration is favored; in opposite, in the later
OPTIMIZATION OF DISTRIBUTED OLAP CUBES WITH AN ADAPTIVE SIMULATED ANNEALING
ALGORITHM
25