Algorithmes de routage pessimiste

Dans cette section nous décrivons la mise en œuvre du scénario décrit dans la section précé-dente avec un modèle d’exécution pessimiste. Le principe de base est que les transactions sont exécutées dans l’ordre défini par le plan d’exécution. Nous présentons d’abord l’algorithme pour choisir un nœud ND afin d’exécuter une transaction T . Puis, nous détaillons l’exécution de T sur ND.

Choix du nœud optimal

Nous définissons par Card(G) le nombre de sommets d’un graphe, autrement dit, le nombre de transactions. La fonction getF irst(G) retourne le premier sommet (i.e. sommet sans prédécesseur) d’un graphe G. Le choix du nœud sur lequel exécuter une transaction est basée sur le coût et utilise la synchronisation à la demande. Il tient compte du coût de rafraîchissement d’un nœud dans le calcul du coût global d’un nœud.

Dans un premier temps, l’algorithme évalue, pour chaque nœud NDj de la liste des candidats potentiels :

– la charge de ND_j. Cette composante du coût du nœud est obtenue en évaluant le temps d’exécution restant de toutes les transactions actives sur ND_j;

– le coût de rafraîchissement de NDj afin que celui-ci soit suffisamment frais par rapport à l’obsolescence tolérée par la transaction T (on rappelle que si T fait des mises à jours, cette tolérance est forcément nulle). A cet effet, l’algorithme calcule le graphe de rafraîchissement GRT

Algorithme 1: CalculRafraichissement (NDj, Obs)

entrées : ND_j nœud de données, Obs obsolescence tolérée, GSG. sorties : GR^T_j graphe de rafraichissement

variables : GV fraîcheur du nœud ND_j i.e.graphe de transactions déjà validées et/ou en cours sur ND_j.

1 begin

2 GRT j = ∅ ;

3 while Card(GSG) − card(GV ) ≤ Obs do

4 T⁰ = getF irst(GSG − GV ) ; 5 GRT j = GRT j ∪ T0); 6 GV = GV ∪ T⁰ ; 7 return GR^T_j

Le coût de rafraîchissement est donc le temps total estimé pour exécuter toutes les transac-tions dans GRT

j. Nous mentionnons également que GRT

j peut contenir des transactions déjà validées et des transactions en cours.

– le coût d’exécution de T elle-même. Ce coût est obtenu en calculant la moyenne glissante du temps d’exécution des dernières transactions exécutées sur le système ;

– le coût total de l’exécution de T sur ND_j appelé CoutExec(N D_j, T ) est obtenu en faisant la somme des trois coûts précédents.

Ensuite le ND avec un coût d’exécution le plus faible est choisi comme nœud optimal et correspond à NDk défini par notre fonction de coût CoutExec(N Dk, T ) = M in({(CoutExec(N D_i, T )}) tel que pour tout ND_i appartenant aux nœuds candidats. La fonction ChoisirNoeud() décrite par l’algorithme 2 donne les détails du calcul du nœud optimal.

Exécution cohérente des transactions au niveau du ND

Dans cette section nous présentons comment un ND assure la cohérence mutuelle en exécutant une transaction conformément aux exigences du plan d’exécution. Nous montrons d’abord qu’une exécution suivant le plan d’exécution est cohérente puis nous présentons l’algorithme utilisé pour exécuter le plan.

Maintien de la cohérence. Ce paragraphe décrit pourquoi le plan d’exécution généré par l’al-gorithme 5.1.3 est suffisant pour garantir la cohérence mutuelle. Pour ce faire nous énonçons la propriété suivante.

Propriété 1. Si l’ordre d’exécution des transactions sur chaque nœud est compatible avec l’ordre global (GSG), alors la cohérence à terme est garantie puisque toutes les transactions seront exé-cutées sur tous les nœuds dans un ordre compatible.

Algorithme 2: ChoisirNoeud (LC, Obs)

entrées : LC liste des nœuds candidats, Obs obsolescence tolérée. sorties : N_optnœud ND choisi, P plan d’exécution.

variables : GC : Graphe de transaction en cours sur le ND considéré, GR le graphe de rafraichissement, AV G(T ) : temps moyen d’exécution des transactions, Min : réel, CoutExec : coût d’exécution de T

1 begin

2 M in = ∞ ;

3 foreach N ∈ LC do

4 GR = CalculRaf raichissement(N, Obs);

5 CoutExec(N, T ) = AV G(T ) ∗ [(Card(GR) + Card(GC)) + 1];

6 if CoutExec(N, T ) < M in then

7 M in = CoutExec(N, T );

8 N_opt = N ;

9 return Nopt

par GT 1 et GT 2 sur ND1 et ND2. Supposons que T 1 et T 2 soient exécutées dans un ordre différent sur les deux ND, par exemple, T 1 → T 2 sur ND1 et T 2 → T 1 sur ND2.

Cela veut dire que GT 1 et GT 2 ont utilisé chacun un GSG différent pour calculer les plans d’exécution de T 1 et T 2, autrement dit, GT 2 n’a pas lu les modifications faites sur le GSG par GT 1. Ceci n’est pas possible puisque le GSG est unique et est géré de tel sorte que tout accès concurrent soit sérialisé (cf. section 5.2). Ainsi GT 2 utilise forcément le même GSG que GT 1 vient de modifier, ce qui veut dire que GT 2 inclut T 1 dans le graphe de rafraîchissement requis pour exécuter T 2 et dès lors T 1 → T 2.

De plus comme toutes les transactions de mise à jour et de rafraîchissement sont routées avec cet algorithme 5.1.3, alors la convergence des copies ne peut pas être compromise puisque les ND exécutent les transactions dans le même ordre qu’ils les reçoivent (cf. paragraphe ci-après).

Exécution des transactions. Pour exécuter les transactions sans compromettre la cohérence mu-tuelle, il faut garantir la propriété 2, qui à son tour exige une application parfaite de (P (N D, T )). Pour respecter l’ordre de P (N D, T ), l’Ordonnanceur d’un nœud ND ne transmet au SGBD local la transactions T que lorsque toutes les transactions qui l’ont précédées ont été transmises et vali-dées avec succès. Si une ou plusieurs transactions précédant T ne peuvent pas être exécutées pour une raison quelconque, l’Ordonnanceur avise le Planificateur qui à son tour renseigne le GT de la situation en lui faisant parvenir l’état de rafraîchissement du nœud si toutefois il a été entamé. En d’autres mots, si une partie des transactions de rafraîchissement a été validée avec succès, alors le GT est tenu au courant pour qu’il mette à jour les informations du catalogue. L’algorithme 3 définit la procédure déroulée par l’Ordonnanceur pour s’assurer de la bonne exécution de P .

exécu-Algorithme 3: ExecuterP (P ) entrées : P plan d’exécution. sorties : booléen 1 begin 2 while Card(P ) 6= 0 do 3 T_c = (getF irst(P )); 4 delivrer(T_c) ; 5 repeat 6 attendre();

7 until fin transaction;

8 if T_c.etat=valideethen

9 P = P − T_c;

10 else

11 return Echec ;

12 return Succes;

tion. De plus, l’Ordonnanceur via la fonction attendre() est bloqué jusqu’à ce que T_csoit validée ou annulée. Si T_c est annulée alors la transaction T échoue puisque le nœud ne sera pas suffi-samment frais pour l’exécuter. Une fois le GT averti de l’échec de l’exécution de T ou d’une exécution en partie de la séquence de transaction qui devrait la précéder, il choisit un autre nœud pour reprendre l’exécution de T mais en recalculant la nouvelle séquence de précédence relative au nouveau ND choisi. Ce processus est itéré jusqu’à ce que la transaction puisse être exécutée sur un ND. En cas de non exécution de la transaction après avoir sollicité toutes les répliques candidates, le client est informé.

Exemple. La figure 5.2 illustre un système composé de deux nœuds de données N D1 et N D2. Le catalogue réparti indique que N D1 a reçu T 1 et T 2 alors que N D2 n’a exécuté que T 1 avec la contrainte T 1 précède T 2. Supposons qu’à partir de cet état du système, il arrive une troisième

transaction T 3 avec un niveau de fraîcheur maximal. En d’autres mots, T 3 requiert l’état le plus récent des données. La figure 5.3 montre que le GT ayant reçu T 3, par l’intermédiaire de l’algo-rithme décrit précédemment désigne le nœud N D2 comme nœud optimal. Ce qui fait que le GR correspondant est T 2 puisque c’est l’unique transaction dans le GSG à ne pas être exécutée sur N D2. Enfin, le GT envoie le GR et T 3 à N D2 puis met à jour le catalogue. Ainsi, comme le montre la figure 5.3, le GSG est complété avec T 3 et l’état de N D2 inclut désormais les deux dernières transactions qui viennent d’être envoyées. L’envoi de GR suivi de T 3 signifie et sera interprété par ailleurs par N D2 que T 2 → T 3.

FIGURE5.3 – GSG après routage

Nous mentionnons que le GSG est utilisé que pour garder la cohérence par conséquent, il ne contient que les transactions de mises à jour qui peuvent introduire des incohérences.

Discussion

Le mécanisme de routage décrit dans cette section assure une sérialisation globale de manière pessimiste. Il est utilisé aussi bien pour router les transactions de mise à jour que les requêtes. Chaque transaction est associée avec ses classes de conflits, qui contiennent les données que la transaction peut potentiellement lire (resp. modifier). En fonction des classes de conflits, les tran-sactions sont ordonnées dans un GSG en s’appuyant sur leur ordre d’arrivée. Bien que cette ap-proche assure une sérialisation globale, il réduit malheureusement la parallélisation du traitement des transactions puisqu’elle s’appuie sur des sur-ensembles potentiels de données réellement accé-dées. Par exemple, si les transactions T et T⁰ écrivent sur la relation R, alors elles seront exécutées sur chaque nœud dans le même ordre. Pourtant, si T et T⁰ n’accèdent pas aux même tuples, elles pourraient être exécutées dans n’importe quel ordre, ce qui accroît le parallélisme et donc le débit transactionnel.

Par conséquent, pour accroître la parallélisation du traitement des transactions, nous proposons dans la prochaine section, un second algorithme hybride qui combine une approche pessimiste et optimiste.