We presented in Section 2.7.2 two directions of data partitioning which are: graph partitioning and hash partitioning. We compared their methods, outcomes, and effects on the performance of distributed query processing. In our system, we chose to perform graph partitioning aiming to reduce the communication costs while having steady ground for the workload-based adaption. In this section, we describe how the system performs this partitioning, and the approaches used to deal with its main issues which are the: partitions balance, the running time, and the border region.
We have seen in Section 2.1.4 that any RDF data set can be seen as a single graph.
The RDF data partitioning is then directly reduced into a graph partitioning prob-lem. Since that each partition is assigned to a single host, the number of partitions is known and equal to |H|, which is the number of hosts in our system. The objective of graph partitioning is related to how the system is going to employ and process the result of the partitioning process. Each host should use his share to execute the query it receives. The execution of a SPARQL query can be mapped into a subgraph matching problem (Section 2.6). While we are looking for a certain sub-graph q in a certain graphGi, it may happen that we have reached theGi border, and having a sub-graph gˆi matches the sub-query graphq, whereˆ qˆ⊆q andgˆ⊆Gi. We would then be in the problem of answering the following question:
Does a data graph Gj (hosted by one of the neighbour nodes) have a sub-graph gˆj such that both gˆi and gˆj form a single sub-graph g = ˆgi ∪gˆj, and g matches the query graphq?
The answer to the above question requires moving data across the network, which is marked as a costly operation that we should avoid by the partitioning process. At the initial step (i.e. at system start-up), we don’t have a certain assumption about the workload or the expected shape of system queries. Thus, the initial step should partition the input RDF graph while trying to achieve the minimum probability of queries to require data from neighbours, and increase the probability of local execu-tion within hosts available data. One of the best methods to achieve this is by using a min-cut algorithm such that we have the partitions’ borders with the minimum number of edges, thus with minimum probability of a query requiring sub-graphs data from neighbours. However, the process requires also some assumption of bal-ancing the size of the resulting partitions. For this purpose, we use METIS and discuss its constraints and output in the next subsections.
5.3.1 METIS based Partitioning
METIS [45] is a set of tools developed by Karypis Lab 1 that serve the purpose of graph partitioning based on the multilevel recursive-bisection, multilevel k-way, and multi-constraint partitioning schemes. For the context of this thesis, we define the partitioning process of METIS as in the following:
Definition 5.1 (METIS Partitioning) We refer to METIS as a functionmetis(v) which for anyv∈V returns the static partition number whichvbelongs to. We could
1http://glaros.dtc.umn.edu/
then define the partition ri ={v∈ V |metis(v) =i}. V is the set of RDF vertices as given by definition 2.1.
The general objective of such partitioning is to have a minimum number of edges (or sum of edges’ weights) that straddle different partitions, while at the same time, it tries to produce balanced partitions. This balance is defined by METIS as a set of constraints. The set of constraints is mapped into a vector of weights for each vertex in the graph. All the vectors of all the vertices within a certain METIS partition can be summed into one total vector. The partitioning process will try to produce partitions that have equal total vectors. The default vector contains one element for each vertex having a value of 1. This vector instructs METIS to produce partitions that are of equal size in terms of the number of vertices. However, setting strict balancing constraints would reduce the accuracy of the general objective of having a minimum number of edges between partitions besides increasing the complexity of the optimization problem such that it costs more computation steps. For these reasons, METIS allowed the user to specify the maximum degree of load imbalance allowance, by using the option: options[METIS OPTION UFACTOR]. This option is defined by METIS [43] as the maximum allowed load imbalance among the partitions for each element of the constraints vector. We denote it asimbalance(j) for constraint j in the constraints vector. The formula that defines imbalance(j) for partition i according to [43] is:
maxi (w(j, i)
t(j, i))6 imbalance(j)
1000 + 1 (5.3)
Where, w(j, i) is the fraction of the overall weight of the jth constraint that is assigned to partition i, and t(i, j) is the desired weight of the jth constraint for partitioni.
Since our current objective of initially partitioning an RDF graph has no assump-tion about the workload, the interesting constraint is partiassump-tions sizes in terms of their number of vertices. In this context, our constraints vector is the default vector.
However, we need to set a suitable value for the maximum acceptableimbalanceto be set inoptions[METIS OPTION UFACTOR].
Adaption of Partitions Size Balance
Setting a proper value to the METIS imbalance option (options[METIS OPTION UFACTOR]) is not handled or formulated in all the known related works that used METIS to partition the RDF graph despite its effect on the outcomes of the METIS.
Relaxing this value would speed up the partitioning process as well as increase the accuracy of its main objective that is having minimum cut; although it could produce variation in partitions’ sizes.
Since we want to avoid any fixed parameters in our adaptable system, we would like to formalize a method that allows the system to find a proper value of imbalance.
Relaxing the imbalance value is a more favourable choice. This coming from the idea that the host with smaller data size can fill its extra space by replications from the neighbours. Thus, we focus on the first place on performing more optimal partitioning, then solve the problem of extra storage space, by also choosing more optimal parts to replicate.
We let our system adapt itself to the best possible partitions balancing situation that is suitable to the available storage size which could be allocated by each working node for hosting its main data share. The value of this storage space which we denote Sm is dynamically allocated by our storage space optimizer (Section 6.2).
If the total data size is Sd in a system of |H| hosts, the balanced host share would be:
Sd
|H|
At hosti, the difference between the available storageSmiand the host share of the data |H|Sd is the amount of extra data that the host i can tolerate. Thus, we can tolerate a maximum imbalance per partition Po as given by:
Po= min
i (Smi− Sd
|H|)
However, to avoid creating an extreme case of partitions size variation, we limit the maximum accepted imbalance per partition to half the initial proposed share. In this context,Po is rewritten as:
Po= min[min
i (Smi− Sd
|H|), Sd
2· |H|] (5.4)
The above value ofPoadapts dynamically with the available storage providing the enough flexibility to METIS to produce well partitioned graph while still avoiding the case of extreme size variation.
To mapPo into the METIS imbalance factor and from Equation 5.3, we have:
Sd When we solve forimbalance, we get:
imbalance= 1000·Po· |H|
Sd (5.5)
Our partitioning system uses Formula 5.5 to find the imbalance value which is set to the imbalance input option of the METIS. It should be noted that this value is related to the maximum allowed imbalance in the partitioning; however, the METIS tries to produce more balanced partitioning as long as that doesn’t affect the objective of the keeping min-cut across the resulted partitions as been reflected by the inequality in 5.3. The more storage space available at the working nodes, the more flexibility we give to the METIS to favour producing more connected rather than more balanced partitions, although, this could leave some hosts with only small size of data, which can be next utilized by replication as we have mentioned earlier in this subsection.