UNIVERSITÉ CHEIKH ANTA DIOP

ÉCOLE DOCTORALE DE MATHÉMATIQUES ET INFORMATIQUE (EDMI)

THÈSE POUR L’OBTENTION DU GRADE DE

Docteur de l’Université Cheikh Anta Diop

Spécialité : INFORMATIQUE

présentée par

IBRAHIMA GUEYE

Titre de la thèse

Traitement des transactions à large échelle avecajustement dynamique des ressources à la demande

Soutenue le 16 Décembre 2015 devant le jury composé comme suit :

Président : Pr Hamidou DATHE, Professeur UCADRapporteurs : Pr Ousmane THIARÉ, Professeur UGB

Dr Stéphane GANÇARSKI, Maître de conférences (HDR) UPMCExaminateurs : Dr Oumar NIANG, Maître de conférences EPT

Dr Cheikh Ahmadou Bamba GUEYE, Maître de conférences UCADDirecteur de thèse : Pr Mamadou SANGHARÉ, Professeur UCADCo-directeur : Dr Idrissa SARR, Maître de Conférences UCADCo-directeur : Dr Hubert NAACKE, Maître de Conférences UPMC

Année universitaire 2014-2015

”I hear and I forget. I see and I remember. I do and I understand.”

- Confucius

à feus mon père et mon frère,à ma famille. . .

ii

Remerciements

La thèse est une longue épreuve au cours de laquelle les résultats et les succès obtenus dé-

pendent autant de notre labeur et notre persévérance que des personnes tout au tour. Je suis

chanceux d’avoir eu des personnes d’une grande qualité et en nombre tout au long de ce voyage.

Je suis conscient que les mots à eux seuls ne sont pas suffisants pour dûment remercier tout le

monde, mais c’est un bon début.

Avec une gratitude immense, je remercie mes encadreurs Dr Idrissa Sarr et Dr Hubert Naacke

pour leur soutien constant, leur orientation, leur encadrement et leurs conseils tout au long de

ma thèse. Les perspectives de recherche et la vision d’Idrissa et d’Hubert ont rendu ce travail

possible. C’est assez facile de travailler avec de tels chercheurs dont la rigueur dans le travail et

la qualité ne sont plus à démontrer. En dehors du travail d’encadrement leur simplicité et leur

attitude décontractée m’ont particulièrement marqué. Leurs caractères continueront de m’inspi-

rer tout au long du chemin qui me reste à faire.

Je remercie les membres du Jury : les professeurs Hamidou Dathe, Oumar Niang, Cheikh Ah-

madou Bamba Gueye pour leur disponibilité, leurs critiques, questions et discussions. Malgré

leur emploi du temps très chargé, il ont accepté de participer à mon jury, n grand honneur pour

moi.

Je remercie les professeurs Ousmane Thiaré et Stéphane Gançarski qui ont bien voulu être les

rapporteurs de cette thèse. Leur relecture approfondie, questions, critiques et suggestions m’ont

sans aucun doute permis d’améliorer le manuscrit et d’apporter des éclaircissements sur certains

aspects.

Je remercie l’Agence Universitaire de la Francophonie (AUF) pour m’avoir financé deux années

de suite pour mener à bien mes travaux et effectuer des séjours dans mon laboratoire d’accueil,

le LIP6.

Je remercie aussi tous les membres de l’équipe BD du LIP6. Des personnes formidables qui

m’ont accueilli et m’ont mis dans des conditions et une ambiance de travail excellentes. Je re-

mercie tout autant les membres du groupe bases de données et data mining du LID.

Je remercie le docteur Joseph Ndong pour sa collaboration et sa disponibilité.

Je remercie mes collègues doctorants Bassirou Ngom, Ndiouma Bame (Dr), Bassirou Gueye,

Moindze Moussa, Bassirou Diene, Ousmane Diallo (Dr), Mamadou Thionghane, Fodé Camara

(Dr) et Modou Gueye (Dr) pour les échanges intéressants que nous avons souvent eus, leur ami-

tié et soutien.

Je remercie les enseignants-chercheurs de la section informatique du département de Mathé-

matiques et Informatique. Ils nous ont formé, nous ont initié à la recherche et nous ont mo-

tivé pour continuer. J’ai squatté leurs bureaux pendant de longs mois afin de pouvoir travailler.

Merci pour votre accueil et compréhension. Je remercie mes collègues enseignants-chercheurs

du département Génie Informatique et Télécom de l’EPT pour leur soutien et écoute lors des

pré-soutenances.

iii

J’aurais sans doute pu commencé par là si la forme ne m’avait pas tordu le bras (rires)... Je

remercie ma famille, qui m’a toujours soutenu et a été présente pendant les moments difficiles

mais aussi pendant les moments de bonheur. Merci à ma chère épouse Mariama, ma meilleure

moitié, qui a enduré ces longs mois d’absence et ces journées et nuits où j’étais là mais pas

vraiment là. Un doctorant, à force d’être très concentré et très longtemps, peut parfois perdre de

vue le monde qui l’entoure. Mariama a toujours était là pour me raccrocher à cet environnement

réel. Merci pour ta patience, ta compréhension et pour y avoir cru tout autant que moi. Je remer-

cie ma maman pour son soutien inconditionnel et intemporel, pour son amour, pour sa patience

aussi. Je remercie mes sœurs et frères (Coumba, Magueye et Marie). Je vous adore.

Enfin, merci à vous qui lisez ce manuscrit pour l’intérêt que vous portez à ce travail ; merci à

toute personne qui m’a un jour encouragé ou soutenu d’une quelconque manière, ... merci.

Table des matières

Remerciements iii

Liste des Figures viii

1 Introduction 11.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Contexte et cadre général de la thèse . . . . . . . . . . . . . . . . . . . . . . . 21.3 Présentation des problèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Vue d’ensemble de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Architecture globale proposée . . . . . . . . . . . . . . . . . . . . . . 31.4.2 Le partitionnement dynamique en fonction du graphe social . . . . . . 31.4.3 Gestion de la fluctuation de la charge . . . . . . . . . . . . . . . . . . 41.4.4 Modèle d’exécution des transactions . . . . . . . . . . . . . . . . . . . 5

1.5 Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 État de l’art 72.1 Le passage à l’échelle dans la gestion des données . . . . . . . . . . . . . . . . 72.2 Le partitionnement des données . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Le partitionnement statique . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Le partitionnement dynamique . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Le placement des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 La consolidation ou l’optimisation du placement . . . . . . . . . . . . . . . . . 142.5 Autres stratégies de passage à l’échelle . . . . . . . . . . . . . . . . . . . . . . 152.6 La migration des données en temps réel . . . . . . . . . . . . . . . . . . . . . 172.7 Équilibrage de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Concepts de Base et Architecture globale du Système 213.1 Notions d’application Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Défis des application web 2.0 . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Structure des interactions . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Modèle de transaction et notions de base . . . . . . . . . . . . . . . . . . . . . 233.3 Description de notre architecture . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.1 Modèle de communication . . . . . . . . . . . . . . . . . . . . . . . . 263.3.2 Architecture détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Discussion sur les potentiels points de congestion . . . . . . . . . . . . 28

v

Table des matières vi

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Le partitionnement dynamique et le placement des données 304.1 La problématique du partitionnement . . . . . . . . . . . . . . . . . . . . . . . 314.2 Principes de notre partitionnement . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 La séparation des métadonnées et des données de l’application. . . . . 324.2.2 Limiter les opérations courantes à un seul nœud. . . . . . . . . . . . . 33

4.3 Le partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.1 Découverte des cibles . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.2 Formation des partitions . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Le placement des partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Gestion des fluctuations de la charge transactionnelle 385.1 Formulation du problème et solutions proposées . . . . . . . . . . . . . . . . . 38

5.1.1 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Gestion de la charge transactionnelle sur la couche de routage . . . . . . . . . 41

5.2.1 Détection d’une charge anormale . . . . . . . . . . . . . . . . . . . . 415.2.2 Équilibrage de la charge entre les TMs . . . . . . . . . . . . . . . . . . 425.2.3 Élasticité des RNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.4 Équilibrage de la charge et élasticité des SDs . . . . . . . . . . . . . . 43

5.3 Gestion de la charge transactionnelle sur la couche des données . . . . . . . . . 445.3.1 Détection d’un pic de charge . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Identification de l’origine des pics de charge . . . . . . . . . . . . . . 465.3.3 Équilibrage de la charge et élasticité des BD . . . . . . . . . . . . . . . 47

5.3.3.1 Identification des DBs candidates : . . . . . . . . . . . . . . 475.3.3.2 La procédure de migration : . . . . . . . . . . . . . . . . . . 47

5.4 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.4.1 Évaluation de l’élasticité de la couche de routage . . . . . . . . . . . . 48

5.4.1.1 Environnement expérimental . . . . . . . . . . . . . . . . . 495.4.1.2 TransElas vs TransPeer . . . . . . . . . . . . . . . . . . . . 495.4.1.3 Élasticité des TMs . . . . . . . . . . . . . . . . . . . . . . . 505.4.1.4 Élasticité de tout le middleware . . . . . . . . . . . . . . . . 51

5.4.2 Évaluation de l’élasticité sur la couche des données . . . . . . . . . . . 525.4.2.1 Charge peu dynamique . . . . . . . . . . . . . . . . . . . . 525.4.2.2 Charge très dynamique . . . . . . . . . . . . . . . . . . . . 535.4.2.3 Consolidation des ressources . . . . . . . . . . . . . . . . . 54

5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Modèle d’exécution des transactions 566.1 Modèle d’exécution par regroupement des données . . . . . . . . . . . . . . . 56

6.1.1 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.1.2 Cas des transactions mono-cible . . . . . . . . . . . . . . . . . . . . . 576.1.3 Cas des transactions multi-cibles . . . . . . . . . . . . . . . . . . . . . 596.1.4 Processus de regroupement des données . . . . . . . . . . . . . . . . . 596.1.5 Validation expérimentale : Évaluation du regroupement des données . . 61

6.1.5.1 Environnement expérimental . . . . . . . . . . . . . . . . . 61

Table des matières vii

6.1.5.2 Spécification de la charge applicative et configuration . . . . 626.1.5.3 Impact du regroupement des partitions . . . . . . . . . . . . 626.1.5.4 Impact de la fluctuation des cibles . . . . . . . . . . . . . . . 64

Impact de la fluctuation des cibles sur la latence : . . . . . . . . 64Impact de la fluctuation des cibles sur le coût du transfert des

données : . . . . . . . . . . . . . . . . . . . . . . 646.1.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Modèle d’exécution par regroupement des transactions . . . . . . . . . . . . . 666.2.1 Modèle d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2.2 Regroupement des transactions . . . . . . . . . . . . . . . . . . . . . . 67

6.2.2.1 Modèle de communication . . . . . . . . . . . . . . . . . . 67Les jetons : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Graphe de transactions : . . . . . . . . . . . . . . . . . . . . . 69

6.2.2.2 Gestion de la cohérence . . . . . . . . . . . . . . . . . . . . 70Transactions mono-cible : . . . . . . . . . . . . . . . . . . . . 70Transactions multi-cibles : . . . . . . . . . . . . . . . . . . . . 72

6.2.3 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.3.1 Évaluation du regroupement des transactions . . . . . . . . . 746.2.3.2 Absorption des pics de charge temporels . . . . . . . . . . . 756.2.3.3 Impact du nombre de jetons . . . . . . . . . . . . . . . . . . 766.2.3.4 Évaluation du traitement des transactions multi-cibles . . . . 766.2.3.5 Surcharge des approches eager et lazy . . . . . . . . . . . . 78

6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Conclusion et Perspectives 807.1 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Gestion des transactions : . . . . . . . . . . . . . . . . . . . . . 81Gestion d’une charge applicative fluctuante et transitoire : . . . 82

7.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Prédiction de la charge : . . . . . . . . . . . . . . . . . . . . . 83Passage à l’échelle de la gestion des transactions : . . . . . . . . 84Comparaison avec certains travaux de l’état de l’art : . . . . . . 84Tolérance aux pannes : . . . . . . . . . . . . . . . . . . . . . . 84

Bibliographie 85

Résumé 96

Table des figures

1.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 Graphe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Architecture : vue en couches . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Architecture : vue détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Vue détaillée d’un noeud BD . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Détails des composantes de la couche de routage . . . . . . . . . . . . . . . . 28

4.1 Formation et évolution des cibles . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1 Approvisionnement selon la charge courante et non selon le pic maximal . . . . 395.2 Performances globales de TransElas . . . . . . . . . . . . . . . . . . . . . . . 495.3 Nombre de TM vs. Nombre de clients . . . . . . . . . . . . . . . . . . . . . . 515.4 Nombre de TM/SD vs. Nombre de clients . . . . . . . . . . . . . . . . . . . . 515.5 Évolution des temps de réponse dans le système avec l’occurrence de pics pas

trop fréquents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.6 Évolution des temps de réponse dans le système avec un workload très dynamique 545.7 Consolidation du nombre de nœuds BD avec la baisse de la charge . . . . . . . 55

6.1 Logigramme modèle d’exécution 1 . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Scénario de traitement modèle d’exécution 1 . . . . . . . . . . . . . . . . . . . 596.3 Instance locale vs Traitement distribuée avec regroupement . . . . . . . . . . . 636.4 Impact de la fluctuation des cibles . . . . . . . . . . . . . . . . . . . . . . . . 656.5 Exemple de transactions entrantes . . . . . . . . . . . . . . . . . . . . . . . . 676.6 Schéma du modèle de communication . . . . . . . . . . . . . . . . . . . . . . 686.7 Graphes de transactions, ordonnancement et cibles . . . . . . . . . . . . . . . 696.8 Demande de plusieurs jetons de traitement . . . . . . . . . . . . . . . . . . . . 726.9 Temps de réponse vs. Nombre de cibles . . . . . . . . . . . . . . . . . . . . . 746.10 Pourcentage de transactions regroupées vs. non regroupées . . . . . . . . . . . 756.11 Temps de réponse vs. Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.12 temps de réponse vs. Nombre de nœud BD (ou nombre de jetons) . . . . . . . 776.13 Temps de réponse vs. Nombre de nœud BD . . . . . . . . . . . . . . . . . . . 776.14 Nombre de messages vs. Nombre de nœuds BD . . . . . . . . . . . . . . . . . 78

viii

Chapitre 1

Introduction

1.1 Motivations

Les applications dites Web 2.0 ont émergé rapidement. Elles sont aujourd’hui omniprésentes

dans le monde informatique et mettent l’utilisateur au centre des applications telles que les mé-

dias sociaux dans lesquels il y a un échange de données et de services au sein d’un large réseau

d’utilisateurs. Le nombre d’utilisateurs utilisant la même application peut atteindre plusieurs

millions, voire plusieurs centaines de millions. Les bases de données qui servent ces applications

ont une taille très grande, car toute information ou action concernant un utilisateur est stockée.

L’application contrôle ces données qui sont manipulées par toute action d’un utilisateur. Dans

ce type d’applications, la majorité des actions ou interactions d’un utilisateur se traduisent par

des lectures et/ou écritures de données. Avec le nombre croissant d’utilisateurs, le système fait

face à une importante charge transactionnelle. En plus, les utilisateurs exigent une rapidité de

l’exécution pour avoir une facilité dans leurs interactions. Pour satisfaire ce besoin des utilisa-

teurs et faire face à cette charge, il faut pouvoir augmenter assez rapidement les ressources du

système (calcul, stockage, etc.). De plus, compte tenu du rôle joué par les utilisateurs dans ces

applications, le modèle d’accès aux données est fortement assujetti au comportement de ces der-

niers. Ce modèle d’accès erratique, selon des études antérieures [APBC13], pose un problème

de charge fluctuante dû au comportement des utilisateurs. Pour assurer une interaction rapide

aux utilisateurs, il faut borner le temps de réponse et assurer la disponibilité. Ce qui peut se

faire en utilisant la répartition et la réplication des données sous-jacentes. Dès lors, la question

est comment répartir/répliquer les données pour arriver à borner le temps de réponse malgré

les fluctuations de la charge. Une solution est de procéder par une réplication dynamique basée

sur les caractéristiques des interactions entre utilisateurs qui sont généralement représentées à

travers un graphe dit social.

1

Introduction 2

Toutefois, si la répartitions ne se fait pas attentivement, le risque d’avoir des transactions distri-

buées devient important. Ces transactions peuvent être particulièrement coûteuses quand elles

requièrent la garantie d’une cohérence forte. Les synchronisations nécessaires pour une vali-

dation atomique (exemple le 2PC dans [WPC10]) impactent le débit transactionnel et peuvent

parfois prendre beaucoup plus de temps qu’il n’en faut pour traiter la transaction elle même

[TDW+12]. Finalement, le gain recherché en procédant à la répartition devient nul. Par consé-

quent, il est important de procéder à une répartition qui réduit autant que possible le nombre de

transactions distribuées.

1.2 Contexte et cadre général de la thèse

Récemment, beaucoup de travaux ont été faits dans le domaine de la gestion des transactions à

large échelle. Plusieurs solutions ont été proposées pour un traitement des transactions avec une

forte cohérence. Ces solutions prennent en compte à la fois l’exigence des utilisateurs (temps

de réponse faible), et garantissent une disponibilité (réplication). Parmi ces solutions, nous pou-

vons citer celles présentées dans les travaux [IDR10] et [SNG10]. Toutefois, ces solutions ne

prennent pas en compte les caractéristiques des applications web 2.0, liées au graphe social et le

caractère fluctuant et transitoire de la charge. En effet, ces fluctuations de la charge peuvent me-

ner à des situations de surcharges temporaires occasionnant une dégradation des performances.

Les travaux effectués dans notre thèse partent du constat que les applications Web2.0 ont un mo-

dèle applicatif en rupture avec les applications transactionnelles classiques, en termes de charge

applicative et du rôle de l’utilisateur. Un des objectifs de cette thèse est de prendre en compte

les caractéristiques de ces applications pour proposer une solution adaptée de la gestion de leurs

charges transactionnelles.

1.3 Présentation des problèmes

Un ensemble d’utilisateurs interagissant à un moment donné se traduit par un ensemble de tran-

sactions accédant aux données pendant la période de l’interaction. Ces données appartiennent à

des utilisateurs en relation. Plus le nombre d’utilisateurs impliqués dans l’interaction est grand,

plus la taille (ensemble) des données impliquées est grande. Par conséquent, la charge induite est

aussi importante. Un utilisateur interagit avec une personne contact et est libre d’interagir avec

quiconque sans restriction en créant de nouveaux liens. Ainsi, même si on envisage de parti-

tionner les données pour améliorer les performances, il est difficile voire impossible de faire des

partitions qui favorisent les accès disjoints où une transaction n’accède qu’à une seule partition

[TDW+12, LTP+14]. Les problèmes abordés peuvent être résumés comme suit :

– Comment faire un partitionnement dynamique en tenant compte des fluctuations de la charge ?

Introduction 3

– Comment placer les partitions pour faciliter la gestion des transactions et minimiser les res-

sources nécessaires ?

– Comment procéder au traitement des transactions en les regroupant sur un seul noeud ?

1.4 Vue d’ensemble de la thèse

1.4.1 Architecture globale proposée

Pour des besoins de passage à l’échelle et de disponibilité, nous avons conçu une architecture

distribuée sur de multiples machines (ou nœuds). Pour ce faire, nous nous appuyons sur les

principes de conception prescrits dans [DAE13, SNA13]. Ces principes ont suggéré et démontré

que la séparation des fonctions de gestion des transactions de celles d’accès aux données per-

met d’ajuster séparément le nombre de machines allouées pour chacune de ces fonctions. Par

conséquent, nous avons divisé notre architecture en trois couches comme indiqué sur la Figure

1.1.

FIGURE 1.1: Vue simplifiée de notre architecture Globale

La couche de stockage. Elle stocke les données et exécute les transactions.

La couche de Routage. Cette couche effectue les prétraitements nécessaires à une exécution co-

hérente des transactions, et s’occupe de la gestion des ressources nécessaires au fonctionnement

correct du système.

La couche des Applications. La couche supérieure est celle des applications qui génèrent les

transactions à destination de la couche de Routage.

1.4.2 Le partitionnement dynamique en fonction du graphe social

Nous concevons un mécanisme de partitionnement dynamique des données qui se fait automa-

tiquement à chaque fois que des conditions nécessaires sont remplies. Nous tirons parti de la

structure des interactions pour placer dans la même partition les données sollicitées en même

Introduction 4

temps par les mêmes utilisateurs. En effet, en examinant attentivement la charge, nous voyons

que les interactions ont lieu au sein de groupes d’utilisateurs distincts et ces interactions se tra-

duisent par des lectures/écritures des données. Les données sur lesquelles les utilisateurs d’un

groupe se concentrent forment un bloc compact que nous appelons une cible. Ces cibles peuvent

conduire à des pics de charge si la fréquence des interactions et/ou le nombre d’utilisateurs de-

viennent important. Pour gérer une telle situation, nous utilisons un partitionnement horizontal

des données qui est guidé par la formation et l’évolution des cibles.

Le partitionnement doit garantir que les données d’une cible soient stockées dans une même par-

tition, laquelle est sur un même noeud. Il est possible qu’une partition regroupe plusieurs cibles

surtout lorsqu’elles sont liées. Ce partitionnement répond essentiellement à deux besoins : (i)

maintenir les données d’une même cible sur un noeud et (ii) assurer qu’une machine soit tou-

jours capable d’exécuter les transactions touchant ces cibles dans un délai borné. Pour satisfaire

ces besoins, le partitionnement se base fondamentalement sur la structure des interactions des

utilisateurs. En fait, nous suivons activement la formation et l’évolution des cibles. Quand une

cible se forme ou évolue, elle inclue des données d’utilisateurs qui peuvent se situer sur diffé-

rents nœuds. Deux situations peuvent survenir : soit les partitions existantes sont modifiées en

réunissant les données de la cible sur une même partition, soit une nouvelle partition est crée

pour contenir cette cible. Sur la couche de gestion des transactions de notre architecture, nous

avons deux composantes essentielles qui s’occupent du partitionnement et du placement des par-

titions : le moniteur de cibles et le moniteur de ressources. Ces composantes sont responsables

du suivi des cibles et des décisions de placement.

1.4.3 Gestion de la fluctuation de la charge

Il s’agit d’adapter dynamiquement les capacités de traitement du système en fonction des carac-

téristiques de la charge. Précisément, quand la charge augmente et tend à dépasser les capacités

actuelles, le système ajoute de nouvelles ressources (machines) pour déplacer certaines don-

nées et répartir les traitements. Ainsi, la charge est distribuée et les exigences de performances

peuvent être respectées. Il faut noter que les capacités de traitement ajoutées sont évaluées en

fonction des besoins réels. Le surplus de charge est minutieusement évalué pour choisir les ca-

pacités supplémentaires adéquates à ajouter.

De même, quand la charge diminue très fortement, le système diminue les ressources et regroupe

les données pour réduire le coût opérationnel.

Des méthodes existent pour déplacer en temps réel des partitions de la base sans interrompre le

traitement des transactions. Mais pour une résolution efficace de la surcharge en utilisant ces mé-

thodes de déplacement, il est nécessaire d’opérer un minimum de déplacement de données. De

fait, il devient crucial d’identifier avec précision l’origine (cibles, partitions) des pics de charge.

Introduction 5

Nous proposons des méthodes de détection qui renseignent avec suffisamment de détails sur

l’origine et l’emplacement des pics.

1.4.4 Modèle d’exécution des transactions

Nous concevons deux modèles d’exécution des transactions :

– Le premier modèle garantit que toute transaction s’exécute sur un seul nœud. Ce modèle

s’appuie sur un partitionnement et un placement des données guidés par les cibles. Ceci nous

permet de regrouper les données sollicitées par les mêmes transactions sur les mêmes nœuds.

Ce modèle d’exécution est motivé par un besoin d’éviter les transactions distribuées qui sont

souvent coûteuses. Ainsi, nous évitons les transactions distribuées et offrons des fonctionna-

lités riches pour la gestion des transactions à l’échelle d’un nœud. Cette approche est efficace

tout en permettant une montée à l’échelle horizontale.

– Le deuxième modèle s’appuie sur une couche de routage légèrement différente. Les transac-

tions ont des classes d’accès constituées de l’ensemble des données auxquelles elles accèdent.

Nous regroupons les transactions qui accèdent aux mêmes classes d’accès et les envoyons

pour exécution via une chaîne avec un ordonnancement strict. Cette méthode permet de ré-

duire significativement le temps de réponse puisqu’un ensemble de transactions est envoyé

pour exécution en un seul coup tout en garantissant la cohérence et en réduisant fortement

le nombre d ’accès à la couche stockage. Pour ce faire, notre ordonnanceur utilise plusieurs

stratégies pour chaîner les transactions en se basant sur leur classe d’accès.

Les différentes contributions de cette thèse ont fait l’objet de plusieurs publications : [GSN12],

[GSN14a], [GSN14b], [GSNJ15], [SNI15], [GNS15] et [SNB+15].

Remarque 1.1 (Tolérance aux pannes). La tolérance aux pannes est l’habilité d’un système à

continuer à fonctionner, éventuellement de manière réduite, en cas de pannes ou d’indisponibi-

lité de certaines de ses composantes. C’est une fonction essentielle pour un système distribué.

Cependant, nous ne la traitons pas explicitement dans cette thèse. Elle sera abordée dans les

perspectives de cette thèse.

1.5 Organisation du manuscrit

La suite de ce manuscrit est structurée en six chapitres.

– Dans le chapitre 2, nous présentons les travaux connexes aux nôtres. Il s’agit des méthodes

existantes pour gérer les transactions dans les bases de données distribuées. Nous étudions les

systèmes partitionnés en privilégiant le type de partitionnement et son impact sur l’optimisa-

tion des quantités de ressources engagées dans le traitement des transactions. Nous y étudions

aussi quelques travaux connexes qui traitent de l’équilibrage des charges.

Introduction 6

– Dans le chapitre 3, nous présentons les définitions des concepts de base utilisés dans ce ma-

nuscrit et décrivons notre architecture dans le détail.

– Dans le chapitre 4, nous présentons le mécanisme de partitionnement et de placement des don-

nées de la base. Nous commençons par expliquer les observations qui ont guidé l’élaboration

de notre mécanisme de partitionnement. Puis, nous décrivons comment ce partitionnement se

fait et comment les données sont placées sur les différents sites.

– Dans le chapitre 5, nous décrivons nos mécanismes de gestion de la charge fluctuante résul-

tante du type d’applications cibles. Nous présentons nos algorithmes permettant de rendre

élastique notre système de gestion des transactions. L’objectif est de borner le temps de ré-

ponse du traitement des transactions et de minimiser les ressources nécessaires.

– Dans le chapitre 6, nous présentons nos différentes propositions sur la gestion des transac-

tions. Plus précisément, nous y présentons les algorithmes de routage, d’ordonnancement et

le modèle d’exécution.

– Dans le chapitre 7, nous présentons la conclusion générale et les perspectives de cette thèse.

Chapitre 2

État de l’art

Dans ce chapitre, nous faisons une revue de la littérature sur les problématiques de recherche

connexes à nos travaux. Il s’agit notamment de la gestion des transactions dans les bases de

données distribués. Cette problématique soulève celui du partitionnement, du placement des

partitions et aussi de l’équilibrage de la charge.

2.1 Le passage à l’échelle dans la gestion des données

La réplication partielle ou totale des données est considérée aujourd’hui comme l’une des meilleures

solutions pour passer à l’échelle et garantir la disponibilité d’un système. Dans cette perspec-

tive, plusieurs travaux ont été proposés. La plupart des travaux pionniers tels que R* [MLO86],

Gamma [DGS+90] et Bubba [BALC+90] se sont concentrés sur comment traiter des opérations

de jointures complexes. Toutefois, la distribution d’une base de données sur de multiples ma-

chines favorise l’occurrence de transactions distribuées (accédant à plusieurs données localisées

sur différents sites). La gestion de cette classe de transactions est un vrai défi qui intéresse les

systèmes de gestion de données proposés ces trois dernières décennies. Il s’est avéré que la

présence de telles transactions, combinée au besoin d’une forte cohérence, constitue un facteur

qui rend très difficile le passage à l’échelle des systèmes de gestion de données [TDW+12].

Les systèmes de stockage clé-valeur tels que ceux présentés dans [DHJ+07, Vog07], Google

Bigtable [CDG+06], Yahoo PNUTS [CRS+08], HBase [AS14] ou MongoDB [Inc14] sont de

plus en plus choisis pour concevoir des systèmes distribués à large échelle. En général, ces sys-

tèmes offrent des opérations sur un espace de clés à l’échelle d’une table (i.e. pas de jointures) et

offrent une cohérence sur une clé seule. Ceci rend plus facile la distribution des opérations et des

données sur plusieurs machines. Toutefois, il existe deux exceptions à savoir Scalaris [TFA08]

qui utilise le protocole de validation Paxos et offre des transactions multi-clé, et Percolator de

Google [PDI00] qui étend Bigtable avec des snapshot isolation.

7

État de l’art 8

La plupart de ces systèmes ont obtenu des gains en termes de débit transactionnel en limitant

la cohérence à de petites unités de données appelées entity-group (une petite collection de don-

nées sollicitées ensemble). Dans des travaux tels que ceux décrits dans G-Store [DAE10] et

[LTP+14], des solutions ont été proposées pour rendre automatique la création de ces entity-

group, et de les élargir à des demandes transactionnelles sur un nombre de partitions plus ou

moins important. L’idée est de permettre un traitement en local via une partition temporaire qui

est en fait l’entity-group. La motivation est de traiter sur un nœud une transaction qui devrait

être exécutée de manière distribuée.

Même si la solution proposée dans G-store est orientée clé-valeur et que celle dans [LTP+14] est

pour des charges de type OLTP, ces deux solutions font du partitionnement dynamique via les

entity-group. L’idée derrière les solutions proposées dans ces travaux est proche de la nôtre. En

effet, nous avons comme objectif d’offrir le passage à l’échelle tout en supportant des opérations

complexes à l’échelle d’un nœud. Nous nous appuyons sur le partitionnement dynamique pour

atteindre notre objectif.

2.2 Le partitionnement des données

Les systèmes qui passent à l’échelle via le partitionnement offrent des garanties ACID 1 en li-

mitant la prise en charge des transactions. Ils partent du fait que la base de données peut être

partitionnée de telle sorte que les données fréquemment sollicitées ensemble par une transaction

soient co-localisées dans la même partition. Ce partitionnement permet d’adapter le placement

des données au pattern d’accès de l’application.

En dépit d’efforts récents pour automatiser le processus du partitionnement [ANY04, PA04,

ZRL+04], un bon partitionnement reste toujours un processus complexe surtout quand il doit

être dynamique. Dans ce cas, il peut y avoir des repartitionnements (partitionnement modi-

fié) en fonction de critères établis. En effet, ce repartitionnement peut avoir un coût élevé du

fait du déplacement des données physiques et son utilisation peut être problématique dans le

cadre d’une charge avec des fluctuations à court terme. Par conséquent, les nœuds doivent être

sur-approvisionnés pour de petites fluctuations, ce qui conduit au gaspillage de ressources de

stockage et de calcul.

2.2.1 Le partitionnement statique

La stratégie du partitionnement statique consiste à produire un partitionnement qui ne change

pas au cours du fonctionnement du système. Autrement dit, les données de la base sont réparties

1. La gestion classique des transactions garantit les propriétés ACID : toutes les opérations d’une transaction sontvalidées ou aucune ne l’est (Atomicité), une transaction trouve la base de données dans un état cohérent et la mène àun autre état cohérent (Cohérence), il n’existe aucune interférence pendant l’exécution de transactions concurrentes(Isolation), et les mise à jour faire par une transaction sont durables (Durabilité).

État de l’art 9

en mode offline (système à l’arrêt). Pour modifier ce partitionnement, il faut arrêter le système

puis modifier le partitionnement des données et l’application avant de remettre le système en

marche.

Plusieurs systèmes ont adopté ce type de partitionnement. Nous pouvons citer, entre autres,

Megastore de Google [BBC+11], Cloud SQL Server [BCD+11] et SQL Azure [MTK+11]

de Microsoft. Ces systèmes utilisent un partitionnement statique et offrent un accès transac-

tionnel sur ces partitions. Plus récemment, nous avons les systèmes présentés dans Relational

Cloud [CER+11] et ElasTraS [DAE13] qui adoptent ce type de partitionnement. Ces derniers

systèmes sont plutôt orientés vers une perspective de base de données multi-tenant 2 [FJR09].

Comme dans notre cas, leur passage à l’échelle est guidé par la charge. Dans Relational Cloud

[CER+11], une approche workload-aware est adoptée. Autrement dit, il identifie les tenants

avec les charges qui peuvent être co-logées sur un serveur de base de données, comme décrit

dans [CJMB11]. Concernant le système ElasTraS [DAE13], une sémantique transactionnelle

restreinte similaire à celle de Sinfonia [AMS+07] est offerte. En plus, ce système s’appuie

sur un partitionnement au niveau schéma (Schema Level Partitionning). Il réalise le passage

à l’échelle à la granularité d’une partition en jouant sur le placement des partitions pour équili-

brer la charge. Dans ElasTraS, les ressources sont ajoutées/supprimées en fonction de la charge

courante et les partitions distribuées sur ces ressources pour offrir un traitement performant.

Le passage à l’échelle est assuré par le fait que les transactions s’exécutent toujours sur une et

une seule partition. En outre, ElasTraS fait une gestion centralisée des métadonnées, sans offrir

d’élasticité à ce niveau, supposant que leur petite taille et la faible fréquence de leur mise à jour

ne peuvent pas constituer un problème pour le passage à l’échelle. Ces deux derniers points sont

les principales différences entre notre système et ElasTraS. En effet, l’hypothèse que les méta-

données ne constituent pas un blocage au passage à l’échelle est fortement dépendante du type

d’application cible. Ainsi, nous avons géré l’élasticité sur la partie métadonnées [GSN12] pour

faciliter le passage à l’échelle global de notre système. Notons par ailleurs que Relational Cloud

et Cloud SQL Server utilisent l’architecture shared-nothing où les données sont stockées sur des

SGBD locaux. Par contre, ElasTraS et Megastore utilisent une architecture où le stockage est dé-

couplé de la logique d’exécution des transactions et les données persistantes sont stockées dans

une abstraction de réseaux de stockage adressable, partagé et tolérant aux pannes. Par ailleurs,

nous avons les systèmes de base de données distribuées en mémoire tels que VoltDB [Vol14] dé-

rivé de H-Store [KKN+08]. VoltDB a une architecture shared-nothing où les différents nœuds

forment un cluster. La base de données est partitionnée de façon disjointe et chaque nœud du

cluster est responsable d’un sous-ensemble de partitions. Un nœud qui stocke une partition en

2. La multi-tenance dans les bases de données signifie le partage de ressources pour différentes petites basesde données (tenants) servant des applications ; ces bases sont gérées par un même SGBD sur une même machine.Par exemple, beaucoup de plateformes Cloud telles que Salesforce.com, Facebook, Google AppEngine, et WindowsAzure hébergent des centaines de milliers de petites applications ; chacune ayant une petite base de données. Avecles bases multi-tenants, chaque tenant est considéré comme une partition et une transaction accède à un et un seultenant à la fois.

État de l’art 10

a l’exclusivité ("owner") jusqu’à ce que ce lien soit rompu. Cette organisation sur une architec-

ture share-nothing passe à l’échelle et simplifie l’implémentation du SGBD [SW85]. VoltDB

est conçu pour un débit transactionnel maximal et une tolérance aux pannes. Ainsi, les choix

suivants ont été faits dans sa conception :

– toutes les données sont stockées en mémoire, ce qui supprime les accès disque lents ;

– toutes les opérations (transactions) qui ont besoin d’être traitées sur la base de données sont

prédéfinies dans un ensemble de procédures stockées qui s’exécutent sur le serveur, i.e. les

transactions ad-hoc ne sont pas permises ;

– les transactions sont exécutées sur chaque partition de la base en série, donc pas de transac-

tions concurrentes sur une partition, ce faisant on élimine le besoin de contrôle de concur-

rence ;

– les partitions sont répliquées pour la durabilité et la tolérance aux pannes.

Il existe d’autres systèmes proches de VoltDB comme Riak [BT14], ou MongoDB [Inc14] qui

passent à l’échelle et sont orientés NoSQL (Not Only SQL). Comme décrit dans les travaux pré-

sentés dans [Hel07], [AAEAD10] et [TD15], le constat est le même : il faut limiter les accès

d’une transaction, autant que possible, à un seul nœud. Cette limitation permet d’éviter les pro-

blèmes liés à la gestion des transactions distribuées 3, contribue fortement à réduire le temps de

latence et simplifie la gestion des accès concurrents.

Toutefois, trouver une bonne stratégie de partitionnement pour bien répartir les données reste un

défi surtout si on se trouve dans un contexte où les applications ont un modèle d’accès qui varie

dans le temps. En réalité, la plupart de ces systèmes cités ci-haut ont été conçus avec l’hypothèse

que le modèle d’accès aux partitions par les applications est statique. Pour des applications dont

le pattern d’accès est dynamique, utiliser un système où les données sont statiquement partition-

nées conduit à des transactions distribuées.

2.2.2 Le partitionnement dynamique

Le partitionnement dynamique consiste à modifier les partitions et leur placement au cours du

fonctionnement du système et suivant certaines conditions. Deux situations peuvent justifier le

besoin d’un partitionnement dynamique :

– le regroupement dynamique des données sollicitées ensemble par une transaction. Ce regrou-

pement dynamique peut se faire à la suite de l’analyse de traces d’exécution et avec l’utilisa-

tion d’algorithmes complexes comme dans [CJZM10] et [AKD13]. Il peut aussi se faire en

exploitant en amont les caractéristiques de la charge applicative comme dans [GSNJ15].

– la restructuration des partitions pour une meilleure répartition de la charge.

3. Les transactions distribuées requièrent un protocole de validation distribuée tel que le 2PC. Ces protocolesnécessitent en général l’utilisation de verrous durant toute la période de validation pour garantir l’isolation. En plus,le protocole de validation requiert plusieurs messages entre les participants. Ces deux facteurs favorisent la limitationdu débit transactionnel, et rallongent la latence. Le temps nécessaire pour exécuter le protocole peut souvent êtreconsidérablement plus grand que le temps nécessaire pour exécuter la transaction en local. [TDW+12]

État de l’art 11

Comme nous l’avons souligné plus haut, l’une des difficultés avec le partitionnement dyna-

mique est le coût qui lui est associé puisqu’il requiert des mouvements de données physiques

entre nœuds. Ceci peut avoir des effets indésirables comme la perturbation des transactions en

cours [SAG06, Val93]. Dans la littérature, plusieurs travaux ont abordé le partitionnement dy-

namique. Nous pouvons citer Schism [CJZM10], Sword [AKD13] et Cumulus [IFS15]. Dans

Sword et Schism, des algorithmes de partitionnement de graphes (hypergraphe dans le cas de

Sword) sont utilisés pour réorganiser dynamiquement les partitions. Leur objectif est réduire le

nombre de transactions distribuées mais aussi d’équilibrer la charge entre les différents nœuds.

L’application d’une charge applicative telle que la nôtre au système Schism le rendrait non per-

formant dans la mesure où les transactions distribuées ne seront pas si souvent évitées puisque

leur stratégie de calcul de replacement des partitions n’est pas rapide et est inappropriée à de

fréquentes variations. Dans Sword, les auteurs ont tenté de réduire ce déficit en proposant un

partitionnement incrémental qui procède à des ajustements dès que le taux de transactions dis-

tribuées devient supérieur à un seuil. Leur critère est le nombre de transactions distribuées et

non le temps de réponse.

Dans Cumulus, une approche de partitionnement dynamique et adaptatif est proposée. Cette ap-

proche identifie les caractéristiques des patterns d’accès depuis les transactions entrantes puis

détermine un nouveau schéma de partitionnement basé sur ces patterns d’accès identifiés. L’ob-

jectif de ce système est de minimiser le nombre de transactions distribuées. C’est une approche

assez similaire à la nôtre avec la différence que nous avons, en plus de l’objectif de réduire la

quantité de transactions distribuées, un objectif de traitement avec un temps de réponse borné.

Dans [CABK88], les auteurs proposent une technique pour partitionner les tables d’une base de

données pour des besoins d’équilibrage de la charge, mais leur méthode n’a pas prévu d’approvi-

sionnement pour le partitionnement dynamique ou une estimation du coût de ce partitionnement.

Dans [BLS95], les auteurs proposent des stratégies simples pour du partitionnement dynamique

de données pour des charges changeantes dans un système de base de données partitionnés mais

non répliquée. Leur but est de maximiser les accès locaux pour chaque nœud. Leur stratégie

garde un compteur des blocs de bases de données sollicités par différents nœuds et essaie le

repartitionnement pour maximiser les accès locaux sur chaque nœud. La technique proposée a

été testée seulement sur un système de deux nœuds, en assumant que la charge ne change pas

rapidement. Enfin, dans [RVVN90], les auteurs proposent des stratégies d’ordonnancement pour

minimiser le temps nécessaire pour le transfert des données durant le repartitionnement et pour

minimiser l’impact sur les transactions.

État de l’art 12

2.3 Le placement des données

Le problème du placement est de trouver une manière efficace d’allouer les différents fragments

aux sites disponibles de sorte que les performances soient améliorées (latence et débit transac-

tionnel). Il a été montré que le problème général du placement des fragments est NP-Complet

[SW85]. La recherche dans ce domaine a conduit à la production de différents algorithmes et

heuristiques [HI12, TH08, HIMF08, Chu69].

Dans [Min13], le problème du placement est formulé comme un programme mixed-integer

(MIP), avec un objectif de minimiser les coûts en nombre de serveurs via l’élasticité (passage

à l’échelle élastique). Dans cette thèse [Min13], l’auteur veut avoir une solution exacte au lieu

de s’appuyer sur des heuristiques. Ainsi, son objectif n’est pas de proposer une nouvelle heuris-

tique pour résoudre ce problème de placement (NP-complet), mais plutôt, il utilise un solveur

d’ordre général pour trouver une solution exacte. Plusieurs éléments sont en général pris en

compte dans les méthodes d’allocation ou de placement des fragments sur les différents sites

disponibles. Ces critères sont principalement influencés par la méthode de fragmentation utili-

sée lorsque les transactions sont susceptibles d’accéder à plusieurs sites. Ces critères peuvent

être le nombre de copies de chaque fragment, le modèle d’accès aux données, le coût des com-

munications inter-sites, le coût du traitement local et le coût du stockage.

Dans le contexte de notre travail, le placement des partitions est guidé par deux objectifs : (i)

garantir une prise en charge locale des transactions selon une contrainte temporelle et (ii) éviter

les transactions accédant à plusieurs sites. Chaque nœud de notre couche de stockage (voir sec-

tion 3.3) a un SGBD local qui gère les partitions placées sur le nœud. C’est-à-dire que chaque

nœud de cette couche peut gérer plusieurs partitions selon sa charge courante et ses capacités de

traitement. A un instant donné, chaque partition de notre base de données sera localisée sur un

nœud et un seul.

Notre stratégie de placement est dynamique et nous partons d’un placement initial quelconque

des données qui est amélioré au fur et à mesure du fonctionnement du système. Les conditions

de modification seront soit un besoin d’éviter une transaction distribuée, soit un besoin de répar-

tition de la charge entre des noeuds, soit un besoin de consolidation des partitions. Concernant

le cas précis de la réduction des transactions distribuées, nous observons que la plupart 4 des tra-

vaux dans la littérature partent du principe que les variations de la charge et du pattern d’accès ne

sont pas très fréquentes. Il s’agit en général d’un processus d’observation et/ou d’apprentissage

qui exploite les traces d’exécution de la charge applicative pour ensuite décider du placement.

Par exemple Schism [CJZM10] et Sword [AKD13] (que nous avons présentés plus haut), RTP

[SJK+13] et Delphi/Pythia [ASA+13].

Dans les travaux présentés dans RTP [SJK+13], les auteurs proposent de résoudre le problème

d’un placement optimal des tenants afin de maintenir un niveau de temps de réponse tout en

4. à notre connaissance et à la date de la rédaction de cette thèse.

État de l’art 13

optimisant le nombre de nœuds du système. Ils travaillent dans un contexte de bases de données

en mémoire et de type lecture intensive. Ils ne traitent pas les problèmes de transactions à accès

multiples. Toujours dans cette dynamique de maintenir des temps de réponse à niveaux détermi-

nés, nous avons les travaux décrits dans Delphi [ASA+13] où les auteurs proposent un système

autonome de contrôle pour une base de données multi-tenants. Delphi permet de détecter les

dégradations de performances conduisant à un non respect des SLO (Service Level Objectives).

Ces dégradations sont dues à des pics de charge sur certains tenants de la base. Delphi s’appuie

sur Pythia [ASA+13] qui est une technique d’apprentissage des modèles de charge des tenants

qui propose des placements conduisant à un retour à la normal des charges sur chaque serveur.

Dans une perspective d’équilibrage de la charge, nous avons les travaux décrits dans SCADS

Director [TBF+11]. Dans ces travaux, les auteurs abordent le problème du placement des par-

titions dans un contexte de système de stockage clé-valeur simple. Il utilise une heuristique

gloutonne comme cela se fait dans ElasTras[DAE13] pour leurs décisions de placement. Ces

deux systèmes ne prennent pas en charge le traitement des transactions accédant à de multiples

partitions (transactions multi-partition). Notre stratégie de placement de partitions peut prendre

en charge les applications dans lesquelles une transaction accède à une et une seule partition et

celles autorisant des accès à de multiples partitions. Il utilise un modèle de performances couplé

avec les statistiques sur la charge applicative pour prédire si chaque serveur de données est dans

les conditions d’utilisation lui permettant de respecter les SLO (Service Level Objectives) ou

pas. Se basant sur ce modèle, des réplications ou des déplacements de partitions sont faits. Plus

récemment, nous avons Acordion [SMA+14] qui est un système de placement dynamique des

données pour des SGBD partitionnés qui prennent en charge les transactions ACID (locales ou

distribuées). Dans Acordion, un placement dynamique est effectué en considérant explicitement

l’affinité entre partitions. Cette affinité indique la fréquence avec laquelle des partitions sont

sollicitées par la même transaction. La capacité d’un serveur est estimée en considérant l’im-

pact des transactions distribuées et de l’affinité sur le débit transactionnel maximal du serveur.

Acordion est destiné aux systèmes de base données en mémoire, où les transactions distribuées

représentent une source de surcharge majeure [LKF+13], [PCZ12].

Toutefois, l’atténuation du coût du traitement des transactions distribuées est aussi un problème

important pour les systèmes orientés disque. Des travaux récents comme par exemple Calvin

[TDW+12] et les transactions RAMP [BFH+14] en attestent. La coordination de l’exécution

d’une même transaction entre plusieurs partitions peut mener à des attentes (e.g. dans le cas de

verrouillage distribué) ou des annulations de transactions (e.g. dans le cas de contrôle de concur-

rence optimiste). Dans tous les cas, le débit transactionnel du serveur peut être borné non pas par

son CPU, ni les entrées/sorties, ni les capacités du réseau mais plutôt par le coût supplémentaire

provoqué par la coordination des transactions.

État de l’art 14

2.4 La consolidation ou l’optimisation du placement

La consolidation du système consiste à mettre ensemble le maximum de partitions de la base de

données sur un même serveur pour minimiser les ressources au mieux tout en favorisant l’accès

local à un site. Ces dernières années, la consolidation a été particulièrement mise en œuvre dans

le contexte de la multi-tenance.

Les fournisseurs de SaaS (Software-as-a-Service) avec le Cloud font appel à la multi-tenance. Il

s’agit de faire tourner plusieurs instance de la même application, accessible sur le web, pour de

multiples clients. A chaque client correspondra une instance de l’application. Chaque instance

est appelée un tenant. Les données de chaque tenant sont isolées et restent invisibles aux autres

tenants mais toutes les données sont gérées par le même système de base de données.

La problématique générale de la consolidation des partitions est assez proche de celle de la

consolidation des tenants. Il s’agit d’améliorer le regroupement de plusieurs tenants sur un seul

serveur de base de données (base de données multi-tenant) et de gérer des charges applica-

tives mixtes dans ce contexte [BCD+92], [Hea14], [JA07], [AGJ+08], [HJLZ09]. Les avancées

notées dans ce domaines ont permis le développement de stratégies de consolidation des te-

nants pour ces bases de données dites multi-tenant. La consolidation dans un tel contexte vise

à optimiser l’utilisation des ressources matérielles et se fait en tenant compte des capacités des

serveurs utilisés et des charges courantes des tenants [CJMB11, DAE13, SJK+13]. Un pro-

blème important à résoudre pendant la consolidation est d’assurer la continuité du service. En

effet, cette consolidation passe par le déplacement des données d’un serveur à l’autre et doit se

faire sans interrompre le service. Il s’agit de migrer les données et les processus transactionnels

associés, on parle de "déplacement en temps réel" ((live migration en anglais). Plus générale-

ment, la consolidation est très utilisée dans les environnements virtualisés. Dans ce contexte,

les machines virtuelles (VM) tournent sur différentes machines physiques. Leur consolidation

répond à des besoins d’optimisation du coût de l’opération via une utilisation efficiente des ma-

chines physiques disponibles. La consolidation des bases de données en utilisant des machines

virtuelles (VM) est considérée comme un moyen pour réduire les coûts opérationnels de ces

dernières [jon14]. Dans [SMA+10], les auteurs ont travaillé sur la configuration de multiples

VM tournant sur la même machine physique pour gérer de multiples charges applicatives . Leur

travail est adapté à la gestion d’un petit nombre de charges applicatives et non à un contexte

plus large échelle et plus dynamique. Dans la même lancée, dans [SLG+09] les auteurs pré-

sentent un système pour déterminer comment partitionner les ressources de VM entre toutes

les machines virtuelles sur une seule machine physique . Leurs travaux sont complémentaires

aux nôtres mais sont plutôt orientés côté infrastructure tandis que nos travaux sont orientés sur

l’aspect gestion des données. Par ailleurs, les différentes propositions dans [SLG+09] peuvent

être utilisées pour optimiser les techniques de placement proposées dans nos travaux. Dans cette

thèse, nous utilisons une technique de consolidation qui tente d’utiliser au mieux les ressources

État de l’art 15

physiques disponibles. Nous regroupons les partitions sur un minimum de machines physiques

mais en tenant compte des liens entre ces partitions (pour les transactions distribuées) et aussi

en tenant compte de la charge des machines et des partitions.

2.5 Autres stratégies de passage à l’échelle

Il existe des travaux qui cherchent à offrir un passage à l’échelle pour des systèmes qui ne

requièrent pas que la base de données soit partitionnée en fonction des patterns d’accès. Par

conséquent, les transactions distribuées sont souvent inévitables. Dans ces travaux, les auteurs

proposent diverses stratégies pour une gestion des transactions qui passe à l’échelle. Dans ecS-

tore [VCO10], les auteurs proposent un système de stockage élastique sur le Cloud, qui vient

avec un mécanisme de partitionnement et de réplication automatique des données tout en per-

mettant des accès transactionnels. Dans ecStore, les données sont distribuées et répliquées sur

un cluster. Les accès transactionnels à de multiples données sont offerts à travers le traitement

de transactions distribuées ; l’accent est mis sur l’atomicité et la durabilité avec un faible ni-

veau d’isolation offert à travers un contrôle de concurrence optimiste multi-version. Le système

Deuteronomy [LLMK11] offre le traitement efficient et à l’échelle des transactions ACID. Pour

y arriver, ce système décompose les fonctions de base de données en une composante transac-

tionnelle (TC) et une composante données (DC). Le TC gère les transactions, le contrôle de

concurrence logique et le recouvrement, mais ne sait rien à propos de la localisation physique

des données. Le DC maintient une cache de données et utilise des méthodes d’accès pour sup-

porter une interface orientée enregistrement avec des opérations atomiques, mais ne sait rien à

propos des transactions. L’idée maîtresse de Deuteronomy est que le TC peut être appliqué sur

des données situées n’importe où (dans le Cloud, en local, etc.) avec des déploiements variés

pour aussi bien les TC que les DC. Puisque les TC et les DC sont complètement découplés,

l’accent est mis sur la conception du protocole interface, un verrouillage efficace et un recouvre-

ment efficace. Hyder [BRD11] est un système qui vise à fournir le passage à l’échelle (scale-out)

sans avoir besoin de partitionner la base de données tout en offrant un débit transactionnel élevé

et une faible latence. Ses auteurs proposent une architecture share-nothing radicalement diffé-

rente des architectures classiques de partage de données [CER+11], [CB03]. Hyder tire profit

des nouveaux progrès dans l’infrastructure matérielle globale dans les data centers : des proces-

seurs plus rapides (multi-cœur très puissants), des réseaux avec plus de bande passante et des

supports de stockage en mémoire offrant des entrée/sorties abondantes (tels que les mémoire

flash). Il est conçu pour tourner sur un cluster de serveurs qui ont un accès partagé sur un large

pool de mémoires de stockage flash adressables en réseau. Les aspects clés dans Hyder sont le

log partagé qui est aussi la base de données, l’utilisation d’un contrôle de concurrence multi-

version optimiste pour le traitement transactionnel, et un algorithme efficient pour la détection

de conflits déterministes pour l’exécution optimiste des transactions. Dans Calvin [TDW+12],

État de l’art 16

les auteurs ont proposé une solution qui reste distribuée mais efficace. Elle s’appuie sur les

principes des bases de données déterministes. Une réplication active cohérente y est effectuée

en exécutant la même transaction sur les tous les sites abritant une copie de la partition ciblée.

Cette exécution est précédée par des opérations de lectures distantes qui pourvoient à chaque site

la partie qui lui manque et qui provient des autres sites afin qu’il puisse exécuter la transaction.

La couche de réplication dans Calvin utilise une garantie déterministe sur l’ordonnancement des

transactions pour réduire considérablement la contention associée aux transactions distribuées.

Il permet aussi d’apporter à une base de données non transactionnelle un support transactionnel

en respectant les garanties ACID. Calvin est conçu pour servir de couche transactionnelle qui

passe à l’échelle au dessus de n’importe quel système de stockage ; aussi bien ceux qui offrent les

fonctions basiques de création, lecture, modification ou suppression (CRUD), que ceux NoSQL

ou à clé-valeur. Ces systèmes - Deuteronomy, Hyder, ou Calvin - offrent des solutions très per-

tinentes et performantes pour la prise en charge de transactions dans un système de gestion de

données distribuées. Leurs auteurs se sont surtout focalisés sur les aspects débit transactionnel

et passage à l’échelle, mais contrairement à nous ils ne cherchent pas à minimiser les ressources

du système (stockage, et calcul). Par ailleurs, dans [PCZ12] les auteurs présentent une nouvelle

approche de partitionnement automatique pour les systèmes OLTP. Leur approche permet de

minimiser le nombre de transactions distribuées tout en minimisant les effets des différences

des fréquences d’accès dues aux horaires, aussi bien pour la distribution des données que pour

l’accès. Pour ce faire, les auteurs utilisent un modèle analytique de coût qui peut être utilisé

rapidement pour estimer le coût de coordination d’une transaction et les variations (temporelles)

pour une charge donnée, un schéma de base de données candidate donné et une exploration d’un

grand espace de solution basée sur une recherche large dans le voisinage. Comme pour Calvin,

notre différence avec [PCZ12] se situe dans le fait que nous faisons un partitionnement et un

placement dynamique pour amener les transactions à accéder à un seul site.

Le passage à l’échelle a aussi été étudié dans le contexte des systèmes pair-à-pair (P2P). Les

applications P2P sont distribuées et coopèrent, d’égale à égale, pour exécuter les tâches d’un

traitement distribué. C’est un modèle différent et plus général que celui offert dans le paradigme

Client-Serveur (C/S). Mais les caractéristiques des systèmes P2P ont créé de nouveaux défis.

Premièrement, la nature dynamique et autonome des pairs fait qu’il est très difficile de don-

ner des garanties sur la complétude des résultats et/ou de faire de l’optimisation de requêtes.

Deuxièmement, les technique de gestion des données ont besoin de passer à l’échelle sur de

grands nombres de pairs. Troisièmement, le manque de contrôle central rend très difficile la

gestion d’un schéma global et le contrôle d’accès. Enfin, même dans le cas de l’utilisation de

la réplication, il est difficile d’assurer la tolérance aux pannes et la disponibilité en présence

de pairs instables. Ces défis ont fait l’objet de beaucoup de travaux parmi lesquels nous avons

[VP05, OST03, HHL+03, NSS03, TIM+03, ABC+03, CMH+02, ACMD+03, SNG10].

Dans PeerDB [OST03], en considérant un réseau pair-à-pair non structuré, le mapping de schéma

État de l’art 17

est fait à la volée pendant le traitement de la requête en utilisant des techniques de recherche

d’informations. Même si elle est flexible, cette approche limite l’expressivité des requêtes à la

recherche de mots clés. En plus, le routage des requêtes s’appuie souvent sur la diffusion qui

peut être inefficace. Dans PIER [HHL+03], un réseaux pair-à-pair structuré (DHT), l’accent

est mis sur le passage à l’échelle dans le traitement des requêtes sur une très large configura-

tion en supposant qu’un schéma standard existe. Toutefois, seule la correspondance exacte et

les requêtes avec équijointure sont supportées. Dans Edutella [NSS03], un système hybride, les

descriptions de schéma basées RDF sont données par les super pairs 5. Ainsi, des requêtes SQL

peuvent être faites par les super pairs en utilisant des techniques de base de données distribuées.

Piazza [TIM+03] est une solution plus générale, indépendante du réseau, pour la gestion du

schéma. Des algorithmes sont proposés pour reformuler une requête en Xquery sur le schéma

d’un pair dans de nouvelles requêtes équivalentes sur les schémas d’autres pairs. ActiveXML

[ABC+03] est un système P2P général basé sur des documents XML actifs, c’est-à-dire des

documents XML avec des appels de services web en XQuery. Le traitement de requêtes dans

ActiveXML s’appuie sur un modèle de coût qui aide dans l’évaluation de requêtes distribuées et

à décider quelles donnée et quel service répliquer.

TransPeer [SNG10] (Transaction on Peer to peer) est un système de gestion de transactions sur

des bases de données répliquées et distribuées. Il utilise un réseau de nœuds qui assurent le

routage et l’exécution des transactions. Ces nœuds ont un modèle de communication basé sur

un système P2P en l’occurrence FreePastry [Fre14]. TransPeer gère également la tolérance aux

pannes des nœuds pour assurer une disponibilité des données.

La réplication de données en présence de mises à jour est un problème ouvert abordé plus géné-

ralement dans certains travaux tels que Freenet [CMH+02], ActiveXML [ABC+03] et P-Grid

[ACMD+03].

En définitive, les systèmes pair-à-pair permettent de gérer une grande masse de données avec une

importante charge applicative. Toutefois, la problématique de la consolidation des ressources

n’est pas abordée dans les travaux relatifs portant sur ces systèmes. En plus, l’autonomie des

nœuds pose souvent problème pour une gestion des données qui passe l’échelle et une garantie

de la disponibilité.

2.6 La migration des données en temps réel

L’objectif de partitionnement et de placement dynamique est d’adapter les changements de la

charge (demandes) à la configuration du système. Les systèmes distribués qui tournent sur de

5. Un super pair est un pair leader d’un groupe de pairs. On le retrouve dans une configuration hiérarchique oùles nœuds (pairs) sont organisés en groupes et que chaque groupe a un leader. Les leader sont structurés dans unréseau qui aussi pair-à-pair.

État de l’art 18

larges Datacenter peuvent, en théorie, ajouter et supprimer des ressources de façon dynamique-

ment en fonction des besoins. Toutefois, il est difficile de rendre des bases de données élastiques

(passage à l’échelle selon la charge : augmentation ou diminution du nombre de noeuds qui

composent de la base). De façon traditionnelle, cela requiert qu’on mette à jour le matériel et un

déplacement des données pendant les fenêtres de maintenance, ce qui met la base de données

hors service. Cette interruption du service est inacceptable dans les application de nos jours où

le service est censé être disponible continuellement.

Offrir l’élasticité pour des applications sans état est relativement simple, mais c’est beaucoup

plus compliqué pour des applications avec état, telles que les bases de données. Ceci est dû au

fait que d’importantes quantités de données doivent être transférées d’une machine à une autre.

Ce transfert de données peut causer une surcharge à la source et peut prendre du temps. Le pire

c’est que cette surcharge arrive au moment où la machine source a besoin d’être déchargée.

Le stop-and-copy, la copie itérative, ou encore la copie à la demande sont des approches de mi-

gration qui ont toutes été étudiées pour la migration de processus [MDP+00]. Ces techniques,

traditionnellement utilisées dans les environnement composés de machines virtuelles, ne sont

pas adaptées aux bases de données.

Les critères clés d’une migration efficace pour un système de base de données sont :

– une surcharge faible ou inexistante pour faciliter les mouvements de données provenant de

machines déjà fortement chargées et ainsi réduire l’intensité des pics de charge sans accroître

la charge actuelle de la machine ;

– une migration partielle qui déplace seulement les portions de données nécessaires vers une

autre machine. Ceci permet ainsi d’optimiser la distribution des données à la volée et parti-

tionner la charge d’une machine sur plusieurs machines.

Plus récemment, les solutions Wildebeest [Jon12], Zephyr [ASDA11] et Albatross [DNAE11]

sont proposées pour faire du déplacement en temps réel dans les bases de données. Ces solutions

proposent l’implémentation d’une stratégie de migration en temps réel de partitions (parfois

appelées cellules ou tenant, ou encore portions) de bases de données et les processus associés.

Zephyr [ASDA11] une technique de migration d’une partition de la base (appelée tenant ou

cellule) dans une architecture de bases de données share-nothing, sans interruption du service.

Zephyr utilise un mode dual synchronisé où à la fois les nœuds source et destination exécutent

de façon concurrente les transactions sur la cellule en migration. Le nœud source complète

l’exécution des transactions qui ont démarré au début de la migration, tandis que la destination

exécute de nouvelles transactions. Comme première étape de la migration, Zephyr copie de la

source vers la destination, les métadonnées (et toutes les informations sur les schémas et index)

nécessaires à la destination pour commencer à traiter les transactions. A ce stade, les données

stockées sur la cellule ne sont pas copiées. Pour des bases de données utilisant des arbres B+,

seuls les nœuds internes sont inclus dans les métadonnées copiées, les nœuds feuilles contenant

les données sont remplacées sur la destination par des sentinelles. Une fois que les métadonnées

sont installées, la destination commence à exécuter les nouvelles transactions pendant que la

État de l’art 19

source continue à traiter les transactions qui ont démarré au début de la migration. Les pages

(structure de stockage des données) de la base de données sont récupérées à la volée sur la

destination à chaque fois qu’une transaction les sollicite. Une transaction peut être annulée sur

la source quand elle accède à une page déjà migrée. Quand une transaction sur la source se

termine, la migration se poursuit avec le transfert des pages concernées par cette transaction.

Albatross [DNAE11] est une autre technique de migration de cellules dans une architecture

avec stockage partagé. Albatross permet une migration sans aucune annulation de transaction

et un impact minimal sur la performance. Dans une architecture avec stockage partagé, l’image

persistante d’une cellule n’a pas besoin de migration. Albatross se concentre sur la migration

du cache de l’état des transactions actives. Dans Albatross, la source prend un snapshot du

cache d’une cellule et la destination initialise un cache à partir de ce snapshot. Pendant que

la destination continue d’initialiser son cache, la source continue l’exécution des transactions.

Par conséquent, la destination accuse une légère obsolescence par rapport à la source. Albatross

utilise une phase itérative pendant laquelle les changements faits sur le cache du nœud source

sont copiés de manière itérative sur la destination. Quand le nombre maximum d’itérations est

atteint, alors les transactions sont bloquées à la source et un Hanover atomique est fait pour

compléter la migration. L’état des transactions actives est copié dans la phase finale du Hanover

pour leur permettre de s’exécuter sur la destination qui aura déjà un cache à jour. Dans notre

thèse, la migration sert à déplacer des données entre deux noeuds (ou plus simplement entre

deux partitions). C’est une primitive assez générique qui peut servir dans diverses opérations

telles que l’éclatement d’une partition existante en deux ou plusieurs nouvelles partitions, la

fusion de deux partitions en une seule, ou encore l’équilibrage de charge entre deux partitions.

La migration est une opération déclenchée par une entité chargée de la surveillance du niveau de

charge des noeuds. Une fois l’ordre de la migration donné, la coordination de l’opération sera

assurée entre trois entités : le noeud source, le noeud destinataire et un noeud routeur qui gère

la partie des métadonnées concernées. Notre approche assez proche de Wildebeest présentée

dans [Jon12]. Il s’agit d’une migration partielle qui ne déplace que les données nécessaires.

Dans Wildebeest, la phase proprement dite de migration (déplacement effectif des données) est

précédée par une mise à jour des index sur les machines source et destinataire. La différence

avec notre solution est que nous avons des index sur la couche de routage et par conséquent

leur mise à jour est plus simple et n’entraîne aucune charge supplémentaire sur les machines

destinataire et source de la migration.

2.7 Équilibrage de charge

Notre politique d’optimisation des ressources s’appuie sur un mécanisme d’équilibrage de charge.

L’équilibrage de charge permet de tendre vers une utilisation efficiente des ressources dispo-

nibles. Une nouvelle machine est ajoutée au système que s’il n’y a plus de place dans les autres

État de l’art 20

machines en fonction. L’objectif d’une utilisation efficiente des ressources via l’équilibrage de

charges a fait l’objet de plusieurs travaux parmi lesquels nous avons [HL90, NMB11, LXK+11,

MKC11, NC12, JN12, YHJ11, GJP11, VCO10]. Il s’agit, en général, d’une distribution dyna-

mique de la charge parmi tous les nœuds du système. Cette distribution se fait de telle sorte que

les points de contention sont évités au maximum possible.

Dans l’article [MKC11], les auteurs proposent une nouvelle politique d’équilibrage de charge

sensible au contenu, appelée Workload and Client Aware Policy (WASP). Ils ont utilisé une

propriété unique et spéciale (USP) pour caractériser les requêtes tout autant que les nœuds de

traitement. La propriété USP aide l’ordonnanceur dans le choix du meilleur(le plus approprié)

nœud pour le traitement d’une requête. Cette stratégie est implémentée d’une manière décen-

tralisée et réduit le temps passé à l’état idle des noeuds de traitement. Les travaux menés dans

[CFH+05] proposent une politique d’équilibrage de charge pour les serveurs web largement

distribués. Les temps de réponse du service sont réduits en utilisant un protocole qui limite les

redirections des requêtes aux serveurs distants les plus proches sans les surcharger. Notre al-

gorithme d’équilibrage de charge agit presque de la même manière que ceux cités ci-hauts en

tentant de réduire le temps de réponse, c’est-à-dire une charge est transférée de A à B afin de

réduire le temps de réponse sur A s’il est surchargé. Cependant, notre approche vise à minimiser

les ressources tout en assurant l’élasticité et elle est basée sur l’état global du système : un noeud

est choisi pour recevoir un surplus de charge d’un autre noeud en fonction de sa charge locale

et non de sa proximité ou la propriété d’un client. Par ailleurs, il existe d’autres travaux de re-

cherche pertinents axés sur l’allocation dynamique de ressources dans les data-centers [CGS03],

[NBAM05], [USC+08]. Ces travaux partagent certains de nos objectifs mais leur but principal

est de consolider les charges applicatives web sans état et imprévisibles. Les auteurs mettent

l’accent sur la réponse aux changements de la charge et une garantie sur la latence. Ces travaux

combinent des modèles prédictifs sophistiqués et des composants réactifs dynamiques. Mais ils

ne considèrent pas les problèmes liés à la migration et à la consolidation des services orientés

données telles que les bases de données.

D’autres travaux, et dans une perspective d’optimisation du temps de réponse et du débit tran-

sactionnel, ont abordé le problème de l’allocation des données aux serveurs [G.88],[SMR00].

Ces travaux ont des objectifs différents aux nôtres, puisque leur but est d’obtenir une perfor-

mance et le passage à l’échelle pour un nombre fixe de machines, plutôt que de les consolider,

quand cela est possible, sur un nombre minimal de nœuds physiques tout en atteignant les perfor-

mances voulues. De façon similaire, Aboulnaga et al. ont abordé le problème de "l’emballage"

(packing) des tâches map-reduce sur un cluster de machines, mais la nature orientée batch du

problème le rend significativement différent du nôtre. Leurs travaux ont conduit à des solutions

orientées ordonnancement (scheduling) [AWZ09].

Chapitre 3

Concepts de Base et Architectureglobale du Système

Dans cette section, nous définissons les notions et concepts sur lesquels se basent nos diffé-

rentes propositions. Nous y détaillons aussi les différentes composantes de notre architecture et

expliquons leur rôle.

3.1 Notions d’application Web 2.0

Définition 3.1. Définir le Web 2.0 est un exercice pas facile qu’ il n’y a pas une définition

établie et unanime. Toutefois, une application web 2.0 a un ensemble de caractéristiques qui le

distingue des autres types d’applications. Parmi ces caractéristiques nous pouvons citer :

– l’utilisation du réseau internet comme une plateforme,

– le fait de permettre les utilisateurs d’ajouter et de contrôler leur propre contenu ;

– les utilisateurs ont la possibilité d’interagir et de s’organiser en communautés via des relations

d’amitié, de collaboration ou plus généralement d’intérêts communs. Ce critère spécifique

concerne le cas des médias sociaux ;

– les applications web 2.0 peuvent interagir avec d’autres applications via des navigateurs ; cette

caractéristique leur confère le rôle de pépinières d’applications.

3.1.1 Défis des application web 2.0

Les types d’applications Web 2.0 sont nombreux, par exemple, web blogging, wikis, réseaux

sociaux, podcasts, flux, etc. Pour tous ces exemples d’applications, le défi majeur consiste à dé-

livrer le service attendu par l’utilisateur et assurer sa satisfaction en termes de fonctionnalités et

21

Concepts de Base et Architecture globale du Système 22

de temps de réponse. Généralement, les applications web 2.0 cherchent à attirer le maximum de

visiteurs puis de les convertir en utilisateurs relativement assidus ou clients. Pour atteindre cet

objectif, les applications web 2.0 doivent séduire les visiteurs en satisfaisant les exigences des

visiteurs qui sont, entre autres, une haute disponibilité, une forte réactivité ou la fluidité dans

l’utilisation (temps de réponse faible). Aujourd’hui, l’environnement web 2.0 offre des moyens

pour atteindre ces objectifs, qui soulèvent de nouveaux problèmes. En effet, le nombre d’uti-

lisateurs est très important et dépasse facilement une centaine de millions. Tel est le cas pour

Facebook, Twitter, Google+, eBay ou MySpace. Ce nombre important d’utilisateurs engendre

une grande masse de données à gérer. De plus, les utilisateurs interagissent à longueur de jour-

née entrainant ainsi une arrivée incessante de données. La charge transactionnelle associée à

ces données est très élevée et fluctuante. Pour arriver à bien gérer ces données et contenir la

charge applicative associée, le partitionnement et la réplication des données sont souvent uti-

lisées. Toutefois, ces applications ont des modèles de charge variables [APBC13] et la plupart

des partitions demeurent froides (très rarement sollicitées) la plupart du temps. Il convient alors

de trouver un mécanisme efficace de partitionnement et de réplication pour absorber les pics de

cette charge et un placement qui tient compte des données froides.

3.1.2 Structure des interactions

Définition 3.2 (Interaction). Une interaction est définie comme une action qui lie deux ou plu-

sieurs utilisateurs. Par exemple, un utilisateur publie un contenu et un de ses contacts réagit à

cette publication. L’interaction se traduit par une transaction sur les données appartenant aux

utilisateurs impliqués.

Les utilisateurs interagissent avec ceux avec lesquels ils sont en relation (amitié, collaboration,

etc.). Un groupe d’utilisateurs qui interagissent fréquemment ensemble constitue un réseau d’in-

teractions ou communauté [New04, For10] ou encore cercle comme dans Google+. Ces réseaux

d’interactions entre utilisateurs forment la structure de ce qu’il est convenu d’appeler le graphe

social (voir la figure 3.1). Les sommets de ce graphe sont représentés ici par les utilisateurs et il

existe un lien entre deux sommets si une occurrence d’une transaction fait intervenir ou concerne

ces deux sommets. Ces liens sont datés, et la date représente la dernière fois qu’une interaction

entre les sommets concernés a eu lieu. Pour les sommets, un utilisateur est confondu avec l’en-

semble de ses données. En effet, chaque utilisateur a ses données qui sont estampillées de son

identifiant. Par exemple, le sommet User_23 correspond à l’utilisateur d’identifiant User_23, ou

à l’ensemble des données estampillées de cet identifiant. Nous représentons ce graphe social par

un ensemble de triplets de la forme [pi, pj , It] qui représente respectivement le sommet (pi), le

sommet (pj) et la date de l’occurrence d’interaction It.

Comme montré sur la Figure 3.1, les interactions ont lieu dans les communautés (ensemble de

Concepts de Base et Architecture globale du Système 23

FIGURE 3.1: Exemple de graphe d’interactions

sommets de même couleur). Dans ces communautés, les utilisateurs se focalisent sur une portion

des données par moment et selon leurs intérêts.

3.2 Modèle de transaction et notions de base

Nous considérons une base de données conçue pour le fonctionnement d’une application web

2.0 telle qu’un réseau social. La base est gérée par un SGBD et peut être partitionnée sur n

noeuds (BD) de telle sorte que BDk, 1 <= k <= n, gère la partition pk. Dans notre contexte

d’applications de médias sociaux, la base de données en elle même est une collection de don-

nées d’utilisateurs de l’application. Chaque utilisateur possède un ensemble de données et un

identifiant unique. Par exemple, nous avons les tables Profil (PL), Message (MS), Contact (CT),

Historique(HT), Post(PB) et Autres (AR). En plus d’autres champs consacrés au contenu des

enregistrements, chacune de ces tables possède un champ iduser qui est une référence vers un

champs du même nom sur la table Profil, et qui permet de dire à quel utilisateur appartient un

enregistrement.

Ainsi, les tables MS, CT, HT, PB et AR sont partitionnables suivant leur liens avec la table PL.

Plus précisément, une partition de la base contiendra un ensemble d’utilisateurs, c’est-à-dire

une partie de la table Profil, et l’ensemble des enregistrements correspondants dans les autres

tables MS, CT, HT, PB et AR. Nous considérons que les nœuds BD ont des contenus disjoints,

c’est-à-dire qu’une partition pi est présente sur un et un seul noeud BD à un instant donné. Cette

présence d’une partition sur un noeud BD est renseignée par une structure que nous appelons

indexe global.

Définition 3.3 (Transaction). Nous définissons une transaction comme la matérialisation d’une

interaction. C’est-à-dire son implication au niveau des données d’utilisateurs. Par exemple, si

nous prenons le cas de la réaction d’un utilisateur à la publication d’un de ses contacts, cela peut

se présenter comme suit :

Concepts de Base et Architecture globale du Système 24

reaction_pub_contact(ID_user1, ID_user2, post_2-1){

begin_transaction();

update_pub_comm(ID_user2, post_2-1, new_comment, ID_user1,

timestamp);

update_historique(ID_user1, new_comment, ID_user2, post_2-1,

timestamp);

end_transaction();

}

Cette transaction traduit ce que cette réaction produit au niveau des données. Ici, les deux

utilisateurs sont identifiés par IDuser1 et IDuser2, c’est l’utilisateur IDuser2 qui réagit à une

publication de l’utilisateur IDuser1. Cette réaction est matérialisée par l’appel de la fonction

reaction_pub_contac(param1, param2, param2). Cette fonction lance une transaction qui

ajoute la réaction de IDuser2 au contenu de IDuser1 et à l’endroit approprié, et parallèlement, la

même transaction ajoute cette réaction à l’historique de l’utilisateur IDuser2.

Donc, une interaction se traduit par une transaction, qui est une suite d’actions qui sont des

lectures et/ou des écritures sur les données des utilisateurs impliquées.

Définition 3.4 (Charge). La charge est définie comme étant l’impact (en termes de latence) des

transactions en instance de traitement. Quel que soit le niveau (ou la couche) du système où on

se trouve, la charge sera évaluée comme étant la somme des durées d’exécution des transactions

en attente et en cours. Nous nous appuierons sur la Trace pour évaluer cette charge.

Définition 3.5 (Pic de charge). Un pic de charge est la demande maximale reçue sur une période

donnée. Dans notre contexte, les pics de charge sont localisés, c’est-à-dire qu’ils portent sur des

données identifiables et ont une intensité et une durée.

Définition 3.6 (Trace). Soit ω qui représente la plus récente fenêtre d’observation, exprimée

en secondes. Chaque noeud BD garde une structure de données nommée Trace où sont gardées

les transactions qui passent : Tω(pk) indique l’ensemble des transactions qui ont demandé la

partition pk, aussi bien celles qui sont terminées durant ω ou qui ne sont pas encore terminées

(c’est-à-dire, en attente ou en cours d’exécution). Cette Trace permet d’avoir l’information sur

le temps d’exécution courant et d’attente de chaque transaction. Pour quantifier la charge d’une

partition, nous agrégeons ces informations dans la Trace, soit RTω(pk) qui représente la somme

des temps d’exécution et d’attente de toutes les transactions sur Tω(pk).

Définition 3.7 (Cible). Nous appelons Cible la portion des données qui retient l’attention des

utilisateurs du groupe pendant une période de temps. C’est l’ensemble des données concernées

par les interactions d’un groupe. Cette cible évolue au gré des comportements des utilisateurs

du groupe concerné. Puisque les intérêts des utilisateurs changent avec le temps, les interac-

tions aussi changent et impliquent l’évolution des cibles. Ainsi, une cible peut grossir ou se

décomposer et ses parties se retrouvent dans d’autres cibles.

Concepts de Base et Architecture globale du Système 25

Définition 3.8 (Notion de passage à l’échelle). En informatique, le passage à l’échelle horizon-

tal signifie de passer à l’échelle en ajoutant plus de machines dans le pool de ressources. Tandis

que le passage à l’échelle vertical signifie qu’on passe à l’échelle en ajoutant plus de puissance

(CPU, RAM) à une machine existante.

Dans le monde des bases de données, le passage à l’échelle horizontal est souvent basé sur le

partitionnement des données de sorte que chaque noeud contienne seulement une partie des don-

nées. Dans le cas vertical, les données sont stockées sur un seul noeud et le passage à l’échelle

est fait à travers de multiples coeurs, c’est-à-dire une répartition de la charge entre les ressources

CPU et RAM disponibles sur la machine.

Il est plus facile de passer à l’échelle dynamiquement avec la méthode horizontale. La méthode

verticale est limitée par la capacité de la machine, passer à l’échelle au delà de cette capacité

implique des arrêts du système parce qu’il faut arrêter le système, ajouter des ressources et re-

démarrer.

Voilà pourquoi dans nos travaux, nous avons choisi la méthode horizontale pour passer à l’échelle.

3.3 Description de notre architecture

Pour des besoins de passage à l’échelle et de disponibilité, nous avons conçu une architecture

distribuée sur de multiples machines (ou nœuds). Pour ce faire, nous nous appuyons sur les

principes de conception prescrits dans [DAE13, SNA13]. Ces principes ont suggéré et démontré

que la séparation des fonctions de gestion des transactions de celles d’accès aux données permet

d’ajuster séparément le nombre de machines allouées pour chacune de ces fonctions. Et qu’en

outre, l’accès aux données nécessite davantage de ressources que le contrôle des transactions.

Par conséquent, nous avons divisé notre architecture en trois couches comme indiqué sur la

Figure 3.2.

FIGURE 3.2: Architecture Globale : vue en couche

Concepts de Base et Architecture globale du Système 26

3.3.1 Modèle de communication

La structuration des nœuds des différentes couches est variable. Les nœuds qui s’occupent du

routage sont organisés sur un anneau pour simplifier leur communication. C’est le cas des nœuds

de la couche base de données. Par contre, sur la couche de routage il existe une composante qui

s’occupe du suivi des cibles, de la gestion des ressources et de l’équilibrage de la charge (voir fi-

gure 3.3). Ce composant est en dehors de l’anneau structurant les routeurs et de celui des nœuds

de la couche base de données. La communication entre ce composant et les autres nœuds du

système se fait de manière directe en pair-à-pair aussi.

Le type et la structure des messages échangés changent en fonction des types de nœuds qui com-

muniquent. Par exemple, le message permettant de poser une nouvelle transaction est différent

de celui qui permet de donner un ordre de déplacement de données. En plus, Chaque compo-

sant de chaque couche possède autant d’interfaces que nécessaires pour communiquer avec les

autres nœuds des autres couches. Sur les Figures 3.4, 3.5a, 3.5b, 3.5c, nous avons indiqué les

différentes interfaces qui permettent aux nœuds de communiquer les uns avec les autres. Par

exemple, chaque noeud Routeur dispose des interfaces I_CN pour les clients, I_BD pour les

bases de données, I_RM pour le moniteur de ressources, etc.

3.3.2 Architecture détaillée

Le détail des trois couches de notre architecture est montré sur la Figure 3.3. Nous séparons

d’un côté, les fonctions qui contrôlent l’ordonnancement des transactions, le contrôle des res-

sources et le partitionnement, et de l’autre, les fonctions qui accèdent aux données pour exécuter

les transactions. La raison principale est que le découplage de la propriété des données d’avec

leur stockage, permet d’orchestrer plus facilement le placement des données et l’équilibrage de

charge.

FIGURE 3.3: Architecture globale : vue détaillée

Concepts de Base et Architecture globale du Système 27

Couche de stockage. C’est la couche inférieure qui est composée d’un ensemble de nœuds de

type SGBD appelés BD. Un nœud BD (voir figure 3.4) stocke une partie des données. Chaque

BD contient un ensemble de partitions. Le contenu d’un BD est disjoint de celui des autres BD.

Un BD exécute de manière cohérente les transactions qui accèdent aux données qu’il a en charge

et celles en cours de migration. En effet, chaque noeud possède un index local qui lui permet de

marquer, à chaque instant, l’emplacement effectif et l’état des données qui le concernent. Trois

cas de figures peuvent être observés :

1. données déjà sur place ;

2. données qui sont en cours de déplacement d’un autre noeud BD vers lui ;

3. données qui sont en cours de déplacement de lui vers un autre noeud BD.

Autrement dit, un noeud BD contient aussi bien des données qu’il gère, et des données affectées

à un autre noeud BD mais non encore déplacées. L’index permet de différencier ces cas de figure

et permet ainsi de contribuer à rendre cohérent le processus de déplacement en temps réel des

données. Le nombre de BD peut augmenter et diminuer selon l’intensité de la charge globale.

FIGURE 3.4: Vue détaillée d’un noeud BD

Couche de routage. Cette couche est composée de deux grande parties : une partie composée

des noeuds routeur (RN), et une autre partie composée des moniteurs de ressources et de cibles.

Les routeurs garantissent que l’exécution des transactions soit globalement cohérente. En effet,

les routeurs disposent d’une structure que nous appelons index global. Cet index joue le rôle

d’un catalogue qui garde toutes les informations sur la localisation des données.

En outre, un routeur qui reçoit une transaction est désigné coordinateur si jamais un ensemble

de cibles est sollicité par cette transaction. Plus précisément, quand une transaction accède à

des données depuis de multiples BD, le coordinateur a la charge de regrouper toutes les cibles

concernées sur un même nœud BD. La composante moniteur de cibles (BM) est chargée du

suivi des évolutions des cibles ou les changements sur leurs charges. Le BM exploite le graphe

d’interaction pour évaluer la taille et la charge relative d’une cible (voir figure 3.5c). Le moniteur

de ressources (RM) mesure périodiquement la charge des noeuds BD afin de prévoir quand

les capacités d’un BD sont dépassées (voir figure 3.5b). Ce moniteur de ressources fait que la

couche de routage gère, en amont, les pics de charge et ainsi protège la couche de stockage.

Concepts de Base et Architecture globale du Système 28

En fait, il permet de suivre l’évolution de la charge et d’agir suffisamment tôt quand un pic de

charge arrive. Lors du processus de résolution des surcharges, le RM coordonne avec le BM

pour déterminer quelle cible doit être déplacée d’un noeud BD vers un autre avec de plus grande

capacité. Notons que la coordination des transactions multi-cible se fait avec peu de surcharge

pour plusieurs raisons. Premièrement, les transactions qui requièrent plusieurs cibles ne sont pas

très fréquentes et dans de telles cas, la coordination se fait seulement pendant la recomposition

de ces cibles. Deuxièmement, le fait que le moniteur de cibles maintient continuellement le

graphe d’interactions simplifie le travail de coordination.

(A) Vue détaillée d’un noeud RN (B) Vue détaillée du RM

(C) Vue détaillée du BM

FIGURE 3.5: Détails des composantes de la couche de routage

Couche applications. La couche supérieure est composée des applications (CN) qui génèrent

des transactions.

3.3.3 Discussion sur les potentiels points de congestion

L’architecture est décentralisée pour que les transactions indépendantes soient traitées en pa-

rallèle sur des BD distincts. Les fonctions qui contrôlent le déplacement des données restent

centralisées de manière à éviter d’éventuelles contradictions entre plusieurs décisions de dépla-

cement. De même que l’index global sur la localisation des données est partagé. Concernant

l’index, il est de taille relativement petite comparé à la taille des données. Nous utilisons un

format de données qui ressemble à un dictionnaire (sous Redis [Red14]) et simple d’utilisation.

Quand un noeud RN veut localiser une donnée, il pose une opération get(dataID) et reçoit

en retour l’emplacement de la donnée, qui est ici une adresse de noeud BD. Pour marquer le

Concepts de Base et Architecture globale du Système 29

déplacement d’une donnée, une mise à jour de son emplacement est faite sur l’index via l’opéra-

tion set(dataID, new_BD_adr). Ce sont deux opérations très simples et qui s’exécutent très

rapidement avec des systèmes de gestion de données clé-valeur tels que Redis, plus de 1 million

d’opérations (get/set) par seconde sur des données de moins 1 Ko [Redks]. Les chaînes stockant

dataID et lesBD_adr dans notre système sont dans cette ordre de grandeur. Donc cet index ne

posera pas fréquemment de problème d’engorgement. Concernant les fonctions de monitoring

de la charge et de contrôle de déplacement, elles n’empêchent pas le passage à l’échelle dans la

mesure où les déplacements demeurent peu nombreux comparés au volume de transactions trai-

tées (voir chapitre 5). Toutefois, si la taille du système devient trop grande (plusieurs milliers de

noeuds), le module abritant ces fonctions peut être multiplié à volonté. En effet, le système peut

être divisé en autant de parties que nécessaire. Un nombre de routeurs donné, avec un nombre

de nœuds BD donné et auxquels on associe une instance du module de gestion des ressources et

suivi des cibles. Ces différents "fragments du système" peuvent demeurer disjoints ou partager

certaines données, selon le contexte dans lequel nous nous trouvons.

3.4 Conclusion

Dans ce chapitre, nous avons défini les concepts de base utilisés dans notre thèse et les détails

de notre architecture dans le détail. Nous avons d’abord présenté les applications web 2.0 qui

sont les cibles de notre travail. Nous avons aussi présenté le graphe d’interactions social et mon-

tré comment ces interactions conduisent à l’occurrence de transactions. Dans la présentation de

notre architecture, nous avons donné les raisons qui nous ont poussé à faire le choix d’une archi-

tecture décentralisée et à découpler certaines fonctions qui d’habitude étaient logées au mêmes

endroits. Certains choix de notre conception, notamment le caractère centralisé de certains com-

posants, ont naturellement fait l’objet d’une discussion qui nous a permis de donner certaines

garanties sur l’efficacité de ces choix. Dans les prochains chapitres, nous montrons comment les

composantes de notre architecture sont utilisées pour réaliser un traitement des transactions qui

soit efficient et adapté au contexte applicatif auquel nous faisons face.

Chapitre 4

Le partitionnement dynamique et leplacement des données

Passer efficacement à l’échelle dans le traitement des transactions est une exigence importante

pour des bases de données d’applications dont les charges sont fluctuantes. Une solution pos-

sible est de partitionner les données pour paralléliser les traitements. Pour le type de charge que

nous voulons prendre en compte, le défi consiste à trouver une solution de placement dynamique

des données. Plus précisément, le problème peut être formulé comme suit :

Si nous considérons une base données partitionnée en P partitions, la charge de chaque parti-

tion étant connue, et un en ensemble de nœuds avec pour chacun des capacités mémoire et CPU

données. Comment placer les partitions sur un ensemble minimal de nœuds N tel que N ≤ P ,

tout en prenant en compte le caractère transitoire de la charge.

Le nombre minimal de nœuds trouvé doit garantir :

- un équilibrage de la charge : les partitions sont placées parmi lesN noeuds de sorte que chaque

nœud ait au moins une partition et ne soit pas surchargé ;

- une maximisation du débit transactionnel : les transactions sont traitées d’une manière suf-

fisamment rapide pour satisfaire les exigences des utilisateurs. Cela est possible si les entités

chargées de traiter les transactions sont toujours suffisamment libres pour faire le traitement de

nouvelles transactions ;

Nous avons analysé de multiples SGBD qui passent à l’échelle afin de distiller certains principes

de conception pour construire des systèmes qui passent à l’échelle sur des clusters de serveurs

tout en exécutant efficacement les transactions. Dans ce chapitre, nous mettons d’abord en relief

ces principes de conception et puis nous montrons comment se fait notre partitionnement et le

placement des données pour tendre vers le nombre minimal.

30

Le partitionnement dynamique et le placement des données 31

4.1 La problématique du partitionnement

Le partitionnement d’une base de données est l’une des techniques les plus utilisées pour passer

à l’échelle. De façon basique, partitionner une base de données consiste à diviser ses tables. Il

existe plusieurs types de partitionnement :

– le partitionnement horizontal qui consiste à répartir les tuples (ou enregistrements) en plu-

sieurs groupes ;

– le partitionnement vertical qui consiste à diviser chaque tuple pour former plusieurs partitions

dont chacune possède des fragments de chaque tuple ;

– le partitionnement hybride qui est une combinaison des deux précédentes.

Le partitionnement horizontal permet de répartir les données de sorte à avoir des parties dis-

jointes de la base de données. Dans nos travaux, ce type de partitionnement est choisi parce

qu’il permet de pouvoir exécuter les transactions sur des sites distincts.

Les techniques de partitionnement horizontal les plus couramment utilisées sont le partitionne-

ment par intervalle et le partitionnement par hachage.

Le partitionnement par intervalle consiste à diviser les tables en intervalles disjoints de leurs clés

et puis de faire un placement de ces partitions sur un ensemble de nœuds. Dans le partitionne-

ment par hachage, une technique de hachage est utilisée pour placer les partitions.

Ces techniques de partitionnement sont simples et sont compatibles avec la plus part des SGBD

connus. Toutefois, quand elles sont utilisées sans précaution, elles peuvent entraîner l’occur-

rence de transactions réparties qui sont coûteuses. Par conséquent, le passage à l’échelle est

limité du fait du coût des transactions distribuées. Ainsi, notre premier défi est de partitionner

la base de données de telle sorte que la plupart des accès soient locaux. En outre, la gestion

manuelle de larges installations de SGBD avec un grand nombre de partitions pose un problème

d’une importante surcharge administrative. D’abord, le partitionnement en lui même est une

tâche complexe où l’administrateur de base de données doit décider du nombre de partitions à

produire, arrêter le système, partitionner les données et faire le placement, et puis redémarrer le

système. En suite, le partitionnement et le placement des partitions sur les nœuds sont souvent

statiques, et quand les caractéristiques de la charge changent ou qu’un nœud tombe en panne, la

base de données requiert un nouveau partitionnement ou un nouveau schéma de placement des

partitions. Tout ceci augmente la complexité de la gestion de la base et/ou provoque des arrêts

du système. Enfin, le partitionnement est souvent non transparent à l’application (utilisateur) et

dans ce cas, les applications ont besoin d’être informées quand les données sont repartitionnées

ou que le schéma de placement change. Ainsi, notre deuxième défi est de proposer un partition-

nement automatique de la base, qui réduit voire supprime les complexités de gestion liées au

partitionnement, et qui soit transparent à la couche application.

Le partitionnement dynamique et le placement des données 32

4.2 Principes de notre partitionnement

Pour proposer un partitionnement qui répond à nos préoccupations tout en relevant les défis

ci-haut indiqués, nous avons attentivement analysé les systèmes existants. Ainsi, nous avons

ressorti certains principes de conception [AAEAD10] à suivre pour avoir un système qui passe

à l’échelle tout en offrant les spécificités attendues. Ces principes sont au nombre de deux.

4.2.1 La séparation des métadonnées et des données de l’application.

Abstraitement, une base de données distribuée peut être modélisée comme une composition de

deux états différents : l’état du système et l’état de l’application [SNG10, AAEAD10].

L’état du système est composé des métadonnées critiques et nécessaires à sont propre fonc-

tionnement. Il représente aussi l’état des différentes composantes du système qui, collective-

ment, forment le système distribué. Par exemple, nous avons les informations d’appartenance

des nœuds dans un système distribué, le mapping des partitions aux nœuds, et la localisation

des maîtres et répliques dans des systèmes répliqués. Cet état requiert des garanties de cohé-

rence forte, une tolérance aux pannes, et une haute disponibilité pour assurer un fonctionnement

correct du système en cas de différents types de pannes. En général, les métadonnées sont de

petite taille et la fréquence de leurs mises à jour dépend du contexte. Dans notre cas précis, nous

souhaitons pouvoir réaffecter des partitions à des noeuds, ou modifier les partitions au gré des

variations des patterns d’accès aux données et aux fluctuations de la charge. Ainsi, par moment,

les métadonnées sont très sollicitées.

Les données d’application sont stockées sur la couche de stockage. La cohérence, le passage à

l’échelle, et la disponibilité de ces données sont dépendantes des exigences de l’application. Des

systèmes différents offrent des compromis différents parmi les différentes garanties offertes pour

cette couche. Dans notre cas, la quantité de données stockée sur un noeud dépendra à la fois de

la charge actuelle du nœud et des seuils de performances exigées pour ce nœud. Une séparation

propre de ces deux ensembles de données permet d’utiliser différents protocoles, avec diffé-

rentes garanties et les coûts associés, pour maintenir les deux types de données. Par exemple,

les métadonnées peuvent être rendues très disponibles, et tolérantes aux pannes en faisant une

réplication synchrone et en utilisant un protocole distribué tel que Paxos [LAM98] ; tandis que

les données de l’application pourraient être maintenues avec des protocoles moins contraignants

comme dans [IDR10]. Dans nos travaux, nous proposons une solution qui respecte ce principe.

En effet, nous disposons d’une structure que nous appelons index et qui est situé sur la couche

de routage. Cette structure stocke toute l’information sur la répartition et la localisation des don-

nées. Par ailleurs, nous disposons aussi d’une autre structure qui gère les traces des interactions.

Ces deux structures seront sollicitées pour procéder à la création de nouvelles partitions ou à des

opérations (fusion/éclatement) sur des partitions existantes.

Le partitionnement dynamique et le placement des données 33

4.2.2 Limiter les opérations courantes à un seul nœud.

La limitation des tâches fréquemment exécutées à un seul nœud permet une exécution plus ra-

pide des opérations sans avoir besoin de faire des synchronisations distribuées. Cette approche

permet au système de passer à l’échelle horizontalement par un partitionnement horizontal. Il

limite aussi les effets d’une panne aux seules données gérées par la composante en panne. Ainsi,

en présence de ces pannes (isolées), cette approche offre des dégradations graduelles sur les per-

formances. En règle générale, les opérations qui manipulent l’état de l’application (données de la

base) doivent se limiter à un seul nœud sur la couche base de données. Une fois que l’exécution

des transactions est limitée à un seul nœud, les techniques, indiquées dans la littérature des bases

de données relationnelles pour une exécution efficiente des transactions et une optimisation des

performances peuvent être potentiellement appliquées [BN09, WV01].

4.3 Le partitionnement

Pour que notre partitionnement garantisse des accès locaux aux transactions, nous faisons en

sorte que toute interaction n’implique que les données se situant sur le même noeud. Pour ce

faire, nous nous appuyons sur la notion de cible définie dans le chapitre précédent.

Notre partitionnement est composé de deux étapes : la découverte des cibles et la formation des

partitions. La cible est fortement dépendante du nombre d’utilisateurs qui accèdent simultané-

ment à ses données. Ainsi, aussi bien la charge que la taille d’une cible évoluent dans le temps

et sont respectivement proportionnelles à la densité des interactions et au nombre d’utilisateurs

qui la composent. De ce fait, nous proposons un mécanisme de détection des cibles qui puisse,

au besoin, ajuster dynamiquement le périmètre d’une cible afin de permettre sa prise en charge

sur une machine.

4.3.1 Découverte des cibles

Nous représentons la cible βw = {D; Iw} concernant l’ensemble des données {D}, avec l’en-

semble des interactions {Iw} durant la fenêtre temporelle w. Plus précisément, une cible est

définie comme un ensemble de données sollicitées dans les interactions d’un groupe d’utilisa-

teurs durant une fenêtre de temps. Une cible peut être vue comme un sous-graphe du graphe

d’interactions. Plus formellement, nous définissons une cible en nous appuyant sur le concept

de k-core de la théorie des graphe. Un k-core est un groupe maximal d’acteurs où chaque ac-

teur est connecté à au moins k autres membres du groupe. En partant de cette idée, une cible

est formée par un ensemble de données impliquées dans au moins k interactions pendant une

fenêtre de temps. Notons que plus élevée est la valeur de k, plus dense est la cible. Ainsi, quand

Le partitionnement dynamique et le placement des données 34

un sommet peut être inclus dans plusieurs cibles, nous choisissons celle avec laquelle la valeur

de k est la plus élevée. La raison de ce choix est de construire des groupes très cohésifs et très

denses pour faciliter le processus de partitionnement. L’évolution des cibles est prise en compte

dans notre procédure en considérant seulement les interactions d’une fenêtre temporelle donnée.

Par conséquent, si une donnée d est requise moins fréquemment dans une fenêtre de temps que

dans la précédente, alors d peut être exclue de la cible en se basant sur des seuils.

4.3.2 Formation des partitions

Les cibles peuvent grossir, fusionner, être éclatées et ainsi de suite sur différentes fenêtres de

temps. Ce sont là les différentes opérations de notre partitionnement dynamique.

La fusion de cibles peut résulter à la formation d’une nouvelle partition ou la mise à jour d’une

partition existante. Cette opération est souvent provoquée par un besoin d’avoir des interactions

sur un nœud unique.

L’éclatement d’une cible consiste à produire plusieurs cibles à partir d’une cible où les interac-

tions peuvent être divisées en 2 ou plusieurs groupes compacts. Cette opération permet d’affiner

les partitions mais surtout un passage à l’échelle horizontale. Les exemples sur la Figure 4.1

illustrent la formation et l’évolution des cibles en se basant sur un 2-core, qui signifie qu’une

cible satisfait au moins à un 2-core. Nous illustrons ici comment on peut former des partitions

en utilisant les cibles et favoriser des interactions en local. Nous supposons un ensemble de sept

données {a,b,c,d,e,f,g} appartenant à sept utilisateurs qui interagissent pendant une période de

temps. Puisque chaque interaction se passe entre au moins deux utilisateurs, alors elle joint au

moins deux données, chacune pour un utilisateur. Une interaction qui implique deux données a

et b dans la fenêtre temporelle w est notée iwa,b.

Dans la figure 4.1a, nous observons deux cibles à w.

β1w = {(a, b, c); (iwa,b

, iwb,c, iwa,c)}

β2w = {(d, e, f, g); (iwd,e

, iwe,f, iwd,f

, iwe,g , iwg,f)}

Ces deux cibles sont des 2-core. En fonction des interactions récentes qui ont lieu dans la fenêtre

de temps suivante w′, les cibles ont changé comme on peut l’observer sur la Figure 4.1b.

β3w′ = {(d, e, g); (iw′

d,e, iw′

e,g , iw′d,g

)}

β4w′ = {(a, b, f, c); (iw′

a,b, iw′

a,f, iw′

a,c , iw′f,b, iw′

f,c, iw′

c,b)}.

La cible β4w′ est un 3-core. C’est pourquoi la donnée d est exclue et comme on peut le voir, la

cible est plus homogène et dense. En réalité, durant la fenêtre temporellew′, il y’a eu des interac-

tions entre d, b (iw′d,b

) et d, f (iw′b,f

) que nous représentons par les arcs en pointillés. Donc nous

Le partitionnement dynamique et le placement des données 35

(A) Cibles dans la fenêtre de temps w (B) Cibles dans la fenêtre de temps w′

FIGURE 4.1: Formation et évolution des cibles

pouvons considérer l’ensemble des données a, b, c, d, e, f, g comme faisant partie d’une seule

cible, un 2-core. Mais quand nous sommes dans le besoin de partitionner ces données pour une

raison ou une autre, nous identifions les deux cibles qui se dégagent nettement, à savoir β3w′ et

β4w′ en se basant sur la densité des interactions entretenues avec les autres membres. C’est cette

opération que nous appelons éclatement d’une cible. La fusion est l’opération inverse, c’est-à-

dire si nous avons deux cibles distinctes et une ou plusieurs nouvelles interactions impliquant

des membres appartenant aux deux cibles, alors la réunion de ces deux cibles conduit un nou-

velle cible plus grande. Cette opération se fait, en général, quand ces deux cibles sont situées sur

deux nœuds distincts, et c’est pour éviter les accès distribués.

Notons que dans certains cas qu’une réplication temporaire d’une partie d’une cible vers une

autre partition peut s’avérer avantageuse. En effet, lorsqu’une interaction arrive entre deux don-

nées appartenant à deux cibles totalement disjointes, bien compactes et situées sur deux sites,

alors répliquer temporairement une des deux données vers l’autre cible peut être une stratégie

plus avantageuse que la fusion des deux cibles. Cette situation est observée quand les deux cibles

en question sont de grande taille et suffisamment denses. Alors, leur réunion peut nécessiter la

création d’une nouvelle instance (machine) ayant suffisamment de capacités pour prendre en

charge la nouvelle cible. Or, cette nouvelle cible est composée de deux groupes bien compacts

qui n’ont que peu de liens rarement visités. Dans une telle situation, il est mieux de garder ces

cibles chacune de son côté et traiter sur l’un des deux sites les quelques rares interactions qui les

unissent.

4.4 Le placement des partitions

Plusieurs études dans la littérature [HL90, MD97, CJZM10, AKD13, ASA+13, SJK+13] ont

montré que les performances et le passage à l’échelle des systèmes de bases de données dis-

tribuées sont dépendants du placement des données sur les nœuds. En plus, le placement des

données sert de mécanisme d’équilibrage de charge puisqu’il détermine non seulement la distri-

bution des données mais aussi la distribution des opérations sur ces données. Ainsi, pour avoir

Le partitionnement dynamique et le placement des données 36

une effectivité de la répartition de la charge et éviter les goulots d’étranglement, notre partition-

nement, guidé par l’évolution des cibles, est associé à un schéma de placement tout aussi dyna-

mique. Les cibles et la charge sont dynamiquement distribuées à travers les noeuds disponibles

pour mieux faire face aux fluctuations de la charge. Un placement judicieux et dynamique des

partitions nous permet d’isoler les charges [MD97] et d’arriver à un équilibre en termes de res-

sources de traitement et le nombre de partitions allouées à un nœud [GSN14a]. Le défi consiste

à pouvoir déplacer une partition d’un nœud à l’autre tout en garantissant des temps de réponse

acceptables. Pour y arriver, nous choisissons de déployer notre solution dans un environnement

de type Cloud. Ce choix se justifie par le fait qu’en général dans ce type d’environnement, la

bande passante est suffisante pour garantir un transfert très rapide des données. En plus, le sys-

tème offre des primitives de création d’instances de noeud ou d’en retirer très rapidement et en

temps réel. Notre stratégie de placement adapte globalement la quantité de ressources engagées

en fonction des variations de la charge soumise au système. C’est-à-dire, que le placement des

données peut changer en fonction de l’évolution de la charge sur les différents nœuds du sys-

tème.

Sa mise en œuvre s’appuie sur une composante du système que nous appelons moteur de déci-

sion de placement (voire Figure 3.3). Cette entité utilise les données de surveillance permanente

du système et calcule des schémas de placement pour résoudre les déséquilibres le cas échéant.

Ce calcul consiste à déterminer quelle partition doit être placée sur quel noeud. Une fois ce cal-

cul fait, il faut procéder au placement proprement dit, il s’agira de déplacer certaines partitions

d’un nœud à un autre.

Le coût de cette stratégie de placement doit rester inférieur au bénéfice qui en découle pour que

la stratégie soit efficace. Autrement dit, le coût de ces opérations doit être tel que les transac-

tions soient traitées dans les délais impartis. Pour ce faire, nous utiliserons des techniques de

déplacement en temps réel, comme proposées dans [ASDA11, DNAE11, Jon12]. Le placement

dynamique que nous proposons opère selon trois cas de figure :

1. Le premier cas c’est quand des pics de charge apparaissent et conduisent à un non respect

de la garantie d’un temps de réponse borné. Dans ce cas, une ou plusieurs partitions sont

déplacées. Ces partitions sont déplacées vers un nœud capable de les garder tout en conti-

nuant à répondre aux sollicitations des transactions avec un temps borné. Pour ce faire,

notre système procède à une surveillance de la charge de tous les nœuds du système. Ce

faisant, il a une connaissance globale de la répartition de la charge, mais aussi des nœuds

qui pourraient recevoir d’autres partitions. Ainsi, une nouvelle décision globale de pla-

cement est prise pour rétablir l’équilibre de la charge sur certains nœuds. Cette décision

comporte une phase d’identification des partitions à déplacer. Nous détaillons comment

ce choix est effectué dans le chapitre 5.

2. Le deuxième cas est celui où une transaction demandant à accéder à des cibles localisées

sur différentes machines. Alors, un regroupement des données doit se faire et aboutir à

Le partitionnement dynamique et le placement des données 37

la formation d’une nouvelle cible pour garantir un accès local et ne pas provoquer de

surcharge. Ainsi, une nouvelle partition contenant la nouvelle cible est crée et placée sur

un nœud.

3. Le troisième cas est celui qui se présente lorsqu’un noeud est sous-chargé ou n’a plus de

charge. Il faut alors déplacer les partitions sur les autres noeuds actifs et arrêter le noeud

sous-chargé.

Dans tous les cas, les décisions de placement sont prises en fonction d’une vue globale de l’état

du système pour réduire les placements en cascade.

La mise œuvre des décisions de placement passe parfois par des déplacements de données d’un

nœud à un autre. Ce déplacement est composé de deux phases :

– une phase d’envoi de l’information à la couche de routage et aux nœuds concernés sur la

couche bases de données. Ceci permet de mettre à jour l’index de localisation (schéma de

placement) sur la couche de routage, et une mise à jour des index ;

– une phase d’envoi des données. Cette phase se déroule de manière glissante dans le temps.

En effet, une fois les index mis à jour, l’échange de données ne se fait pas automatiquement

entre les noeuds de base de données. Un noeud qui est censé recevoir une nouvelle partition

le note dans son index local et attend qu’une transaction demande un accès à une donnée dans

la partition, puis la donnée est récupérée. Les données de la partition seront ainsi déplacées à

la demande.

4.5 Conclusion

Un bon partitionnement associé à une bonne stratégie de placement des données, facilitent le

passage à l’échelle d’un système de gestion données en permettant un équilibrage des charges.

Dans ce chapitre, nous avons présenté notre méthode de partitionnement qui garantit que les

transactions soient toujours exécutées en local. Ce qui offre un passage à l’échelle horizontal de

notre système. Ce partitionnement est guidé par les cibles qui sont les granules dans lesquelles

les interactions se font. Notre partitionnement tient compte de leur taille et de leur charge pour

arriver au résultat escompté. La stratégie de placement que nous associons au partitionnement

nous permet d’arriver à un équilibrage de la charge globale sur les nœuds tout en minimisant le

nombre de nœuds nécessaires.

Chapitre 5

Gestion des fluctuations de la chargetransactionnelle

Dans ce chapitre nous étudions la gestion de la charge transactionnelle soumise au système. Il

s’agit d’adapter dynamiquement les capacités de traitement du système en fonction des caracté-

ristiques de la charge.

Dans les approches classiques de déploiement des systèmes de gestion de données distribuées,

l’idée la plus répandue est d’allouer plus de ressources (traitement, stockage et bande passante)

qu’il n’en faut. Ainsi, en cas de fortes charges les différents composants du système auront tou-

jours les capacités pour traiter ces fortes charges. Le problème est qu’en cas de charges faibles

ou même moyennes, la part ressources allouées et non utilisées devient importante.

Dans ce chapitre, nous proposons des solutions permettant à notre système distribué et structu-

rée en couches, de faire face à de fortes charges ou des charges moins fortes tout en utilisant

à chaque fois la quantité de ressources nécessaire et pas plus. Nous commençons par formu-

ler clairement le problème, puis nous présentons les solutions proposées pour les différentes

couches de notre système.

5.1 Formulation du problème et solutions proposées

La problématique générale de la gestion de la charge est résumée sur la Figure 5.1. En effet,

nous sommes confrontés à :

– une charge applicative fluctuante ;

– une contrainte de temps de réponse borné : toute transaction doit être traitée dans un délai ne

dépassant pas une limite fixée ;

– une contrainte de coût (financier et énergétique) par rapport à la quantité de ressources (ma-

chine) utilisée pour traiter la charge applicative.

38

Gestion des fluctuations de la charge transactionnelle 39

En général, dans les systèmes de gestion de données réparties le dimensionnement se fait de sorte

qu’à chaque machine on alloue une quantité de données dépendant des attentes de performances.

Autrement dit, on peut dimensionner pour être en mesure de traiter une valeur de charge donnée

sur les données d’une machine. Cette association ne change pas, à moins d’arrêter le système et

de tout reconfigurer. On parle de dimensionnement statique. Il existe principalement deux types

de dimensionnement statique :

– le surdimensionnement (over-provisioning) qui consiste à prévoir plus de ressources qu’il

n’en faut pour gérer la charge maximale possible pour la quantité de données allouée à la

machine. Dans ce cas, avec une charge applicative aussi variable que celle des applications

visées dans notre travail, un surdimensionnement statique serait synonyme de gaspillage la

plupart du temps. Ce phénomène est illustré sur la Figure 5.1 par la courbe du même nom (en

pointillés).

– le dimensionnement moyen (average provisioning) consistant à allouer les ressources en fonc-

tion de la charge moyenne prévue. Dans ce cas de figure, avec l’occurrence de pics de charge

on se retrouve dans des situations où on ne satisfait plus aux contraintes de qualité de service

(temps de réponse). Ce phénomène est illustré par la courbe du même nom sur la Figure 5.1.

FIGURE 5.1: Approvisionnement selon la charge courante et non selon le pic maximal

Une solution serait d’utiliser un "dimensionnement dynamique" qui équivaut à un placement

dynamique des partitions de données sur les ressources du système. Ce placement se fait à la

demande en fonction de la charge courante des machines et de la quantité de données hébergée.

Sur la Figure 5.1, nous illustrons le résultat escompté par la courbe en trait plein nommée "à la

demande". Dans cette solution, une machine fait partie du système que si cela s’avère nécessaire.

En d’autres termes, un nœud du système fonctionne que s’il a suffisamment 1 de travail à faire.

Toutefois, une taille minimale du système doit être prévue. Cette taille minimale correspond au

1. Le terme "suffisamment" fait référence à un seuil minimal qui peut être le nombre de requêtes/transactionstraitées par minute. On en déduirait qu’une machine n’ayant pas une quantité de charge supérieure ou égale à ce seuilest insuffisamment chargée.

Gestion des fluctuations de la charge transactionnelle 40

nombre de nœuds nécessaires pour stocker toutes les données tout en étant capable de traiter les

transactions avec la contrainte de temps de réponse fixée.

5.1.1 Solutions proposées

Dans cette thèse, nous avons proposé deux solutions qui se complètent pour approcher la solu-

tion "optimale" ci-haut présentée. Les deux solutions que nous proposons apportent une réponse

pour le problème posé aussi bien sur la couche de routage que sur la couche de stockage. Notre

architecture est suffisamment modulaire pour que nous puissions considérer d’un côté notre

couche de routage et gérer sa charge transactionnelle et d’un autre côté gérer celle de la couche

des données. Ainsi, la première partie de notre solution est relative à la gestion de la charge sur

la couche de routage des transactions [GSN12]. Nous y proposons une solution élastique qui fait

varier les ressources de cette couche en fonction des variations notées sur la charge. La deuxième

proposition ([GSN14a] et [GSN14b]) est axée sur la couche de stockage des données et d’exé-

cution des transactions. Dans cette solution nous tenons compte de l’impact que la structure

des interactions entre utilisateurs a sur le modèle d’accès aux données et proposons un place-

ment dynamique qui consolide les données sur un minimum de machines et vise à maximiser

les exécutions de transactions sur un même site. Cette solution s’appuie aussi sur un méca-

nisme d’équilibrage des charges entre les nœuds DB et d’élasticité. La gestion des fluctuations

de la charge se fait donc en deux étapes : la détection d’une situation de charge anormale (sur-

charge ou absence de charge) et sa résolution. Cette résolution se fait avec deux mécanismes :

l’élasticité et l’équilibrage des charges. L’élasticité peut être définie comme l’habilité à aug-

menter au réduire la taille du système. Plus précisément, il s’agit de pouvoir ajouter/supprimer

des nœuds au système sans interrompre ni compromettre son fonctionnement. Ainsi, le système

peu "s’étirer" ou se "rétrécir" pour s’adapter à la charge réelle. L’équilibrage de charge quant à

lui consiste répartir la charge entre les nœuds actifs du système. Il s’agit plus précisément, de

transférer une partie de la charge d’un nœud surchargé vers un autre moins chargé. Dans nos

différentes solutions proposées, l’équilibrage des charges est toujours prioritaire sur l’élasticité.

La mise en œuvre de l’élasticité nécessite de pouvoir initialiser et d’ajouter très rapidement en

nouveau nœud au système, ou d’en enlever très rapidement. Voilà pourquoi nous choisissons

l’environnement du Cloud qui offre les primitives nécessaires, la flexibilité et la simplicité dans

l’ajustement dynamique des ressources (machine, CPU, RAM, bande passante). Le défi étant

d’adapter les fonctionnalités d’un système de gestion de données réparties à un environnement

aussi dynamique.

Pour adapter notre système au Cloud et en tirer les avantages, nous avons prédéfini et précon-

figuré des images (systèmes) pour les différents rôles des nœuds du système : routage, gestion

du catalogue, base de données, contrôleur, etc. Par la suite, le système en soi est composé d’un

Gestion des fluctuations de la charge transactionnelle 41

ensemble de machines virtuelles (VM) de différents rôles 2. Chaque entité du middleware ou de

la couche de stockage est encapsulée dans une machine virtuelle. Nous utilisons alors les primi-

tives par l’environnement Cloud (IaaS) pour facilement ajouter des nœuds quand cela devient

nécessaire. L’ajout de nœuds n’est, par ailleurs, pas systématique en cas de surcharge. Nous

n’aurons pas besoin d’ajouter un nouveau nœud s’il est possible d’équilibrer la charge avec les

nœuds présents. Par conséquent, nous avons en premier lieu conçu un mécanisme d’équilibrage

de charge pour toujours répartir la charge presque uniformément parmi les nœuds présents.

5.2 Gestion de la charge transactionnelle sur la couche de routage

Nous proposons TransElas [GSN12] dont l’objectif est d’améliorer les performances d’une solu-

tion de routage proposée antérieurement dans notre équipe, TransPeer [SNG10]. Cette solution

est un middleware distribué de routage de transactions sur des données réparties. Ce middleware

est composé de deux types de noeud : les TM ou gestionnaires de transactions et les SD ou nœud

du catalogue réparti. Le catalogue est donc réparti sur un ensemble de nœuds (SD) et stocke

toutes les informations nécessaires au routage correct et efficace des transactions vers les nœuds

de données (DN). Les noeuds appelés TM dans TransPeer correspondent aux noeuds que nous

appelons RN (routeurs) dans notre travail. TransElas apporte une solution au contentions obser-

vées dans TransPeer lors d’occurrences de fortes charges. Le principe de TransElas est qu’aucun

nœud du middleware ne doit rester surchargé pendant une durée suffisamment longue pour de-

venir un point de contention. Son fonctionnement peut être résumé comme une surveillance

permanente du niveau de charge de chaque nœud du middleware et, en cas de déséquilibre,

un ajustement dynamique des ressources (nombre de nœuds) impliquées dans le traitement des

transactions. Il s’agit de rendre la couche de routage élastique, c’est-à-dire pouvoir faire va-

rier automatiquement les ressources selon les charges réelles et en fonction d’une contrainte de

temps de réponse. Nous avons introduit une nouvelle entité que nous avons nommée contrô-

leur (CtrlN) qui recueille les informations issues de la surveillance et détecte les surcharges ou

l’absence de la charge. A la suite, une alerte est lancée et les ajustements nécessaires sont faits.

5.2.1 Détection d’une charge anormale

La charge est dite normale quand le nœud n’est ni surchargé, ni sous-chargé. Autrement, la

charge est anormale : surcharge ou absence de charge. Chaque noeud RN et SD informe pério-

diquement le contrôleur sur sa charge courante. La valeur de la charge est un ratio d’utilisation,

qui s’il est supérieur à 1 indique une surcharge du nœud. Le contrôleur agrège toutes ces infor-

mations sur la charge des nœuds du middleware et maintient une moyenne glissante de la charge

2. Chaque VM est instanciée avec une image spécifique. Chaque image est un nœud préconfiguré pour jouer unrôle spécifique.

Gestion des fluctuations de la charge transactionnelle 42

Li pour chaque RNi et SDi. Nous définissons deux valeurs de charge Ldown and Lup. Si Li est

dans l’intervalle [Ldown, Lup], alors le niveau de charge est normal et aucun traitement n’est

nécessaire. Ceci garantit une stabilité des associations RN-à-client, en cas de petites fluctuations

dans la charge. Si Li est inférieure ou égale à Ldown pendant une période fixée 3 alors le nœud

est considéré comme sous-chargé. Sinon, si Li est supérieure Lup alors le nœud est considéré

comme surchargé.

Les valeurs exactes de Ldown et Lup sont spécifiques aux applications cibles. Intuitivement, avec

une valeur Lup proche de 100%, il peut arriver qu’un nœud soit temporairement surchargé. D’un

autre côté, une plus petite valeur Lup permettra d’éviter à un nœud de devenir temporairement

surchargé, mais en contrepartie, elle causera une sous utilisation du nœud en général.

5.2.2 Équilibrage de la charge entre les TMs

Chaque RN attend en permanence les transactions entrantes envoyées par les clients. Nous as-

signons initialement un RN à chaque client d’une manière round robin de sorte que chaque RN

gère le même nombre de clients. Puisque les clients envoient différentes transactions avec diffé-

rents temps d’exécution, il est possible qu’un RN devienne plus chargé qu’un autre. Ainsi, pour

mieux équilibrer la charge, nous ajustons le nombre de clients associés à un RN, c’est-à-dire

que nous déplaçons un client d’un RN surchargé à un autre moins chargé. Cet ajustement est

déclenché par la détection d’une charge anormale.

Pour chaque RNi avec une charge Li > Lup, nous trouvons le RN le moins chargé qui puisse

recevoir le surplus de charge (i.e., Li - Lup). Pour des raison de stabilité, nous considérons

seulement les candidats ayant une petite charge (Ldown ≤ Li < Lup). En outre, si la quantité du

surplus de charge ne peut pas être déplacée vers un seul RN, nous le partitionnons en plusieurs

morceaux et les assignons à plusieurs RNs de sorte qu’aucun RN candidat ne soit surchargé à la

suite de la procédure d’équilibrage de charge. Si aucun candidat n’est trouvé, alors nous ajoutons

un nouveau RN. Le déplacement d’une charge se fait comme décrit ci-dessous. La charge d’un

RN est faite de demandes transactionnelles en cours et en attente. Puisque le temps d’exécu-

tion d’une transaction est plutôt court, nous ne tentons pas de déplacer une transaction en cours

d’exécution en changeant le RN qui en est responsable. Toutefois, nous déplaçons les futures

transactions en changeant le RN qu’elles appelleront plus tard. La principale action pour mettre

en œuvre l’équilibrage de la charge et l’élasticité consiste à déplacer une partie de la charge d’un

RN à l’autre. Nous définissons la primitive MoveLoad(i, j, r) qui déplace r% de la charge du RNi

au RNj . En fait, le CtrlN envoie au RNi un message 〈move, r, RNj〉, où r est le ratio de charge

à déplacer depuis RNi, et doit être ajouté à RNj . Dès la réception de ce message, RNi choisit

les k clients plus récents (avec k = n*nombre_de_clients_actifs), qui représente l’ensemble des

clients à déplacer (noté M ). Par la suite, quand le RNi envoie le résultat d’une transaction en

3. Durée d’observation correspondant à plusieurs relevés dont le nombre est fixé selon le besoin

Gestion des fluctuations de la charge transactionnelle 43

retour à un client qui appartient à M , il y greffe un message qui demande au client d’utiliser

RNj à la place de RNi à partir de cet instant. Ceci fera que le client va temporairement fermer

sa connexion avec RNi, et redirige ses demandes suivantes vers RNj . Notons que la surcharge

en termes de communications est seulement d’un message supplémentaire depuis le contrôleur

vers le RNi.

5.2.3 Élasticité des RNs

La fonction d”élasticité consiste à ajouter/supprimer un nœud en fonction de la charge courante

si nécessaire. Dans ce qui suit, nous décrivons les conditions d’ajout/suppression d’un nœud et

détaillons comment charger un nœud nouvellement créé, ou décharger un nœud à supprimer.

Nous déclenchons les actions pour ajouter/supprimer un nœud en fonction de la valeur courante

de la charge moyenne Li du nœud RNi :

– Si Li > Lup et qu’aucun autre RN ne peut supporter le surplus de charge, alors nous démar-

rons un nouveau nœud RNj et déplaçons le surplus de charge depuis RNi vers RNj .

– Si Li < Ldown, et s’il existe un ensemble S de RNs capables de supporter Li de sorte que

chaque t dans S a sa charge au dessus de Li, et qu’aucun t ne sera surchargé à la suite, alors

nous distribuons la charge parmi les RNs dans S. Ceci permets de vider le nœud RNi. Alors,

nous notifions au répertoire partagé qui, initialement assigne un RN à un nouveau client, de

ne plus suggérer RNi. Ainsi, le nœud RNi devenu idle est arrêté.

– Si Li est dans [Ldown, Lup], alors nous ne changeons pas le nombre de nœuds.

Les nœuds, RN et SD, sont des machines virtuelles (VM) préconfigurées avec les fonctionnalités

nécessaires pour jouer le rôle d’un RN ou un SD. Leur procédures d’ajout ou de retrait, simples

et rapides (du point de vue utilisateur), sont offertes par l’infrastructures (IaaS) Cloud utilisée.

5.2.4 Équilibrage de la charge et élasticité des SDs

Nous rappelons que les nœuds SD gèrent les accès aux métadonnées qu’un RN a besoin pour

router une transaction. Au cas où un SD devient surchargé, nous ne pouvons pas simplement

rediriger les requêtes entrantes vers un autre nœud SD moins chargé, parce que des métadon-

nées distinctes sont gérées par des nœuds SD distincts. Nous devons aussi transférer la part de

métadonnées d’un SD à l’autre. Pour ce faire, nous nous appuyons sur le mécanisme du par-

titionnement par intervalle (range partitioning) pour dynamiquement ajuster la portion de mé-

tadonnées qu’un SD contrôle à un moment donné. Les n métadonnées sont désignées par M1,

..., Mn. En général, Mi est la métadonnée à propos de la ime donnée. Initialement, nous distri-

buons uniformément les métadonnées sur les m nœuds SD, en partitionnant le domaine [1, n]

en m intervalles consécutifs. Soit V un vecteur de dimension (m + 1). Chaque SDi gère les

métadonnées Mk de telle sorte que k ∈ [Vi−1, Vi[. Alors l’équilibrage des charge des SDs suit

Gestion des fluctuations de la charge transactionnelle 44

une méthode similaire à celle avec les TMs. Le CtrlN vérifie périodiquement la charge des SDs.

Pour chaque SDi surchargé, nous procédons comme suit pour équilibrer la charge ou ajouter un

nouveau nœud :

– Si (SDi−1) est capable de supporter le surplus de charge (i.e., i > 0 et Li−1 ≥ Ldown), alors

le CtrlN envoie un message à SDi pour déplacer le surplus de charge vers SDi−1.

– Sinon, si (SDi+1) peut supporter le surplus de charge ; (i.e., i < n et Li+1 ≥ Ldown), alors

CtrlN envoi un message à SDi pour déplacer le surplus de charge vers SDi+1.

– Sinon il crée un nouveau nœud SD qui prendra en charge le surplus de charge.

Á l’opposé, pour chaque nœud SDi sous chargé tel que Li < Ldown, si il existe un SDj (j = i−1

ou j = i + 1) qui peut supporter la totalité de la charge de SDi sans devenir surchargé, alors

nous déplaçons la charge de SDi vers SDj . Ainsi, nous arrêtons SDi une fois tous les TMs sont

notifiés de ce changement. Puisque chaque SD contrôle une portion distincte des métadonnées,

changer la portion de métadonnées qu’un SD contrôle conduit à changer la charge du SD. Par

conséquent, nous définissons la primitive MoveSDLoad(i, j, r) qui gère la modification de la

charge. Plus précisément, le contrôleur (CtrlN) envoie un message 〈move, r, SDj〉 au SDi avec

r, le ratio de charge à déplacer du SDi vers SDj , et j est aussi i− 1 ou i+ 1. A la réception de

ce message, SDi met à jour son vecteur V de sorte à relâcher le contrôle sur r% de l’intervalle

dont il avait le contrôle. Ainsi, SDi déplace les métadonnées correspondantes vers SDj . Plus

tard, l’information, à propos du transfert des métadonnées transférées du SDi au SDj , sera pro-

pagée au autres nœuds TM à la demande. Quand un TM demande à SDi des métadonnées dans

l’intervalle transféré, le SDi répond avec un message 〈 de redirection vers SDj〉 qui permet au

TM de mettre à jour son propre vecteur V , pour ensuite se connecter directement au SDj . Nous

avons choisi la propagation à la demande plutôt que le faire dès que possible, pour minimiser

la surcharge occasionnée par l’invocation de la primitive. En outre, cette primitive est suffisam-

ment générique pour gérer l’équilibrage de charge entre deux nœuds consécutifs existants, aussi

bien que l’élasticité. Le passage à plus de nœuds SD (scale up), résultera d’un éclatement d’in-

tervalles de métadonnées. Le passage à moins de nœuds SD (scale down) résultera d’une fusion

de portions consécutives de métadonnées.

5.3 Gestion de la charge transactionnelle sur la couche des données

La gestion de la charge sur la couche de stockage des données et d’exécution des transactions est

d’autant plus complexe qu’en plus de la contrainte de temps de réponse, nous avons un modèle

d’exécution des transactions qui favorise les traitements locaux. Notre politique de gestion de la

charge sur cette couche du système suit les mêmes principes que sur la couche du middleware :

équilibrage de charge en priorité, si ce n’est pas suffisant alors mettre en œuvre l’élasticité.

Le principal problème est alors comment opérer tout en gardant les données sollicitées par les

mêmes transactions sur les mêmes nœuds pour garantir un accès local. Nous utilisons notre

Gestion des fluctuations de la charge transactionnelle 45

méthode de partitionnement dynamique (voir chapitre 4). Nous nous appuyons sur la notion de

cible comme granule de partitionnement pour proposer des algorithmes permettant d’équilibrer

la charge, d’absorber des pics de charge et consolider le système lorsque la charge globale

devient faible.

Définition 5.1. Nous considérons un ensemble de noeuds N . Chaque noeud Nk ∈ N est une

machine (virtuelle) hébergeant la base de données DBk. Pour simplifier la notation, nous dési-

gnons le noeud Nk par DBk. Alors, chaque noeud DBk stocke un ensemble de partitions, pkiindiquant la partition i de la base de données k. Pendant le fonctionnement, un nœud DB exécute

les transactions entrantes en respectant l’ordre dans lequel il les reçoit. Soit ω la dernière fenêtre

d’observation, exprimée en secondes. Chaque noeud DB garde une Trace des transactions en-

trantes : T kω désigne l’ensemble des transactions qui veulent accéder à ses partitions. Cette trace

prend en compte les transactions terminées dans ω ou non (c.-à-d., en attente ou en cours d’exé-

cution). La Trace informe à propos du temps d’exécution courant et le temps d’attente moyenne

pour chaque transaction. Pour quantifier la charge d’un nœud, nous agrégeons ces informations

récentes, soit RTω(pki ) qui désigne la somme des temps d’exécution et d’attente de toutes les

transactions dans Tω(pki ). Nous définissons load(pki ) comme la charge moyenne de pki pendant

ω telle que :

load(pki ) =RTω(pki )

| ω |(5.1)

Puisque chaque noeud DB peut stocker plus ou moins de partitions, nous définissons la charge

d’un nœud DB comme étant la somme des charges de toutes les partitions sous son contrôle.

Formellement, la charge d’un DBk qui gère n partitions est :

load(DBk) =∑i

nload(pki ) (5.2)

Soit τk le temps de traitement d’une transaction unique sur un nœud DBk. Soit rtk le temps de

réponse observé d’une transaction (incluant le temps d’attente). La charge load(DBk) peut être

considérée comme un facteur de pénalité impactant rtk comme suit :

rtk = τk.load(DBk)

Rappelons qu’une partition de la base de données contient une ou plusieurs cibles, donc nous dé-

terminons la charge d’une cible par la même démarche que pour une partition mais en réduisant

le champ d’action à la cible. Ceci est possible grâce à la Trace qui fournit toutes les informations

nécessaires sur les données sollicitées pendant la fenêtre de temps concernée.

5.3.1 Détection d’un pic de charge

Nous définissons les conditions de stabilité de tout nœud DB comme les conditions dans les-

quelles le DB n’est pas surchargé encore moins sous-chargé. Plus précisément, nous prévoyons

Gestion des fluctuations de la charge transactionnelle 46

que toute transaction sera exécutée dans un temps borné. Soit Tmax qui désigne le temps de

réponse maximal attendu pour une transaction. Pour chaque noeud DB, nous prévoyons que

rtk ≤ Tmax, c’est-à-dire que la condition suivante doit être satisfaite :

load(DBk) ≤Tmaxτk

(5.3)

Inversement, un noeud est considéré comme sous-chargé s’il reste idle (i.e. aucune transaction

en exécution). Ainsi tout noeud DB doit satisfaire la condition suivante :

load(DBk) > 0 (5.4)

Un noeud est détecté comme surchargé (resp. idle) si la condition (5.3) (resp.(5.4)) n’est pas

satisfaite pendant une durée donnée ωoverload (resp. ωidle). Il est à noter que Tmax tout comme

la taille des fenêtres ωoverload et ωidle, sont des indicateurs de performances. Tmax peut être fixé,

en se basant sur les exigences de qualité de services, par le fournisseur, tandis que les valeurs de

ω sont réglées dans le but de prendre des décisions plus appropriées (précision).

5.3.2 Identification de l’origine des pics de charge

Un pic de charge apparait sur un nœud DB si une ou plusieurs de ses partitions sont surchargées,

conduisant à un temps de réponse des transactions qui se dégrade sur le nœud. La surcharge des

partitions est due à des fortes demandes sur les cibles appartenant à ces partitions. En ayant cela

en tête, trouver l’origine des pics peut se résumer intuitivement comme une identification de

suffisamment de cibles, avec les charges les plus élevées. Le surplus de charge ∆load est défini

comme suit :

∆loadk = load(DBk)−Tmaxτk

(5.5)

Pour chaque noeud DBk surchargé, nous trions l’ensemble des cibles {Cik} dans l’ordre des-

cendant des load(Cki ). Puis, nous déterminons un sous ensemble Mk de {Cki } tel que :

∑Ck

i ∈Mk

load(Cki ) ≥ ∆loadk (5.6)

Notons que la taille de Mk est minimale puisque Mk est un préfixe d’un ensemble ordonné

{Cki }. Ceci a pour but de réduire d’avantage le nombre de cibles à déplacer. Puis, nous déplace-

rons d’une manière itérative toutes les cibles dansMk, pour ramenerDBk à un niveau de charge

normal.

Gestion des fluctuations de la charge transactionnelle 47

5.3.3 Équilibrage de la charge et élasticité des BD

L’idée de base de la procédure d’absorption des fluctuations de la charge est la migration des

données. Quand il s’agit d’une surcharge, il s’agira de migrer certaines cibles vers un noeud DB

moins chargé. Quand il s’agit d’un noeud BD sous-chargé, il s’agira de le vider en migrant ses

partitions ailleurs. La migration est plus critique quand il s’agit de décharger un noeud surchargé.

Le problème de cette absorption de la surcharge est de deux dimensions : 1) identifier les noeud

DB candidats qui peuvent recevoir le surplus de charge et, 2) exécuter la procédure de migration

proprement dite, sans interrompre le traitement.

5.3.3.1 Identification des DBs candidates :

Notre approche consiste à utiliser les DB les moins chargés comme candidats pour recevoir le

surplus. Fondamentalement, quand un noeud est choisi pour recevoir une charge depuis un autre

noeud, il devra rester stable (non surchargé) après l’opération. L’algorithme pour absorber une

surcharge du DBk marche étape par étape comme suit :

– Pour chaque cible Cki dans Mk (voir section 5.3.2) qui est surchargée, évaluer sa charge ;

– Trouver tous les DB candidats qui ne sont pas surchargés et qui sont capables de recevoir

load(Cki ) tout en restant dans les conditions normales de charge à la suite. En fait, DBd est un

candidat de destination pour load(Cki ) si :

load(DBd)) ≤Tmaxτd− load(Cki ) (5.7)

– Si il n’y a aucun noeud DB candidat capable de recevoir Cki , alors la condition (5.7) est testée

pour Cki+1.

– Après la migration de chaque Cki , Mk est mis à jour. Si Mk demeure non vide et si aucun DB

n’est capable de recevoir le surplus restant, alors nous démarrons une nouvelle instance de

nœud DB et le contenu de Mk lui est alloué.

5.3.3.2 La procédure de migration :

Nous utilisons une procédure de migration qui s’appuie sur les travaux réalisés dans Relational

Cloud [CER+11] et ElasTraS [DAE13]. Les données sont récupérées (copies) à la demande de la

source vers la destination pour traiter les transactions à la destination. A la volée, les transactions

sont redirigées vers la destination. Une fois les données à migrer connues et leurs destinations

identifiées, la procédure de migration commence. Elle se fait en deux étapes :

– D’abord, l’étape d’initialisation : le DB source informe son router associé et le DB destina-

taire. Le routeur propage cette information aux autres routeurs. Les indexes, où sont indiquées

Gestion des fluctuations de la charge transactionnelle 48

les localisations de la cible, sont mis à jour. A partir de cet instant, les futures transactions

sur cette cible sont redirigées vers la nouvelle destination (DB qui reçoit la cible à migrer).

Ceci initialise l’équilibrage de la charge. Toutefois, à ce stade, aucune donnée n’est encore

transmise. Seuls les indexes sont mis à jour et le DB destination est prêt pour l’insertion des

nouvelles données dès que nécessaires.

– Une fois l’étape d’initialisation est faite, toutes les transactions qui demandent l’accès sur

la cible à migrer, sont routées vers le DB destination. Quand le DB destination reçoit une

transaction sur cette cible alors il fait une demande de la portion de données correspondante

au besoin de la transaction. C’est le récupération-à-la-demande. Et ainsi de suite, les pièces

de la cible sont transmises une à une, à la demande. Cette méthode à les avantages (i) de

permettre au DB source d’alterner le transfert de données et le traitement de transactions, ce

qui réduit la surcharge (temps d’attente) due à la migration ; et (ii) on déplace juste le volume

de données nécessaire, i.e. les parties dont la destination a effectivement besoin. Ceci permet

de réduire la quantité de données transmise.

• Prévenir la migration continuelle d’une cible : Nous supposons que si une cible Cki est

migrée vers une nouvelle instance DBz alors la charge maximale que peut induire cette cible

Cki ne peut pas excéder les capacités de traitement de DBz . Cela signifie que cette cible ne

sera pas migrée pour des raisons de surcharge à la suite de son déplacement récent. Notons

que notre algorithme de déplacement est transparent pour les applications qui peuvent poser

des transactions concernant des cibles en cours de déplacement, sans abandon. Notons aussi

que l’algorithme de déplacement est invoqué également lorsque qu’une décision est prise de

former une nouvelle cible sur un DB à partir de partitions résidant auparavant sur plusieurs DB

(cf. chapitre 4). Il est aussi invoqué lors d’une consolidation pour ’vider’ un nœud DB dont la

charge est trop faible, avant son retrait.

5.4 Validation expérimentale

5.4.1 Évaluation de l’élasticité de la couche de routage

Nous avons validé notre approche par simulation avec l’outil CloudSim [CRB+11]. La solution

d’élasticité proposée dans TransElas est inspirée des mécanismes d’élasticité offerts dans les

environnements de type Cloud. C’est ainsi que nous avons choisi de travailler avec CloudSim,

qui est un environnement de simulation orienté Cloud computing. Dans ces expérience nous

montrons la faisabilité et la validité de nos algorithmes qui apportent l’élasticité au middleware

(TM et SD). Nous commençons par montrer l’apport de notre solution pour résoudre le pro-

blème de contention noté dans TransPeer. Pour ce faire nous comparons les temps de réponse

obtenus avec TransElas et ceux obtenus avec TransPeer. Puis nous avons évalué l’élasticité des

composants de TransElas.

Gestion des fluctuations de la charge transactionnelle 49

5.4.1.1 Environnement expérimental

Nous avons créé via CloudSim un Datacenter contenant 10 nœuds physiques. Chacun d’entre

eux a les caractéristiques suivantes : 2660 MIPS de CPU, 16 GB de RAM et 1 GB/s de bande

passante. Sur chaque nœud physique, nous avons créé des machines virtuelles (VM) en fonction

des besoins en cours. En effet, chaque TM ou SD est associé à une VM, qui correspond à une

instance d’une VM d’Amazon EC2 (1600 MIPS en CPU et 1.7 GB de RAM). Le workload

étant produit par un nombre de clients variant durant toute l’expérience. Un nœud client envoie

une transaction et attend jusqu’à ce que la réponse lui parvienne avant d’en envoyer une autre.

Toutes les transactions accèdent aléatoirement aux données avec la même granularité.

5.4.1.2 TransElas vs TransPeer

Dans cette expérience, nous faisons une comparaison des temps de réponse obtenus lors du rou-

tage des transaction avec TransPeer et avec TransElas. Pour ce faire, nous démarrons avec 10

TMs, chacun peut traiter simultanément jusqu’à 10 transactions. Au delà de ce seuil, le TM

est considéré comme surchargé et par conséquent, le mécanisme d’équilibrage de charge se dé-

clenche et si nécessaire un nouveau TM est ajouté. Le seuil est choisi arbitrairement durant

les expériences mais dans le monde réel, il est fixé selon les conditions du SLO (Service Le-

vel Objectives). Nous avons fait varier la charge de 50 à 800 clients simultanés et nous avons

(A) TransElas vs TransPeer (B) Temps de réponse vs Charge variable

FIGURE 5.2: Performances globales de TransElas

recueilli les temps de réponse moyen du routage des transactions. La Figure 5.2a montre les

résultats obtenus. Les résultats montrent que les temps de réponse deviennent de plus en plus

importants à partir d’une certaine charge avec TransPeer (sur la courbe noté Static). Tandis que

nous observons le contraire avec TransElas (noté Elastic). En effet, avec TransElas, les temps de

réponse se stabilise autour d’une valeur limite. Les raisons sont qu’avec TransPeer le nombre de

TM n’évolue pas (Statique) quand la charge augmente. Par conséquent, certains TMs sont sur-

chargés et les transactions sont mises en files d’attente pendant un moment avant d’être routées.

Avec TransElas, de nouvelles ressources (TM et SD) sont ajoutées une fois que surcharge est

Gestion des fluctuations de la charge transactionnelle 50

observée, ce qui offre plus de disponibilité pour router suffisamment rapidement les transactions

entrantes. Ce résultat montre les bénéfices d’adapter le nombre de ressources de traitement en

fonction des variations de la charge, ce qui est visible sur la Figure 5.2b.

5.4.1.3 Élasticité des TMs

Dans cette expérience, nous évaluons les performances de l’élasticité des TMs. En d’autres

termes, il s’agit de savoir dans quel cas de figure notre système utilise le minimum de TMs

pour assurer un traitement de la charge en respectant les contraintes de temps fixées. Pour ce

faire nous comparons différentes stratégies. Dans un premier temps, nous mesurons les temps

de réponse quand la charge varie (nombre de clients) aléatoirement de 300 à 1400. En d’autres

termes, la charge peut augmenter à t et diminuer à t + ε ou vice versa. Pour garantir un temps

de réponse presque constant tout en minimisant le nombre de TM, nous ajoutons un nouveau

TM quand certains d’entre eux deviennent surchargés, et nous en supprimons un quand un TM

devient inutile (sous chargé). La Figure 5.2b montre que le temps de réponse moyen varie très

peu même si la charge varie aléatoirement. C’est le résultat de nos algorithmes qui ajoutent

des TMs progressivement si le système tend à être surchargé. Nous observons aussi une baisse

du temps de réponse quand la charge baisse en intensité. Ceci est principalement du au fait

que nous attendons plus longtemps avant de supprimer un nœud sous-chargé. Par conséquent,

nous maintenons dans le système pendant un moment autant de TMs qui donnent l’opportunité

de traiter immédiatement une transaction qui arrive. Dans un second temps, nous comptons le

nombre de TM requis en fonction des variation de la charge. Notre objectif principal dans cette

expérience est de mesurer le nombre global de TM requis pour prendre en charge le nombre

grandissant de clients. Nous considérons trois stratégies : 1) Scale-Up Only (SUO) – les TMs

sont ajoutés quand la charge augmente ; 2) Scale-Up and Scale-Down (SUSD) – un nouveau

TM est ajouté si un TM est surchargé tout comme un TM est supprimé s’il est sous-chargé ; 3)

Elasticity and Load Balancing (ELB) – nous incluons une procédure d’équilibrage de la charge :

si un TM est surchargé, nous essayons d’abord de répartir le surplus de charge vers d’autres

TMs, avant d’ajouter un TM s’il n’est pas possible de faire cette répartition de charge. La Figure

6.8 montre que le ELB et le SUSD requièrent moins de TM que le SUO. En fait, le scénario

ELB tout comme celui du SUSD ajoute et supprime des TM en fonction des variations de la

charge. Contrairement, l’option SUO ne supprime pas de TM même si la charge est faible, ainsi,

une fois un TM est ajouté il reste pour toute le reste de l’expérience. L’option ELB marche

mieux quand la charge devient un peu plus forte (au delà de 500 clients) parce qu’elle gère

plus efficacement les ressources de telle sorte qu’un TM n’est ajouté que s’il n’y a aucune autre

possibilité d’équilibrage de la charge transactionnelle entrante.

Gestion des fluctuations de la charge transactionnelle 51

FIGURE 5.3: Nombre de TM vs. Nombre de clients

5.4.1.4 Élasticité de tout le middleware

Dans cette section nous évaluons les performances d’élasticité du middleware (TM et SD). Nous

utilisons l’option ELB décrite dans l’expérience précédente, puisqu’elle requiert moins de res-

sources. La Figure 5.4 montre le nombre global de ressources requises pour prendre en charge la

charge applicative variable (de 300 à 1400 clients). Nous rappelons qu’ajouter un nouveau nœud

SD conduit à éclater une partie des métadonnées en deux parties. Quand le nombre de clients

varie, nous observons que le nombre de ressources utilisées augmente ou diminue en fonction

des variations de la charge. Le faible nombre ressources utilisées est due principalement à notre

mécanisme d’équilibrage de charge appliqué sur les TMs et les SDs. En fait, quand le nombre de

clients diminue, notre algorithme réduit le nombre de TM et SD tandis qu’il augmente le nombre

de TM seulement s’il n’y a aucune possibilité d’équilibrage avec les autres TMs présents.

FIGURE 5.4: Nombre de TM/SD vs. Nombre de clients

Gestion des fluctuations de la charge transactionnelle 52

5.4.2 Évaluation de l’élasticité sur la couche des données

Cette partie de la validation expérimentale a été implémentée avec l’environnement de simula-

tion SimJava [HM98]. SimJava est une API Java pour construire des modèles d’exécution pour

des systèmes complexes. Il est basé sur un noyau de simulation à évènements discrets et inclue

des facilités pour représenter les objets de la simulation. Nous avons implémenté chacune des

entités telles que les clients, nœuds RN et DB. Chacune de ces entités est encapsulée dans un

thread et échange avec les autres par le biais d’évènements. L’objectif de ces expériences est

de tester la réaction de la couche des données de notre système face aux pics de charge. Le

système s’appuie sur le mécanisme de partitionnement et de placement dynamique des données

(cf. chapitre 4) pour faire un équilibrage des charges entre instances de DB et absorber les pics

de charge. Nous testons notre système dans le cas d’une charge assez régulière avec peu de pics

de charge et dans le cas d’une charge très dynamique avec beaucoup de pics de charge.

5.4.2.1 Charge peu dynamique

Dans cette expérience nous testons la réaction typique de notre système pour faire face à l’oc-

currence d’un pic de charge. Pour ce faire, nous démarrons le système soumis à une charge

supportable et relativement uniforme sur les données. Puis, à un instant précis nous provoquons

une surcharge (un pic) qui se manifeste sous forme de pics sur des données précises. Ce biais

sur la charge est laissé tel qu’il est jusqu’à la fin de l’expérience. Nous provoquons un autre

pic de charge à un autre instant aussi choisi. Sur la Figure 5.5, nous pouvons observer l’évolu-

tion des temps de réponse des transactions sur tous les nœuds de base de données durant toute

l’expérience. Comme montré sur la légende, chaque couleur indique l’évolution des temps de

réponse sur un nœud donné. Le temps de réponse maximal étant fixé à 800 unités au cours

de l’expérience, nous observons très clairement que le système maintient cette limite à chaque

apparition de pic en effectuant des déplacements de données. Ainsi, il a fallu ajouter deux nou-

velles instances de base de données, DB2 et DB3 pour juguler la surcharge observée sur les deux

premiers nœuds de base de données. En effet, après l’apparition des premiers pics, le système

aura déplacé le maximum possible vers le DB1 puis a rajouté de nouvelles instances à chaque

fois que nécessaire. Cette réaction est celle escomptée de notre système face à de telles situa-

tions. Toutefois, dans le cas d’une forte charge avec beaucoup de pics, le nombre de déplacement

de données peuvent devenir important et ainsi impacter sur la garantie de maintenir un temps de

réponse borné. Nous étudions ce cas de figure dans l’expérience suivante.

Gestion des fluctuations de la charge transactionnelle 53

0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 10000 20000 30000 40000 50000 60000 70000 0

100

200

300

400

500

600

700

800

900

1000

1100

1200

Tem

ps

de

Rep

on

se (

un

ites

de

sim

ula

tio

n)

Ev

olu

tio

n d

e la

ch

arg

e (#

cli

ents

)

Dates (en unites de temps de simulation)

Evolution du temps de Reponse sur les noeuds DB

pic1

pic2

Sur DB0Sur DB1Sur DB2Sur DB3

Evolution de la charge

FIGURE 5.5: Évolution des temps de réponse dans le système avec l’occurrence de pics pastrop fréquents

5.4.2.2 Charge très dynamique

Dans cette expérience, nous mettons le système dans une situation de stress élevé. En effet, les

pics de charge apparaissent très fréquemment et en grand nombre. L’objectif est de voir com-

ment le système se comporte en cas de charge très dynamique et aussi très forte. En fait, nous

voulons répondre à la question suivante : "Notre système pourra t-il traiter le maximum de tran-

saction sous la limite de temps de réponse imposée avec une charge très dynamique ?" Qu’en

sera t-il du coût ?

Toutefois, avoir un système soumis à un tel stress peut être rare dans la réalité, mais cette ex-

périence nous donne une idée sur la robustesse de nos algorithmes. Nous avons conduit cette

expérience en faisant apparaître des pics de charge (10 exactement) à des intervalles de l’ordre

5000 unités de temps (de simulation). Le temps de réponse maximal étant fixé à 800 unités de

temps. Nous pouvons voir les résultats sur la Figure 5.6. Il apparaît que le système parvient à

maintenir un temps de réponse maximal sous la barre limite fixée pour la plus part des transac-

tions, mais effectue beaucoup de déplacements de données pour y arriver. Et ce grand nombre

de déplacement a un coût qui se traduit par la quantité relativement importante de transactions

qui s’exécutent avec une latence se situant au delà de la limite fixée. Certaines transactions ont

même des latences très largement au dessus : 1500 unités de temps. Toutefois, ce coût est accep-

table parce que le système parvient à traiter 98,3% des transactions en dessous de 1000 unités de

temps de simulation. Par ailleurs il passe 99,4% de son temps dans le traitement des transactions

et seulement 0,6% du temps à faire de la migration. La valeur du percentile 95 est à 809,145. Ce

dernier chiffre signifie que par rapport à un objectif de temps de réponse maximal de 800 unités

de temps, la plus part des transactions sont traitées sous cette limite. Tous ces résultats montrent

Gestion des fluctuations de la charge transactionnelle 54

que les algorithmes que nous proposons permettent au système de réagir efficacement face aux

pics de charge.

0

500

1000

1500

2000

2500

0 10000 20000 30000 40000 50000 60000 70000 0

100

200

300

400

500

600

700

800

900

1000

1100

1200

Tem

ps

de

Rep

on

se (

un

ites

de

sim

ula

tio

n)

Ev

olu

tio

n d

e la

ch

arg

e (#

cli

ents

)

Dates (unites de simulation)

Evolution du temps de Reponse sur les noeuds DB

pic2

pic5

Sur DB0Sur DB1Sur DB2Sur DB3Sur DB4Sur DB5Sur DB6Sur DB7Sur DB8Charge

FIGURE 5.6: Évolution des temps de réponse dans le système avec un workload très dynamique

5.4.2.3 Consolidation des ressources

L’économie ou l’optimisation de ressources est un de nos objectifs majeurs. Notre système a la

capacité de s’étendre en ajoutant de nouvelles instances (VM), alors l’optimisation consiste à

enlever les ressources devenues inutiles ; c’est la consolidation et elle s’opère durant les périodes

où la charge est globalement faible. La fenêtre d’observation pour confirmer la constatation

qu’une charge est faible est volontairement plus longue pour éviter des prises des décisions

hâtives. C’est-à-dire enlever des nœuds et devoir en rajouter tout de suite après. Ainsi, dans cette

expérience, nous avons procédé à une augmentation graduelle et régulière de la charge jusqu’à

atteindre une forte valeur, puis nous défalquons brusquement 90% de la charge. Nous avons en

fait arrêter 90% des clients. Puis nous avons laissé le système continuer à tourner pendant assez

de temps pour observer l’évolution du nombre d’instances de nœud base de données (BD). Les

résultats obtenus sont montrés sur la Figure 5.7. La courbe en rouge montre l’évolution de la

charge et la courbe en vert montre l’évolution du nombre d’instances de nœud base de données.

Nous pouvons voir clairement que le nombre nœud a tendance à diminuer quand la charge

disparaît. Ce résultat est important dans le contexte d’un environnement Cloud où on paie-à-l’

usage, c’est-à-dire qu’on dépense en fonction de la quantité de ressources (machines) utilisées.

Si nous parvenons alors à adapter l’évolution de la consommation aux besoins réels, il s’en

suit alors une minimisation des dépenses. Au delà de l’économie des dépenses, une économie

en consommation d’énergie est aussi réalisée ; ce qui rejoint un objectif plus globale qu’est le

green computing.

Gestion des fluctuations de la charge transactionnelle 55

0

200

400

600

800

1000

1200

0 10000 20000 30000 40000 50000 60000 70000 80000 0

5

10

15

20

Evolu

tion d

e la

char

ge

Nom

bre

de

noeu

d D

B

Date (unites temps de simulation)

ChargeEvolution du nombre de DB

FIGURE 5.7: Consolidation du nombre de nœuds BD avec la baisse de la charge

5.5 Conclusion

Dans ce chapitre, nous avons proposé une gestion de la charge transactionnelle fluctuante. Cette

charge transactionnelle est produite par les applications clientes via les interactions entre utili-

sateurs. Ces utilisateurs ayant des tendances à agir en groupe sur certaines données, il apparaît

des surcharges transactionnelles sur des portions de données distinctes. Mais avant que la charge

n’arrive sur la couche des données, elle est traverse la couche de routage.

Ainsi, nous avons d’abord proposé une solution pour absorber la surcharge transactionnelle sur

un intergiciel distribué qui s’occupe du routage. Ensuite, nous avons proposé une solution pour

absorber la surcharge au niveau de la couche des données. La méthode d’absorption de la charge

passe par une détection d’une situation de surcharge, d’une identification de l’origine (sur qui/-

quoi la charge est concentrée) puis une répartition de cette charge pour l’absorber. Pour garder

la fluidité dans l’utilisation du système et sa rapidité, nous avons tenu compte de la structure

des interactions entre utilisateurs en exploitant les caractéristiques de notre type d’applications

cible. Ceci nous permet d’effectuer des migrations de données qui résolvent les pics de charge

tout en gardant la structure des interactions. Notre solution a aussi comme atout important d’op-

timiser l’usage des ressources de traitement et de stockage. En effet, en s’appuyant sur notre

mécanisme de partitionnement dynamique, nous parvenons à étendre le système au besoin mais

aussi à le consolider si nécessaire. Ce faisant, seule est utilisée la quantité de ressources néces-

saire pour respecter les seuils de performances fixés. La série d’expériences réalisées montre la

faisabilité et l’intérêt de notre solution. Les résultats obtenus sont encourageant et ont fait l’objet

de publications [GSN12], [GSN14a], [GSN14b].

Chapitre 6

Modèle d’exécution des transactions

Dans ce chapitre, nous proposons deux approches pour la gestion des transactions.

La première approche exploite la structure des interactions entre utilisateurs pour regrouper dy-

namiquement les données et garder sur un même noeud les données sollicitées dans les mêmes

interactions. Cette approche s’appuie sur le partitionnement dynamique que nous avons présenté

dans le chapitre 4.

Regrouper les données pour traiter les transactions sur un seul nœud permet d’éviter les tran-

sactions distribuées qui nécessitent des protocoles de terminaison coûteux en communication et

en latence. Autrement, le traitement sur un seul nœud favorise le passage à l’échelle et le paral-

lélisme et semble être adéquat pour les types de transactions (courtes) que nous gérons et qui

sollicitent de faible portion de données. La deuxième approche exploite les classes d’accès des

transactions. C’est-à-dire que les transactions qui accèdent aux mêmes données ou ont au moins

une donnée sollicitée en commun, sont regroupées en amont puis exécutées ensemble selon un

ordre défini. Dans cette approche, les données sont partitionnées et placées sur un ensemble de

nœuds base données et une classe d’accès peut être assimilée à une cible. Dans les sections sui-

vantes, nous présentons en détails ces deux approches avec les différents algorithmes y afférant

et leurs validations expérimentales.

6.1 Modèle d’exécution par regroupement des données

Le principe de base de ce modèle d’exécution est que toutes les données qu’une transaction

manipule doivent se trouver sur le même nœud BD. Ce principe est motivé par la besoin d’avoir

des transactions locales à un nœud. Notre mécanisme de placement dynamique des données est

autonome et fonctionne dans l’optique de satisfaire ce principe. Ainsi, toutes les données d’une

cible sont localisées sur un même nœud. Rappelons qu’une cible est constituée de l’ensemble

des données manipulées au cours des interactions d’un groupe d’utilisateur. Une cible a une

56

Modèle d’exécution des transactions 57

taille et une charge qui dépendent du nombre d’utilisateurs interagissant et de la densité des

interactions. Une cible a aussi une durée de vie qui correspond à la période pendant laquelle le

groupe d’utilisateurs interagissent.

6.1.1 Routage

Une transaction est émise d’une application cliente vers un routeur. Elle est transmise via un

message spécifique vers le routeur, et la transaction est représentée par une structure de données

comprenant plusieurs informations. Ces informations sont entre autres l’identifiant de l’utilisa-

teur ayant initié l’action, l’identifiant des différents utilisateurs dont les données seront lues ou

modifiées par la transaction, le contenu de la transaction (ce qui doit être effectivement fait sur

les données) et l’identifiant de la transaction. D’une manière basique, le routage d’une transac-

tion consiste tout d’abord à localiser les nœuds BD contenant les données à manipuler par la

transaction puis d’y envoyer la transaction pour exécution. Dans notre contexte, les transactions

manipulent des cibles et nous prenons soin de maintenir les données d’une cibles sur le même

nœud BD. Le routage, dans ce modèle d’exécution, consiste tout d’abord à identifier les cibles

manipulées par la transaction puis déterminer sur quel nœud BD la transaction sera envoyée

pour y être exécutée. La détermination de ce nœud dépendra du nombre de cibles concernées et

de leur emplacement. Dans tous les cas, le processus de routage devra conduire à une exécution

sur une seul nœud BD. La Figure 6.1 résume le déroulement de ce modèle d’exécution.

Nous avons doté les routeur de diverses fonctions pour leur permettre de mener leur processus de

routage. Ainsi, quand une transaction arrive sur un routeur, celui-ci commence par tester si cette

transaction est multi-cible ou mono-cible. C’est-à-dire si la transaction touche une seule cible

ou plusieurs cibles. Pour ce faire, le routeur utilise la fonction bundleSorM(String[] tabData).

Cette fonction exploite la liste des données sollicitées par la transaction, à savoir tabData, pour

demander au moniteur des cibles si ces données sont sur une même cible ou pas. Notons que le

moniteur des cibles considèrera une données non encore marquée dans une cible, comme étant

le seul élément de sa propre cible. Une fois que le routeur a la réponse sur le caractère mono ou

multi-cibles de a transaction alors il opère selon le cas.

6.1.2 Cas des transactions mono-cible

Dans ce cas la transaction s’exécutera sur un seul nœud BD car les données de la cible sont

sur un seul nœud BD. L’enchaînement des étapes du processus de traitement des transactions

mono-cible est décrit sur la Figure 6.2. Le routeur connait sur quel BD envoyer la transaction en

interrogeant son index de localisation avec la fonction getDB(String DataId). Cette fonction sera

appelée avec une seule des données touchées par la transaction, le résultat est le même quelle

que soit la données prise. A la suite, le routeur envoie la transaction vers le nœud BD où elle

Modèle d’exécution des transactions 58

FIGURE 6.1: Logigramme du modèle d’exécution des transactions

doit s’exécuter.

Pour ce qui est de l’exécution proprement dite, chaque nœud BD dispose de son propre SGBD

en local, ce qui lui permet de pouvoir exécuter avec cohérence la transaction reçue. Notons

qu’une fois le routeur envoie la transaction sur le nœud BD, la transaction est prise en compte

par le moniteur de cibles qui marque la nouvelle interaction en mettant en à jour la fréquence de

Modèle d’exécution des transactions 59

FIGURE 6.2: Scénario de traitement des transactions mono-cible

visite des arcs concernés.

6.1.3 Cas des transactions multi-cibles

Le routeur récupère les cibles en interrogeant le moniteur des cibles. L’ensemble de ces cibles

ainsi récupérées forment une toute nouvelle cible, plus grande. Pour respecter le principe du

modèle d’exécution qui est d’avoir les éléments d’une cibles sur le même nœud BD, alors le

routeur vérifie si les composantes de la nouvelle cible sont sur le même nœud BD ou pas comme

indiqué sur la Figure 6.1. Cette vérification est réalisée via une fonction et en interrogeant l’index

de localisation des données. Si les cibles sont sur le même DB alors la transaction est routée

vers ce nœuds BD et le processus de routage et d’exécution se font comme pour le cas d’une

transaction mono-cible, décrit ci-haut. Sinon si les cibles sont sur différents nœuds BD, alors

le routeur procède d’abord au regroupement des différentes cibles composantes de la nouvelle

cible. Ce regroupement se fait comme décrit dans la section suivante.

6.1.4 Processus de regroupement des données

Quand un routeur reçoit une transaction qui requiert plus d’une donnée, alors ce routeur interroge

le moniteur des cibles pour connaître la ou les cibles sollicitées. Si c’est plusieurs cibles, l’en-

semble de ces cibles forme un graphe temporaire (Γβw(T )) qui les connecte toutes. Ce graphe

est obtenu par la fusion des k-core représentant les cibles incluses dans la transaction. Nous

distinguons deux cas selon que les cibles se trouvent sur le même nœud BD ou non. Nous do-

tons les routeurs de fonctions leur permettant de savoir si les cibles sont sur un même nœud ou

pas. En effet, notre partitionnement est tel que toute cible est localisée sur un seul nœud, alors

il suffit de connaître une données appartenant à une cible, pour connaître l’emplacement de la

cible en interrogeant l’index. Nous utilisons ce principe pour un définir une fonction qui permet

au routeur de savoir si un ensemble de cibles sont le même nœud ou pas et, le cas échéant, de

Modèle d’exécution des transactions 60

savoir sur quels nœuds sont les différentes cibles.

Si toutes les cibles sont sur le même nœud BD, alors la transaction qui les sollicite est routée

vers ce nœud BD. Ce cas est similaire à celui d’une transaction qui manipule une seule cible.

Autrement, c’est-à-dire que les cibles sont situées sur différents nœuds BD, alors leur regroupe-

ment sur une seul nœud BD est fait avant que la transaction ne soit routée vers ce nœud BD. Ce

regroupement se fait comme suit :

1. Le routeur coordonnateur (cf. section 3.3.2), en collaboration avec le moniteur de cibles,

récupère la description de chaque cible impliquée sur chaque nœud BDi et effectue des

opérations de fusion pour obtenir le graphe temporaire Γβw(T ) qui couvre l’ensemble des

données sollicitées.

Γβw(T ) = {β1w, β

2w, ...., β

nw} (6.1)

Puis, le coordonnateur s’assure que la charge relative à Γβw(T ) n’excédera pas la capacité

maximale d’un noeud. Cela est possible parce que le coordonnateur peut connaître la

charge de chaque nœud BD, de chaque cible ou de chaque donnée d’une cible grâce à

des fonctions que nous avons implémentées sur les nœuds BD (voir chapitre 5). Si la

taille de la cible est trop grande, alors elle peut être réduite. Pour ce faire, les données les

moins fréquemment utilisées et non sollicitées par la transaction courante sont exclues de

Γβw(T ). Le graphe Γβw(T ) est réduit en gardant seulement les arcs correspondant aux

transactions les plus récentes (i.e., en réduisant la valeur de la fenêtre temporelle ω).

2. En se basant sur la taille du graphe temporaire Γβw(T ), le routeur choisit le nœud BDi

approprié qui minimise les transferts de cibles depuis les autres nœuds BD et qui a suffi-

samment de ressources pour prendre en charge la transaction en cours. Si il n’y a aucun

nœud BD qui a assez de capacité pour gérer l’ensemble Γβw(T ), alors le routeur initia-

lise une nouvelle instance de nœud BD pour le prendre en charge. Nous supposons qu’il

est toujours possible d’ajouter de nouvelles instances de nœud parce que l’environnement

de déploiement cible est le Cloud où les ressources sont supposées "illimitées". Mais, si

toutefois nous nous trouvons dans une situation où il n’est pas possible d’initialiser une

nouvelle instance alors les cibles qui composent Γβw(T ) sont laissées à leur place et la

transaction en cours sera exécutée telle qu’elle, c’est-à-dire de manière distribuée. Le trai-

tement d’une transaction distribuée nécessite qu’un routeur, en l’occurrence en charge de

la dite transaction, assure la coordination de l’exécution. Le coordinateur utilisera un pro-

tocole de validation distribuée, le 2PC (two phase commit). Ce protocole est tout à fait

adapté à notre contexte puisque les transactions dont nous faisons face sont en général

courtes, donc le risque d’attentes longues est faible.

Pendant le traitement d’une transaction distribuée, le routeur s’occupe exclusivement de

cette transaction et les autres transactions attendront que celle distribuée soit terminée

pour être prises en charge. Notons toutefois que ce cas est rare dans le système parce que

l’ajout d’une nouvelle instance de nœud est presque toujours possible dans le Cloud.

Modèle d’exécution des transactions 61

3. Une fois le nœud initialisé, le routeur déclenche le déplacement des cibles de Γβw(T ).

L’initialisation d’un nouveau nœud se fait via des primitives offertes par l’infrastructure

IaaS (voir chapitre 5). Nous préconfigurons des machines virtuelles (VM) avec différents

rôles (DB ou autres) et l’ajout d’un nouveau nœud se fera en utilisant une image de ces

VM préconfigurées. Cette opération se fait assez rapidement mais sa mise en œuvre peut

paraître longue comparée à la durée moyenne des transactions dont nous faisons face.

Par conséquent, pendant le fonctionnement de notre système, pour chaque type de nœud,

nous avons déjà une VM prête et en état de veille, dont l’intégration au système se fera

par son réveille et se fera suffisamment rapidement pour ne pas retarder le traitement des

transactions.

Le mécanisme de transfert d’une cible se fait à la demande des différentes parties de cette

cible. Nous décrivons en détails ce mécanisme dans la section 5.3.3.

6.1.5 Validation expérimentale : Évaluation du regroupement des données

Nous validons l’approche du regroupement des données à travers un ensemble d’expériences

qui évaluent les performances globales de notre approche.

6.1.5.1 Environnement expérimental

Nous avons implémenté un prototype sur un cluster composé de 5 nœuds avec une capacité to-

tale de 60 Go de RAM, 21 CPU de 2.3 GHz, et 100 Go d’espace disque. Pour implémenter la

couche des données de notre architecture, nous utilisé Redis[Red14] qui est une base de don-

nées clé-valeur open source. Le modèle de données de Redis est semblable à un dictionnaire qui

mappe des clés à des valeurs, ce qui lui confère une certaine rapidité. Redis supporte principa-

lement les types de données suivantes : les chaines de caractères, les listes, les collections de

chaînes de caractères (non répétitives, non ordonnées ou ordonnées) et les tables de hachage où

les clés et les valeurs sont des chaînes de caractères. Redis supporte une large gamme de client

pour la plupart des langages de programmation à travers des API telles que Jedis [Xetis] pour

Java (que nous utilisons pour ce prototype).

Nous utilisons Redis pour le stockage en local sur chaque nœud base de données et l’index. De

plus, nous utilisons le système storm [Apa14] pour implémenter les différentes entités de notre

système et leurs communications.

Storm est un système de traitement distribué en temps réel et open source. Storm offre une

abstraction d’implémentation d’un fonctionnement décrit sous la forme d’une topologie, à base

d’évènements et déployé sur un cluster de nœuds. Une topologie de storm est un graphe où les

nœuds sont des opérateurs qui encapsulent la logique du traitement à faire et les arcs modélisent

Modèle d’exécution des transactions 62

la circulation du flot de données entre les opérateurs. Avec Storm, les nœuds sont appelés com-

posants. L’unité d’information échangée entre composants est appelée tuple, qui est une liste de

valeurs. Il y’a deux types de composants : (1) les spouts, qui modélisent les sources des évè-

nements (encapsulés sous forme de flots de tuples), et (2) les bolts, qui encapsulent la logique

de traitement (de tuples) spécifique telle que le filtrage, la transformation, les accès en base de

données, etc.

Ainsi, nous avons utilisé les bolts de Storm pour implémenter les nœuds routeur, moniteur de

cibles, monteur de ressources, base de données (noeuds BD au dessus de la couche de stockage).

Nous avons utilisé les spout de Storm pour implémenter la couche des applications clientes. La

communication se fait par message, nous avons implémenté différents types de messages pour

assurer une bonne interaction entre tous les nœuds. Les messages ont différents paramètres que

sont leur type, leur origine, leur destination, le contenu, leur date d’envoi, etc. Le graphe d’in-

teractions, le des niveaux de charges des ressources, l’index global (couche de routage) ou les

index locaux au nœud BD sont implémentés avec des structures de données. Storm est tolérant

aux pannes et assure une délivrance des messages à travers ZeroMQ [zerrg]. Il utilise Zookeeper

[PMFB10] pour une surveillance du système et garantir une reprise à la suite d’une panne d’un

nœud. Storm convient parfaitement à notre besoin d’implémenter des algorithmes de traitement

transactionnel sur des données distribuées. Storm apporte une simplicité dans le déploiement

sur un cluster de machines et sont intégration avec la base de données Redis n’est pas difficile.

En outre, Storm offre aussi un mécanisme de Parallélisation facile à mettre en œuvre pour les

exécutions (en clonant un bolt).

6.1.5.2 Spécification de la charge applicative et configuration

La charge applicative est composée de transactions accédant à plusieurs données d’utilisateurs.

Ces accès sont distribués suivant une loi normale pour refléter les caractéristiques de la charge

applicative, comme montré par l’étude menée dans [APBC13]. Nous avons généré un ensemble

de matrices de données de différentes tailles, chacune d’entre elles correspondant à une distri-

bution gaussienne avec ses propres moyenne et variance pour refléter l’hétérogénéité des tran-

sactions provenant des utilisateurs. Pour chaque distribution gaussienne, nous avons aussi prévu

un intervalle de valeur où appartiennent les données (identifiants des utilisateurs) dans le souci

de contrôler le nombre de transactions émises par les utilisateurs correspondants.

6.1.5.3 Impact du regroupement des partitions

Dans cette expérience, nous évaluons l’impact que peut avoir le regroupement des données sur

le traitement des transactions (surtout celles distribuées). Pour les besoins de comparaison, nous

Modèle d’exécution des transactions 63

0

50

100

150

200

0 500 1000 1500 2000 2500

Late

nces

(ms)

Numero de transaction

1 Instance seule de Redis

(A) Déploiement avec un seul nœud BD

0

50

100

150

200

0 500 1000 1500 2000 2500

Lat

ence

s (m

s)

Numero de transaction

4 Instances Redis & Regroupement

(B) Déploiement avec quatre nœuds BD

FIGURE 6.3: Instance locale vs Traitement distribuée avec regroupement

faisons deux séries d’expériences avec ou sans regroupement des données. La première ex-

périence sert de référence pour la comparaison avec le cas d’un déploiement distribué. Nous

désactivons le regroupement des données dans cette expérience, et toutes les données sont sto-

ckées sur un seul noeud BD. Ainsi, toutes les transactions sont locales. La figure 6.3a montre les

résultats obtenus. Dans la deuxième expérience, les données sont uniformément partitionnées

et distribuées sur quatre nœuds BD. Nous activons la stratégie de regroupement des données

(cibles). La charge reste la même que dans la première expérience. L’algorithme de regroupe-

ment des cibles contrôle la taille et le placement des partitions. Il effectue une série de décisions

de regroupement durant l’expérience. A terme, chaque cible est localisée sur un nœud. Une stra-

tégie d’équilibrage de la charge est active pour gérer les pics de charge potentiels (ce cas est

plus spécifiquement étudié dans le chapitre 5). La Figure 6.3b montre les résultats obtenus. Ces

deux expériences démontrent que notre système est capable de traiter les transactions sur un

déploiement distribué. Plus précisément, dans la deuxième expérience (utilisant 4 noeuds BD)

le traitement s’effectue avec des latences plus élevées que dans la première (qui utilise un noeud

BD) du fait de la charge additionnelle provoquée par le regroupement. Toutefois, la différence

en termes de latence des transactions reste relativement petite. Ceci illustre que notre stratégie

de regroupement est assez efficace en cela qu’elle permet un traitement distribué tout en offrant

des temps de réponse proches d’une exécution centralisée. Notons que dans ce expérience, les

charges appliquées ne sont pas trop élevées, l’objectif étant d’étudier l’efficacité du fonctionne-

ment distribué de notre solution.

Le gain global de notre approche est que notre stratégie permet d’avoir des niveaux de latence

proches des valeurs obtenues avec des traitements locaux. Ce bénéfice est d’autant plus im-

portant que pour les transactions sollicitant les mêmes cibles plusieurs fois, nous parvenons à

paralléliser les exécutions ce qui améliore un peu plus les latences et réduit la concurrence.

Toutefois, nous remarquons que si les cibles évoluent très rapidement, notre stratégie va provo-

quer beaucoup d’opérations de regroupement, ce qui a un impact sur la latence moyenne globale.

Nous étudions cette situation dans la section suivante 6.1.5.4.

Modèle d’exécution des transactions 64

6.1.5.4 Impact de la fluctuation des cibles

La fluctuation des cibles est due à leur durée de vie. Les cibles se forment et sont restent actives

pendant une période finie. Quand cette période expire, elles se décomposent et de nouvelles

cibles se forment. La formation de nouvelles cibles se fait par une recomposition des différents

éléments provenant des cibles dont la durée de vie est terminée. Ce phénomène est lié aux chan-

gements d’intérêts des utilisateurs. Ainsi, pendant la recomposition des cibles nos algorithmes

peuvent opérer des transferts de données entre des nœuds BD. L’objectif des expériences dé-

crites dans cette section est montrer l’impact que ces fluctuations des cibles ont sur la latence

des transactions et le coût des transfert de données.

Impact de la fluctuation des cibles sur la latence : Dans cette expérience, nous maintenons

une charge globale constante et faisons varier la durée de vie des cibles.

Nous faisons dix rounds de l’expérience avec, pour chaque round, une durée de vie différente

pour les cibles. Ces durées varient de 100 à 1000 secondes respectivement pour les rounds 1 à 10.

Pour chaque round nous prenons la valeur latence de la transaction correspondant au percentile

95. Cette valeur correspond à la latence qui est telle que, en faisant un tri dans un ordre croissant

(par exemple) de toutes les latences, seule 5% des valeurs mesurées sont supérieures à elle.

Ce percentile 95 permet d’avoir une bonne lecture de la distribution des latences en ce sens

qu’il nous dit quel est le niveau de latence de l’essentiel des transactions (95% d’entre elles).

Les résultats obtenus sont montrés sur la figure 6.4a. Nous pouvons voir clairement que plus

courte est la durée de vie des cibles, plus importante est la latence correspondant au percentile

95. Ceci signifie que le niveau de latence est plus élevé pour des cibles qui se recomposent

fréquemment. Les nombreuses opérations de regroupement des cibles ralentissent le traitement

des transactions. Nous notons que quand la durée de vie est relativement longue(plus de 300

secondes), le niveau des latences devient faible et demeure dans l’intervalle [120ms, 140ms].

Cette observation conforte que notre stratégie est bonne dans la mesure où une session dans les

applications de médias sociaux dure au moins 5 minute en général comme montré dans l’étude

[BRCA09]. Par conséquent la durée de vie des cibles est en général au dessus de 300 secondes.

Impact de la fluctuation des cibles sur le coût du transfert des données : Dans cette expé-

rience, nous quantifions le coût financier (exprimé en $) de notre stratégie de regroupement de

cibles. Nous considérons le cas où notre solution est déployée sur une infrastructure de Cloud

computing. Dans de tels environnements où on paie à l’usage, la facturation des ressources

(machines, stockage, bande passante) est basée sur le taux d’utilisation. Puisque notre solution

nécessite de déplacer des données d’une machine à une autre, nous nous focalisons sur le coût

des échanges de données pendant que le nombre de machines que nous utilisons reste fixe. Nous

mesurons d’abord la quantité de données transférée, puis nous déduisons le coût (en $). Nous

Modèle d’exécution des transactions 65

100

120

140

160

180

200

220

240

260

100 200 300 400 500 600 700 800 900 1000

Perc

enti

le 9

5 (

ms)

Duree de vie des cibles (s)

Impact de la duree de vie des cibles sur la latence

Percentile 95 vs duree de vie des Cibles

(A) Impact sur la latence

0

10

20

30

40

50

100 200 300 400 500 600 700 800 900 1000 0

0.2

0.4

0.6

0.8

1

1.2

Quan

tite

de

donnee

s dep

lace

es (

% )

Cout

($)

Duree de vie des cibles (s)

% de la base transferee Evolution du Cout($) - Base de 10GB

Evolution du Cout($)- Base de 1TB

(B) Impact sur le coût du transfert desdonnées

FIGURE 6.4: Impact de la fluctuation des cibles

faisons varier la durée de vie des cibles de 100 à 1000 secondes. Pour une durée de vie fixée,

nous exécutons la même charge et mesurons la quantité totale de données transférée.

Sur la Figure 6.4b, nous avons les quantités des données transférées exprimées sous forme d’un

ratio par rapport à la taille de la base totale.

En plus, nous avons pris comme référence Amazon Web Services (EC2 et S3) [Ama14] pour la

facturation. De tels services facturent 0.01 USD pour le transfert de 1GB de données entre deux

machines situées dans la même région (i.e. le même Datacenter).

En nous basant sur la taille réelle de la base, nous avons calculé le coût pour de plus grandes

bases (10GB et 1TB) et les résultats sont montrés sur la figure 6.4b. Nous observons que le coût

du transfert de données est négligeable pour des durées de vies des cibles dépassant 200s. Cela

est due au fait que ces durées de vies sont assez longues et il y’a peu de transferts de données.

Cependant pour des bases de données de taille dépassant plusieurs TB et avec de des durées

de vie de cibles faibles (moins de 200s), le coût des déplacements de données peut atteindre

quelques dizaines de dollars ($). En effet, dans de tel contextes, les transferts de données de-

viennent plus importants. Notons que dans les applications de média sociaux, la durées de vie

d’une session dure au moins une minute. En plus, même si les utilisateurs changent d’intérêts

leur groupe d’interaction ne change pas trop rapidement. Par conséquent, la recomposition des

cibles (en cas de durées de vies courtes) n’entraînera pas forcément des déplacements de don-

nées entre noeuds. Ainsi, notre solution pour le regroupement des cibles n’implique pas des

coûts supplémentaires significatifs sur une plateforme de Cloud.

6.1.6 Discussion

Cette stratégie permet d’avoir un traitement des transactions en maximisant les exécutions en

locale. C’est-à-dire que nous regroupons les données sollicitées par les mêmes transactions et

l’exécution se fait sur un seul site. Ceci permet de passer à l’échelle horizontalement (section

Modèle d’exécution des transactions 66

3.8) et aussi de faciliter les interactions entre utilisateurs en rendant le traitement plus rapide.

Toutefois, cette approche ne prend pas en compte certains aspects importants qui peuvent amé-

liorer le traitement ou le passage à l’échelle. Le regroupement des cibles est effectué pour

certaines transactions entrantes. Il peut être coûteux dans la mesure où les opérations de véri-

fication et de calcul des décisions de placement se succèdent pour beaucoup de transactions.

Pourtant ces opérations et calculs peuvent être effectués pour un groupe de transactions arrivant

à la même période. Cela permet d’avoir des décision de placement aboutissant à un résultat plus

stable. Autrement dit, les décisions de placement sont prises pour un ensemble de transactions

et reste valables pendant toute la durée de vie des cibles correspondantes. L’exécution indivi-

duelle des transactions s’accompagne de plusieurs échanges pour chaque transaction. En effet,

il y’a au moins deux messages échangés entre la couche de routage et la couche de stockage et il

peut y avoir plusieurs messages échangés sur la couche de routage elle même. Quand le nombre

de transactions devient très important, le coût de la communication devient aussi important. Ces

observations nous poussent à proposer des alternatives pour améliorer le fonctionnement de la

couche de routage et le modèle d’exécution des transactions.

En effet, nous proposons de regrouper les transactions sollicitant les mêmes cibles par fenêtre

de temps, puis nous les ordonnons et les traitons par bloc. Ce mode de fonctionnement agrège

les décisions de placement des cibles et réduit le coût de la communication entre les couches

de routage et de stockage. En plus, toutes les opérations nécessaires à un groupe de transac-

tions sont traitées en une seule fois, ce qui réduit les chances de cascades. Nous détaillons cette

deuxième approche dans la section 6.2.

6.2 Modèle d’exécution par regroupement des transactions

L’approche proposée [SNI15, SNA13] est guidée par le fait que le regroupement des transac-

tions qui sollicitent les mêmes données peut simplifier une partie significative du traitement.

L’idée est d’exploiter la possibilité de traiter un groupe de transactions en gérant la concurrence

en amont par un ordonnancement. Intuitivement, cette forme de traitement est plus rapide que le

traitement des transactions une à la fois et réduit le nombre de messages envoyés sur la couche

d’exécution.

Plus précisément, si chaque application se connecte directement à la base de données, alors cette

dernière peut devenir un goulot d’étranglement et surchargée. Plutôt, les requêtes des applica-

tions peuvent être collectées et regroupées au niveau de la couche de routage. Ainsi, les requêtes

de connexion sur la base sont minimisées. Notre solution fonctionne en deux étapes : une pre-

mière dite d’ordonnancement suivie d’une seconde dite d’exécution. L’étape d’ordonnancement

a pour objectif de regrouper les transactions sollicitant les mêmes données peut importe leur lieu

d’origine. Ce regroupement s’accompagne d’un ordonnancement des transactions qui s’appuie

sur un graphe de précédence (voir section 6.2.2.1).

Modèle d’exécution des transactions 67

6.2.1 Modèle d’exécution

Les nœuds RN s’occupent du routage et de l’ordonnancement des transactions. Les nœuds BD

quant à eux reçoivent les transactions et les exécutent. Dans ce modèle d’exécution, les données

sont supposées déjà réparties en fonction des cibles. Chaque cible est identifiée et un nœud de

la couche d’exécution en est responsable, c’est-à-dire qu’il est le seul habilité à exécuter les

transactions en direction de cette cible.

Les transactions arrivent à n’importe quel point de la couche de routage et d’ordonnancement

et par la suite elles seront collectées et groupées en fonction de leurs cibles pour exécution. Par

exemple, sur la Figure 6.5 les transactions TB , TBC , TAC et TAB sont groupées sur RN1 même

si elles ont été reçues par RN2 et RNk. Le groupe d’interactions d’où elles sont issues a pour

cible CA,B,C . La couche de routage et d’ordonnancement est responsable de l’équilibrage de la

FIGURE 6.5: Exemple de transactions entrantes

charge et de l’absorption des pics de charge. Pour effectuer le regroupement des transactions,

les routeurs utilisent un modèle de communication efficace décrit à la section 6.2.2. Les RN se

répartissent leurs tâches (regroupement et ordonnancement) avec l’aide d’une structure de don-

nées appelée jeton (voir section 6.2.2.1) qui leur donne, à tour de rôle, un accès exclusif pour

envoyer des transactions vers la couche d’exécution.

Sur la couche d’exécution, chaque nœud BD peut gérer les transactions destinées à une ou plu-

sieurs cibles dont il a le contrôle. Puisque les transactions sont regroupées et bien ordonnées

depuis la couche de routage, la concurrence est déjà contrôlée. En recevant des transactions à

exécuter sur une ou plusieurs cibles, le nœud BD est le seul qui contrôle les transactions y af-

férent. Cette garantie est gérée depuis la couche de routage qui fonctionne de sorte que seul un

RN à la fois a la possibilité d’envoyer des transactions vers une cible (avec l’aide du jeton).

6.2.2 Regroupement des transactions

6.2.2.1 Modèle de communication

Nous structurons les nœuds RN sur un anneau comme montré sur la Figure 6.6. En procédant

ainsi, nous réduisons la surcharge du réseau et il devient plus facile de contacter un nœud avec

Modèle d’exécution des transactions 68

FIGURE 6.6: Schéma du modèle de communication

peu de messages.

Chaque nœud RN connait son successeur et peut communiquer avec lui à travers un jeton qui est

une structure de données. Ce jeton permet aux RN d’avoir un accès exclusif sur les métadonnées

d’une cible 1 et de soumettre leurs transactions. En réalité, nous gérons deux types de jetons :

jeton de traitement et jeton de transmission.

Les jetons :

a) Jeton de traitement : Un jeton de traitement est utilisé pour synchroniser les nœuds RN qui

désirent router des transactions accédant à la même cible au même moment. Un jeton de

ce type circule dans le sens contraire aux aiguilles d’une montre pour donner à chaque RN

un accès exclusif aux métadonnées nécessaires pour gérer les transactions d’une cible. En

réalité, un jeton de traitement τci est créé pour chaque cible ci et contient les métadonnées

relatives à ci. Quand un RN reçoit τci , il traite toutes les transactions qui attendent l’accès à ciet après relâche le jeton pour son successeur immédiat. Une fois que le RN relâche le jeton,

il doit attendre un tour complet de ce jeton pendant ce temps, il est en état idle concernant

τci . Pendant cette période idle, le RN construit et maintient le graphe des transactions (dé-

crit dans le paragraphe suivant) qui demandent l’accès ci. Plus précisément, chaque RN peut

garder une transaction dans un graphe local jusqu’à ce qu’il reçoive le jeton de traitement

correspondant (τci).

La Figure 6.6 montre une situation avec deux cibles et trois RN. Au début, RN1 acquiert

le jeton de traitement (losange vert), et donc doit traiter un bloc contenant cinq transactions

[T1, T2 − T3 − T4, T6] qui demandent la même cible CA,B,C . Une fois ce processus ter-

miné, le RN1 relâche le jeton pour RN2, qui n’a aucun bloc de transactions en attente. Par

conséquent, RN2 ne garde pas le jeton et le laisse passer vers RNk. Notons que pendant RN1

a le jeton de traitement pour la cible CA,B,C , RNk a le jeton de traitement pour la cible CX .

Ces deux RN traitent en parallèle les transactions concernant ces cibles dont ils ont les jetons

de traitement.

1. Une partition pouvant contenir une ou plusieurs cibles

Modèle d’exécution des transactions 69

b) Jeton de transmission : Un jeton de transmission se déplace dans le sens des aiguilles d’une

montre et est utilisé comme un moyen de transport par un RN pour envoyer des données

ou des transactions à un autre RN. Chaque RNi peut avoir son propre jeton de transmission

(disons fi) ou partager un unique jeton avec ses pairs. L’utilisation d’un unique jeton ou

plusieurs jetons de transmission dépendra de certains contextes que nous décrivons dans la

section 6.2.2.2. Contrairement à un jeton de traitement, un jeton de transmission est utilisé

pour faciliter une communication entre deux RN. Par exemple, dans la figure La Figure

6.6, le RN2, peut utiliser son propre jeton de transmission (losange rouge) pour envoyer T7

directement à RN1 ou RNk pour accélérer l’exécution de T7 selon l’un ou l’autre RN a le

bon jeton de traitement.

Graphe de transactions : Le graphe des transactions est construit sur la couche routage et

d’ordonnancement. Il partage certaines caractéristiques du graphe de sérialisation global (GSG)

utilisé dans [IDR10] et du modèle Blockchain utilisé dans le protocole Bitcoin [BBSU12]. La

lecture du graphe des transactions permet d’indiquer l’ordre d’exécution des transactions en

montrant, pour chacune d’entre elles, celle qui la précède et/ou celle qui vient après elle dans la

chaîne globale. Sur ce graphe, un nœud représente une transaction qui va être exécutée et un arc

indique un ordre de précédence entre deux transactions. Cet arc est dirigé d’une transaction vers

celle qui la suit immédiatement.

Le graphe est construit sur chaque RN pour ordonner les transactions en attente du bon jeton

FIGURE 6.7: Graphes de transactions, ordonnancement et cibles

de traitement. Quand une opération de regroupement est faite vers un RN, chaque RN envoie

son graphe local concernant la liste en formation comme nous le voyons sur la Figure 6.7 avec

Graphe_Cible(A,B,C) et Graphe_Cible(X). Puis la fusion de ces graphes locaux conduit à un

graphe global ordonné pour la cible. Dans l’exemple de la Figure 6.7 le résultat de la fusion

donne la Graphe_Cible(A,B,C), et Graphe_Cible(X) reste de son côté. Pour avoir ce regroupe-

ment, chaque RN qui reçoit le jeton de transmission peut y ajouter son graphe local des transac-

tions en attente d’une cible occupée. Nous décrivons dans la section suivante le fonctionnement

de nos algorithmes pour le regroupement des transactions.

Modèle d’exécution des transactions 70

6.2.2.2 Gestion de la cohérence

La gestion de la cohérence couvre la période allant de l’arrivée de la transactions sur la couche

de routage jusqu’à sa soumission à la couche d’exécution. Notre approche de gestion de cette

cohérence est de regrouper et ordonner les transactions qui touchent les mêmes cibles afin de les

soumettre en groupe pour exécution. Quand une transaction arrive sur un RN, soit elle est routée

vers la couche d’exécution, soit elle est insérée dans un graphe d’attente local mais cette attente

a un temps borné. Pourtant, un des objectifs du processus de routage est de minimiser la latence,

or garder une transaction dans un graphe d’attente peut conduire à l’effet inverse, c’est-à-dire

rallonger la latence. Il faut noter qu’en plus d’accélérer le processus de routage, la transmission

de transactions (entre RN) aide à paralléliser le traitement de la charge globale. En fait, plusieurs

RN peuvent envoyer toutes les transactions modifiant la cible ci au même RN qui va recevoir

τci . Ainsi, ils auront plus de disponibilité pour traiter les autres transactions relatives aux autres

cibles. Les transactions sont regroupées en utilisant les jetons, aussi bien ceux de traitement que

ceux de transfert. Nous proposons deux cas de figure pour la gestion des transactions : le cas des

transactions mono-cible et le cas des transactions multi-cibles.

Transactions mono-cible : Nous proposons trois algorithmes de base pour regrouper les

transactions mono-cibles : un modèle basé sur le piggybacking, un modèle basé sur l’anneau et

un modèle basé sur le temps (attente moyenne estimée).

a) Algorithme piggybacking : Cette stratégie marche avec seulement les jetons de traitement.

Ainsi, les jetons de traitement sont utilisés pour deux rôles : synchroniser l’accès aux mé-

tadonnées et servir de support pour l’envoi de transactions d’un RN à un autre. Le bénéfice

de l’utilisation d’un seul type de jeton est la réduction de la latence en même temps qu’on

réduit le surcoût lié à la communication pour le regroupement des transactions. Notre solu-

tion est telle que nous avons autant de jetons de traitement que de cibles. Ainsi, un RN peut

recevoir un jeton τci alors qu’il est entrain d’utiliser τcj . Dans de telles situations, le RN est

contraint de laisser τci pour un autre RN pour éviter les famines. Toutefois, en relâchant τci ,

le RN rallonge le délai de traitement des transactions qui étaient sur son graphe d’attente et

qui demandaient τci . Pour résoudre ce problème, toute transaction requérant un accès à piest attachée à τci , et transmise au prochain RN. Cette stratégie a l’avantage de regrouper les

transactions tout en partageant les jetons de traitement. En plus, elle garantit une utilisation

efficiente des jetons qui voient leurs rôles multipliés.

Toutefois, il est à noter que la stratégie du piggybacking est fortement couplée au processus

de synchronisation. De ce fait, elle aide à réduire la latence seulement pour ces transactions

qui sont situées sur un RN qui reçoit deux jetons ou plus alors qu’il n’a besoin que d’un seul.

Par conséquent, l’amélioration de la latence est biaisée et faible puisque de telles situations

sont presque rares.

Modèle d’exécution des transactions 71

C’est pourquoi, nous avons introduit une nouvelle solution basée anneau qui dissocie le pro-

cessus de synchronisation et celui de transfert.

b) Algorithme Basé-anneau : Le modèle basé-anneau utilise un jeton de transmission pour

transmettre ou regrouper les transactions. A la base, seulement un jeton de transmission

est partagé par tous les RN et pour toutes les partitions. Tout RN qui reçoit ce jeton y at-

tache ses transactions en attente. Rappelons que ces transactions en attente sont organisées

sur un graphe de précédence, donc bien ordonnées. Le jeton de transmission circule dans le

sens contraire aux aiguilles d’une montre pour agréger les transactions en attente jusqu’à ce

qu’il atteigne un RN qui a un jeton de traitement (disons τci). Ainsi, le RN retrouve toutes

les transactions relatives à la cible ci et les ajoute à son propre graphe et laisse le jeton de

transmission passer au RN suivant.

La stratégie basée-anneau fonctionne bien si le jeton de transmission atteint rapidement sa

destination (un RN possédant un bon jeton d’exécution). Ceci demande un anneau de petite

taille avec un faible temps de latence, c’est-à-dire quelques RN dans un réseau local. Pour

lever de telles contraintes de taille et de localité, nous avons conçu une solution de trans-

mission à un saut, qui s’appuie sur une estimation basée-temps de la localisation du jeton de

traitement. Ce procédé doit permettre le routage de transactions avec des anneaux larges.

c) Algorithme basé-temps : Dans cette stratégie chaque RN possède un jeton de transmission

qui peut joindre un RN spécifique en un saut. Les transactions sont regroupées en se basant

sur la localisation du jeton et le nombre de partitions requises. Pour ce faire, chaque RN

utilise un timestamp pour chaque jeton, TS(τpi), qui garde la dernière date à laquelle il avait

le jeton τpi en sa possession. De fait, quand le RNi relâche τpi il met à jour TSi(τpi). Ce

timestamp est utilisé pour estimer quand un RN va probablement recevoir à nouveau un

jeton après l’avoir lâché. Cette estimation est calculée en se basant sur le nombre de RN et

la moyenne glissante du nombre de transactions par RN (disons T ). En réalité, si νT est le

temps qu’il faut pour router T , alors le temps idle relatif à une partition pi de RNj est :

idle(pij)= (n − 1) ∗ νT + n ∗ λ) où λ représente la latence de transfert du jeton entre deux

RN et n le nombre de RN sur l’anneau. Le temps idle représente le temps d’un tour complet

du jeton. Nous définissons le temps d’attente restant, rt(pij) de RNj , considérant que τpi est

détenu dans RNk, comme suit :

rt(pij) = idle(pij)− [current_time()− TS(τpi)],

où current_time() est un appel de fonction qui retourne le temps actuel du système. En plus,

quand RNj reçoit une transaction T demandant pi, il détermine le temps restant rt(pij) pour

recevoir τpi et calcule le nombre de RN restant, k, qui vont recevoir le jeton avant lui, en

utilisant cette formule :

k = drt(pij)/(νT + λ)e.

Modèle d’exécution des transactions 72

Une fois cette valeur connue, RNj décide de garder T si jamais k = 1 ou de l’envoyer au

prochain RN qui va recevoir τpi sinon. En d’autres termes, un RN décide de garder une

transaction entrante qui modifie pi si jamais il sera le prochain RN qui va recevoir le jeton

τpi . Sinon, envoyer la transaction à un autre RN aide à réduire le temps de réponse.

Transactions multi-cibles : Nous décrivons dans cette section comment nous gérons les je-

tons de traitement pour prendre en charge le cas particulier des transactions multi-cibles. Quand

une transaction requiert plusieurs cibles, l’acquisition de tous les jetons correspondant peut de-

venir difficile puisque certains jetons peuvent être détenus ailleurs. Cette acquisition doit être

gérée efficacement pour éviter que le temps de réponse devienne trop important. Dans ce sillage,

nous proposons deux approches : une approche gloutonne que nous appelons eager et une ap-

proche indolente que nous nommons lazy. L’approche eager prend en charge les transactions

multi-cibles dès qu’elles arrivent, tandis que l’approche lazy retarde leur exécution dans le but

d’effectuer un traitement groupé et améliorer globalement la latence.

a) Approche Eager : Cette approche donne une priorité aux transactions multi-cibles. Par consé-

quent, une fois qu’une transaction T de ce type est détectée sur le graphe d’attente d’un RN

(disons RN1), alors RN1 envoie une alerte à tous les autres nœuds RN pour qu’ils entrent à

l’état idle pour le jeton de traitement correspondant et transfèrent rapidement ce jeton vers

RN1. En d’autres termes, tous les autres RN suspendent l’exécution de toutes les autres tran-

sactions demandant le même jeton de traitement.

Dès lors, le jeton de transmission est utilisé non seulement pour le transfert des transactions,

mais aussi pour notifier les RN de ne pas utiliser le jeton requis pour traiter T . En plus,

chaque RN gère son propre jeton de transmission. Pour détailler les étapes suivies pendant la

gestion d’une transaction multi-cibles, nous considérons la Figure 6.8. Supposons que RN4

FIGURE 6.8: Demande de plusieurs jetons de traitement

reçoit une transaction multi-cibles qui requiert à la fois ci et cj . Alors, grâce à l’algorithme

Modèle d’exécution des transactions 73

basé-temps, il identifie les RN ( RN6 et RN2 respectivement) qui ont en leur possession les

jetons de traitement τci (losange vert) et τcj (losange bleu). Une fois cette identification faite,

en utilisant son jeton de transmission, RN4 envoie à RN6 et RN2 un message spécifique

appelé message d’inhibition. Un message d’inhibition ordonne que tous les successeurs de

RN6 et RN2 ne doivent utiliser (ou garder) τci et τcj , même s’ils ont dans leur liste d’attente

des transactions relatives à ci et cj . De ce fait, RN4 inhibe les successeurs de RN6 et RN2 et

sera le prochain RN qui aura en sa possession les deux jetons τci et τcj . L’intuition derrière

une telle stratégie est de donner la priorité aux transactions multi-cible qui sont supposées

peu fréquentes. En plus, quand un successeur est inhibé, il doit transférer ses transactions en

attente de ce jeton en utilisant l’algorithme de regroupement. En d’autres termes, le processus

d’inhibition conduit en même temps à un regroupement des transactions ce qui atténue l’aug-

mentation de leur temps de réponse. Toutefois, quand le nombre de transactions multi-cibles

devient élevé, les transactions simples peuvent souffrir des longues attentes, et leur temps de

réponse rallongé. Pour minimiser ces longues attentes pendant l’occurrence de beaucoup de

transactions multi-cibles, nous proposons l’approche lazy que nous décrivons dans la section

suivante.

b) Approche Lazy : Cette approche introduit une asymétrie dans le rôle des RN. En fait, un

RN est chargé de regrouper et de router toutes les transactions multi-cibles qui arrivent sur

une fenêtre de temps. Il agit comme un leader par rapport aux autres RN qui doivent lui

envoyer toutes les transactions multi-cibles qu’il reçoivent. Une fenêtre de temps correspond

à la durée nécessaire à un jeton pour faire le tour complet de l’anneau. Ce rôle de gestion

des transactions multi-cibles n’est pas donné de façon statique à un RN, mais plutôt d’une

manière round robin à tous les nœuds RN. Ainsi, un noeud RN donne le rôle de leader à son

successeur une fois qu’il finit de router les transactions multi-cibles reçues dans la fenêtre

de temps considérée. La raison principale de cette façon de faire est d’équilibrer la charge

globale sur tous les nœuds RN et d’éviter les points de défaillance unique pour ce genre de

transactions. Cette approche utilise un seul jeton de transmission comme dans l’algorithme

de regroupement basé-anneau décrit plus haut. Le jeton de transmission sert à envoyer les

transactions multi-cibles vers le nœud RN leader. Pour expliquer étape par étape comment

le travail est fait, supposons que le RN0 vient juste d’être élu leader. De ce fait, le jeton de

transmission est en train de ramasser les transactions multi-cibles sur les nœuds RN1, RN2 et

ainsi de suite. A moins que le jeton de transmission atteigne encore RN0, chaque noeud RN

enlève de son graphe toutes les transactions multi-cibles et les ajoute au jeton. A la fin de la

fenêtre de temps considérée, c’est-à-dire quand le jeton arrive à RN0, le leader réquisitionne

tous les jetons nécessaires pour le traitement. Il faut noter que le leader peut prédire le temps

restant pour qu’il reçoive le jeton de transmission. En plus, il peut commencer à récupérer les

jetons de traitement relatifs aux transactions qu’il a directement reçues des client, avant que

le jeton de transmission ne lui ramène les transactions multi-cibles restantes. Cette prédiction

Modèle d’exécution des transactions 74

est possible grâce à notre algorithme basé-temps et elle accélère le processus de réquisition

des jetons de traitement.

En résumé, l’approche lazy introduit un délai pour alterner les exécutions de transactions sur

une cibles et celles multi-cibles, et ainsi empêche les sources de d’attente longue.

6.2.3 Validation expérimentale

Dans cette section nous validons par simulation notre approche de regroupement des transac-

tions. Nous utilisons l’outil SimJava [HM98]. Pour être le plus proche possible d’un système

réel, chaque client qui une transaction doit attendre les résultats avant d’en envoyer une autre.

Pour équilibrer les requêtes des clients parmi tous les nœuds RN, les clients utilisent un méca-

nisme de tourniquet pour envoyer une requête à un RN.

En plus, nous avons implémenté TranspeerToken [MLA+12] une solution qui utilise un anneau

pour router les transactions vers un ensemble de bases de données distribuées. L’objectif prin-

cipal de nos expériences est de mesurer les performances de notre solution. Nous la comparons

par la suite avec TranspeerToken en termes de temps de réponse.

6.2.3.1 Évaluation du regroupement des transactions

L’évaluation des trois approches pour le regroupement des transactions mono-cibles a révélé que

celle basée-anneau (notée Ring sur la Figure 6.9) donne de meilleurs temps de réponse et est plus

appropriée pour faire face aux pics de charge. En plus, les approches basée-temps (notée Time)

FIGURE 6.9: Temps de réponse vs. Nombre de cibles

Modèle d’exécution des transactions 75

et basée-anneau produisent des groupes de transactions avec de plus grandes tailles comme

montrés sur la figure 6.10. Sur cette figure nous observons que l’approche basée-temps collecte

plus de 67,2% des transactions tandis que l’approche basée-anneau et celle Piggybacking font

au plus 46,2% et 40% respectivement. Pour le traitement des transactions accédant à une seule

cible l’approche basée-anneau est plus appropriée pour avoir des latence faibles.

FIGURE 6.10: Pourcentage de transactions regroupées vs. non regroupées

6.2.3.2 Absorption des pics de charge temporels

Dans cette expérience nous visons à montrer que notre solution peut absorber les pics de charges

et par conséquent passe à l’échelle. Pour ce faire, nous utilisons 10 nœuds RN, 10 nœuds BD

et nous varions le nombre de transactions de 1000 à 8000 dans une très courte période. Nous

reportons sur la Figure 6.11 les temps de réponse aussi bien que l’augmentation de la charge.

Nous observons que notre solution fait face efficacement aux pics de charge puisque le temps

de réponse est presque constant quand la charge varie. La raison principale est que même si

des milliers de transactions sont envoyées, notre couche de routage et d’ordonnancement les

regroupe de sorte que le temps global de routage est réduit et ainsi, le temps de réponse global

l’est aussi. En plus, que tous nos algorithmes sont plus performants que TranspeerToken (TT)

en termes de temps de réponse grâce à l’étape de regroupement des transactions et l’exécution

en groupe.

Modèle d’exécution des transactions 76

FIGURE 6.11: Temps de réponse vs. Charge

6.2.3.3 Impact du nombre de jetons

Puisqu’il y’a un jeton par cible, le nombre de jetons augmente pendant que le nombre de cible

augmente. Cette expérience est conduite pour évaluer l’impact de l’augmentation du nombre de

jetons sur les performances globales de l’approche de regroupement des transactions. Pour ce

faire, nous fixons un nombre constant de transactions (exactement 500 transactions), 10 nœuds

RN et nous varions le nombre de nœud BD (une cible par nœud BD) de 5 à 35. Nous avons

reporté sur la figure 6.12 les résultats obtenus et nous observons qu’ajouter plus de jetons aug-

mente le temps de réponse. La raison est que le surcoût engendré par la gestion des jetons de

traitement "inutilisés" augmente en même temps que le nombre de jetons. Si beaucoup trop de

jetons circulent sur l’anneau alors les RN sont obligés de souvent prendre en charge des jetons

sans les utiliser, parce que soit le RN est occupé avec un autre jeton ou le jeton qui vient d’arriver

n’est pas utile pour ses transactions en attente. Ceci tend à ralentir le jeton de transmission. Par

conséquent, une transaction attendra en moyenne un peu plus de temps avant d’être exécutée.

6.2.3.4 Évaluation du traitement des transactions multi-cibles

L’objectif principal de cette expérience est d’évaluer et de comparer les deux mécanismes propo-

sées pour gérer les transactions multi-cibles. Nous comparons les deux approches aussi bien en

termes de latence qu’en termes de surcharge. Pour ce faire, nous fixons 10 nœuds RN, 10 nœuds

BD (10 cibles) et nous varions le nombre clients de 100 à 600. En plus, nous fixons le tau de

concurrence à 30% et 50% des transactions sont multi-cibles. La figure 6.13 montre le temps de

réponse moyen quand la charge augmente. Comme on peut le voir, pour des charges faibles, le

Modèle d’exécution des transactions 77

FIGURE 6.12: temps de réponse vs. Nombre de nœud BD (ou nombre de jetons)

FIGURE 6.13: Temps de réponse vs. Nombre de nœud BD

temps de réponse reste relativement faible mais augmente rapidement quand la charge devient

importante. Cette observation est vraie aussi bien pour l’approche eager que pour l’approche

lazy. Toutefois, le temps de réponse de l’approche lazy reste inférieur à celui de l’approche

eager. La raison principale de cette différence est que dans l’approche lazy, les nœuds RN al-

ternent l’exécution des transactions sur une seule cible et celle des transactions multi-cibles. En

fait, l’exécution de chaque transaction multi-cibles conduit à une suspension de la plupart des

transactions sur une cible. Ainsi, quand le nombre de transactions multi-cibles est important, le

temps de réponse des transactions simples augmente. L’impact de cette situation est atténué dans

l’approche lazy où la plupart des transactions simples sont exécutées avant que les transactions

multi-cibles soient regroupées et gérées en une seule fois. Dans la stratégie lazy, presque tous les

Modèle d’exécution des transactions 78

FIGURE 6.14: Nombre de messages vs. Nombre de nœuds BD

jetons sont disponibles puisque les transactions simples sont déjà traitées avant que le leader ne

commence l’exécution des transactions multi-cibles. Par conséquent, le temps de réponse global

est moins important que dans l’approche eager.

6.2.3.5 Surcharge des approches eager et lazy

En outre, nous avons mené une expérience pour mesurer la surcharge occasionnée sur le réseau

par nos solutions (eager et lazy), et pour identifier quelle approche est la plus coûteuse en termes

messages. Nous avons utilisé la même configuration que précédemment, c’est-à-dire que nous

considérons 10 nœuds RN, 10 nœuds BD et un tau de concurrence de 30%.

Nous avons reportés les résultats obtenus sur la figure 6.14. Ces résultats révèlent que l’ap-

proche eager utilise un nombre important de messages pendant que l’approche lazy en demande

beaucoup moins. Ceci est du au fait que l’approche eager génère un ensemble de messages pour

chaque transaction multi-cibles, tandis que l’approche lazy attend une fenêtre de temps et agrège

le nombre total de messages à envoyer pour le routage et le traitement des transactions.

6.3 Conclusion

Dans ce chapitre, nous avons présenté nos différentes contributions sur la gestion des transac-

tions pour des applications web 2.0. Notre système est soumis à une contrainte de charge fluc-

tuante, et un besoin de performances en utilisant des ressources minimum.

Modèle d’exécution des transactions 79

Nous proposons diverses stratégies dans gestion des transactions. L’objectif étant toujours d’of-

frir un traitement des transactions qui soit performant mais autorise un accès transactionnel

multi-partition sans être réparti sur différents sites. L’idée étant d’éviter de payer le surcoût oc-

casionné par le traitement de transactions distribuées.

Notre première approche consiste à exploiter les caractéristiques des applications de médias

sociaux de sorte à offrir un traitement des transactions qui soit adapté à la structure des interac-

tions. Pour ce faire, nous exploitons la granule des données liées à une interaction : la cible. Nous

utilisons cette cible pour opérer des regroupements dynamiques des données liées à une interac-

tions. Ce faisant, nous offrons des sémantiques transactionnelles à ce groupe de données sur un

site local. Ce regroupement dynamique des données tient compte des contraintes de capacités de

traitement qu’ont les machines cibles (les sites) et de la tailles des cibles. Ainsi, nous utilisons

le concept k-core augmenté d’un facteur temporel pour définir une cible et avoir la possibilité

de dynamiquement ajuster sa taille en éliminant les données qui peuvent l’être sans déstructurer

les interactions. Ceci nous permet, quand cela est nécessaire, d’adapter la taille d’une cible aux

capacités de traitement d’une machine donnée.

Notre deuxième approche consiste à agir sur la partie routage et ordonnancement des transac-

tions. Il s’agit d’offrir une fonctionnalité de regrouper les transactions en amont de sorte que

les transactions soient soumises pour exécution en groupe plutôt qu’une à une. Ce faisant nous

réduisons considérablement la charge en communication due au nombre important de messages

échangés entre la couche d’exécution et la couche de routage. En plus, le regroupement des

transactions, nous permet de bien les ordonner avant leur exécution, et par là nous gérons la

concurrence dans l’accès aux données et offrons plusieurs possibilité dans la Parallélisation du

traitement. Nous avons validé nos différentes approches via une expérimentation et avons mon-

tré leurs performances.

Chapitre 7

Conclusion et Perspectives

7.1 Synthèse

Durant ces dernières années, le web 2.0 et les applications de ce type ont émergé et se sont im-

posées aux utilisateurs d’internet. Ainsi, ils ont drainé et continuent de mobiliser des centaines

de millions d’utilisateurs à travers la planète. L’utilisation qui est faite de ce type d’application

varie et va des interactions sociales simples à des collaborations dans des domaines profession-

nels. Les utilisateurs sont au centre de ces applications, qui leur permettent de gérer leurs propres

contenus (données) et de manipuler (lectures/écritures) ceux des autres avec qui ils sont en re-

lation. Une caractéristique importante de ces applications est l’exigence de servir les besoins

des utilisateurs avec un traitement suffisamment rapide. Comme tout système d’information, les

données sont essentielles pour la bonne marche des applications web 2.0. Il est nécessaires de

pouvoir accéder rapidement aux données, les modifier tout en ayant une cohérence dans leur

état. Vu le volume de ces données et la quantité de requêtes d’utilisateurs (des millions, voire

des milliards) par heure, il est difficile d’en assurer une gestion avec de fortes exigences dans le

délai du traitement. Les solutions classiques reposent essentiellement sur la distribution de ces

données à travers des clusters de plusieurs dizaines de machines. Ces systèmes sont dimension-

nés de sorte à répondre efficacement (rapidement) aux demandes des utilisateurs, mais le coût est

très élevé. Ce coût se reflète en général dans le nombre de machines qui tournent mais en conte-

nant des données rarement sollicitées. Cela implique la consommation de ressources, d’énergie

et l’utilisation d’une main d’œuvre inutilement. Notre problématique de thèse s’articule au tours

de la gestion des transactions à large échelles avec un ajustement dynamique des ressources à

la demande. Le type d’applications cibles étant celles web 2.0. L’avènement du paradigme du

Cloud computing a ouvert de nouvelles perspectives dans la gestion "intelligente" des ressources

de stockage et de calcul pour les systèmes distribués. En effet, le Cloud offre la possibilité de

modifier dynamiquement la quantité de ressources affectées à une fonction, c’est-à-dire sans

80

Conclusion et Perspectives 81

avoir à interrompre le fonctionnement du système. Nous avons donc proposé de nous inspirer

de ces fonctionnalités du Cloud computing, pour offrir une gestion intelligente des ressources

dans le traitement d’une charge transactionnelle fluctuante pour les applications web 2.0. Cette

gestion de la charge se fait en garantissant un traitement efficace et cohérent des transactions qui

la composent. Le défi majeur auquel nous nous sommes confrontés était de deux dimensions :

– (i) les systèmes de gestion de données (SGBD) ne sont pas destinés à s’adapter à un environ-

nement dynamique (taille variable du système) ;

– et (ii) il fallait réduire au maximum le coût (surcharge) que provoquerait de telles changements

(ajout ou retrait de nœuds, déplacements de données, etc.).

Nous avons adopté une solution qui s’appuie d’une part sur l’utilisation d’une architecture en

couches où nous avons séparé les sémantiques de gestion des transactions et celles de gestion

des données, et d’autre part sur un déploiement sur un cluster de type share nothing. Cette solu-

tion a plusieurs avantages.

D’un côté, elle facilite la possibilité d’ajouter de nouveaux nœuds au système (montée à l’échelle

ou scale-out). Ce qui a permis de répondre efficacement aux pics de charge tout en garantissant

une gestion des transactions qui est efficace et transparente à la couche des applications clientes.

D’un autre côté, la possibilité de réduire dynamiquement la taille du système (descente à l’échelle

ou consolidation) nous permet de consolider le nombre de nœuds du système. Ainsi, la charge

transactionnelle est gérée avec les garanties de performances (temps de réponse borné) et en

utilisant toujours le minimum de ressources possible. Cette consolidation est alors un gage d’al-

lègement du coût de revient du système : économie de ressources matérielles, économie d’éner-

gie et efficience dans l’utilisation des ressources humaines. Nos contributions détaillées dans ce

manuscrit sont regroupées dans deux domaines qui sont la gestion des transactions en environ-

nement distribués et la gestion d’une charge transactionnelle fluctuante. Ces contributions ont

permis d’apporter des réponses aux problèmes posés dans cette thèse, et aussi ont avancé l’état

de l’art dans ces domaines.

7.2 Contributions

Gestion des transactions : La gestion des transactions est un point important dans nos tra-

vaux. En effet, nous avons traité dans cette thèse la possibilité d’optimiser les ressources utili-

sées dans la gestion d’une charge transactionnelle avec des caractéristiques spécifiques. Toutes

les solutions proposées pour la gestion de cette charge doivent prendre en compte le routage,

l’ordonnancement et le traitement des transactions. Nos propositions dans la gestion des tran-

sactions s’articulent autour du routage, de l’ordonnancement et de l’exécution. Ces propositions

ont permis d’apporter une efficacité dans le traitement des transactions tout en contribuant à la

minimisation des ressources.

Conclusion et Perspectives 82

– Nous avons proposé une couche de routage qui est un middleware entre la couche des ap-

plications clientes et la couche de stockage des données et d’exécution des transactions. Sur

cette couche se fait le routage et l’ordonnancement des transactions. Les routeurs s’appuient

sur un index (métadonnées) pour connaître l’emplacement des données et avoir la possibilité

d’ordonnancer et de router des transactions à destination de ces données.

– Nous avons proposé une stratégie de partitionnement et de placement des partitions qui s’ap-

puie sur la notion de cible. Une cible représentant un ensemble de données sur lesquelles

portent les interactions d’un groupe d’utilisateurs pendant une période de temps fini. Notre

stratégie de partitionnement a essentiellement deux rôles : (i) maintenir sur un même site les

données sollicités dans les mêmes interactions, et (ii) avoir une finesse dans la répartition des

données en fonction de la charge courante des nœuds. Ainsi, nous pouvons garantir que la plus

part des transactions sont locales à un site et évitons par conséquent les revers des transactions

distribuées. Un autre avantage de notre partitionnement est de simplifier les interactions dans

la mesure où les données d’une interaction sont le plus souvent sur un même site.

– Nous avons aussi proposé un modèle de gestion qui s’appuie sur une exécution en groupe des

transaction plutôt que d’envoyer les transactions une à une vers les nœuds d’exécution. Nous

proposons une stratégie qui permet de regrouper et d’ordonner les transactions sur la couche

de routage, puis d’envoyer les blocs de transactions au niveau de la couche d’exécution. Cette

stratégie nous permet de considérablement réduire la surcharge en communication dans l’in-

teraction entre couche de routage et couche d’exécution, mais aussi de bénéficier au mieux

des possibilités de Parallélisation dans l’exécution.

Ces propositions ont fait l’objet de publications dans des conférences internationales [GSNJ15],

[SNI15] et [GSN12].

Gestion d’une charge applicative fluctuante et transitoire : Dans nos travaux, sur la gestion

de la charge transactionnelle fluctuante et transitoire, nous avons proposé deux solutions.

– La première solution est relative au problème de la charge au niveau de la couche de routage

des transactions. La solution que nous proposons permet de rendre élastique cette couche en

faisant varier le nombre de machines mobilisées en fonction de la charge courante. La gestion

d’une surcharge sur cette couche consiste à déplacer l’excédent vers d’autres nœuds moins

chargés qui peuvent la gérer ; au besoin, nous rajoutons de nouveaux nœuds pour absorber

l’excédent de charge. Nous utilisons en priorité une politique d’équilibrage de la charge entre

les nœuds actifs et rajoutons de nouvelles instances que si l’équilibrage n’est pas possible.

Nous gérons aussi la consolidation en cas de baisse de la charge globale.

Notre solution surveille la charge des entités qui composent la couche de routage. Cette sur-

veillance nous permet de voir les surcharges arriver, de détecter sur quelle type de ressources

elles se concentrent, puis de les résoudre. Cette surveillance nous permet aussi de détecter les

Conclusion et Perspectives 83

nœuds qui n’ont plus de charge à traiter pendant un certain temps afin de libérer leurs res-

sources. En définitive, notre solution est de rendre la couche de routage élastique, ce qui lui

permet d’adapter ses dimensions (nombre de ressources) en fonction de la charge courante à

traiter.

– La deuxième proposition est relative aux pics de charge qui surviennent sur la couche des

données, là où l’exécution des transactions se fait.

Nous avons observé que le temps d’exécution des transactions pouvait être beaucoup plus

important que le temps consacré au routage des transactions. Par conséquent, l’élasticité de

la couche de routage ne fait que déplacer le problème vers la couche d’exécution. Il faut alors

trouver un moyen de bien répartir les données et disposer de suffisamment de ressources pour

un traitement rapide sur la couche d’exécution. Les caractéristiques de la charge applicative

fluctuante et le caractère changeant du modèle d’accès aux données nous obligent à gérer de

façon concomitante la quantité de ressources et le placement des données.

Dans les solutions que nous proposons, nous avons pris en compte la structure des interac-

tions entre utilisateurs. Les utilisateurs sont organisés en groupe d’interactions denses. La

plupart des pics de charge ont pour origine un pic d’interactions au sein des groupes. Les

cibles désignant les groupes de données auxquelles les transactions accèdent. Plus le nombre

de transactions accédant simultanément à une cible est grand, plus sa charge est importante et

vis-versa.

Nous avons proposé une gestion efficace de ces pics de charge en procédant par un partition-

nement dynamique qui identifie les sources de pics et exploite la structure des interactions

entre utilisateurs afin d’effectuer des placements dynamiques pour absorber les pics progres-

sivement.

Nos différentes propositions sur la gestion de la charge ont fait l’objet de publications dans

conférences internationales et chapitre de livre [GSN12], [GSN14a], [GSN14b], [GSNJ15],

[SNI15], [GNS15] et [SNB+15].

7.3 Perspectives

Prédiction de la charge : Dans cette thèse, les solutions proposées pour la gestion des pics de

charges se basent sur l’utilisation de statistiques obtenues en collectant les informations utiles à

cet effet. En bref, nous détectons les pics de charge après leur occurrence même si cette détection

est rapide. Cependant, pour plus d’efficience dans leur prise en charge, il serait plus avantageux

de détecter les pics avant leur occurrence. Nous avons commencé des travaux dans ce sens et

planifions de les poursuivre en exploitant le graphe d’interaction mais aussi les caractéristiques

des utilisateurs pour une meilleure maîtrise du modèle de charge. Le défi dans cette perspective

est la nature changeant des humeurs des utilisateurs d’application web 2.0, particulièrement

Conclusion et Perspectives 84

dans les réseaux sociaux. Une bonne prédiction du modèle de charge pourrait aussi permettre

une meilleure prise en charge des transactions.

Passage à l’échelle de la gestion des transactions : Notre système de gestion de la charge

utilise un élément (une entité) centralisé, nommé contrôleur. Ce contrôleur est chargé du recueil

et de la compilation des informations sur la charge des nœuds de la couche de données et de la

couche de routage. Avec un très grand nombre de nœuds à gérer, cette entité pourrait devoir un

point de contention et par conséquent ralentir le processus de prise de décision sur la gestion de

la charge. Bien que nous ayons évoqué quelques éléments de solution par rapport à ce problème,

nous ne les avons pas implémenté dans nos expérimentations. Nous planifions de les étudier plus

amplement afin d’apporter une solution effective.

Comparaison avec certains travaux de l’état de l’art : Nous planifions de faire une étude

comparative de nos solutions de placement dynamique des données et de la gestion dyna-

mique de la charge transactionnelle. Nous prévoyons de nous comparer à des travaux relatifs

parmi lesquels Kairos [CJMB11], SCADS Director [TBF+11], Pythia [ASA+13] et Accordion

[SMA+14]. Pour ce qui est du regroupement des données nous prévoyons de nous comparer à

certaines propositions faites dans [LTP+14] et éventuellement dans [DAE10].

Tolérance aux pannes : Nous n’avons pas explicitement abordé cette question dans nos tra-

vaux. En effet, notre architectures est conçue de sorte à implicitement être tolérante à certaines

pannes. De plus, notre travail est dans la continuité des travaux réalisés dans [IDR10]. Dans

ces travaux [IDR10], la gestion des pannes dans le routage et l’exécution des transactions à été

étudié et des solutions efficaces proposées. Ces solutions peuvent être appliquées dans notre

contexte, moyennant des approfondissement pour les adapter à l’élasticité du système et au pla-

cement dynamique des données. Ces questions seront étudiées dans nos travaux ultérieurs à cette

thèse.

Bibliographie

[AAEAD10] Divyakant Agrawal, Abbadi Amr El, Shyam Antony, and Sudipto Das. Data

management challenges in cloud computing infrastructures. In International

Conf. on Databases in Networked Information Systems, pages 1–10, 2010.

[ABC+03] Serge Abiteboul, Angela Bonifati, Grégory Cobéna, Ioana Manolescu, and Tova

Milo. Dynamic xml documents with distribution and replication. In Proceedings

of the 2003 ACM SIGMOD International Conference on Management of Data,

pages 527–538, 2003.

[ACMD+03] Karl Aberer, Philippe Cudré-Mauroux, Anwitaman Datta, Zoran Despotovic,

Manfred Hauswirth, Magdalena Punceva, and Roman Schmidt. P-grid : A

self-organizing structured p2p system. SIGMOD Rec., 32(3) :29–33, 2003.

[AGJ+08] Stefan Aulbach, Torsten Grust, Dean Jacobs, Alfons Kemper, and Jan Rittinger.

Multi-tenant databases for software as a service : Schema-mapping techniques.

In ACM SIGMOD International Conference on Management of Data, pages

1195–1206. ACM, 2008.

[AKD13] Quamar Abdul, K.Ashwin Kumar, and Amol Deshpande. Sword : Scalable

workload-aware data placement for transactional workloads. In Intl Conf. on

Extending Database Technology (EDBT), pages 430–441, 2013.

[Ama14] Amazon Web Services Pricing. http ://aws.amazon.com/fr/ec2/pricing/. online,

Retrieved on November 2014.

[AMS+07] Marcos K. Aguilera, Arif Merchant, Mehul Shah, Alistair Veitch, and Christos

Karamanolis. Sinfonia : a new paradigm for building scalable distributed

systems. SIGOPS Oper. Syst. Rev., 41(6) :159–174, 2007.

[ANY04] Sanjay Agrawal, Vivek Narasayya, and Beverly Yang. Integrating vertical and

horizontal partitioning into automated physical database design. In Proceedings

of the 2004 ACM SIGMOD International Conference on Management of Data,

SIGMOD, pages 359–370. ACM, 2004.

85

Bibliographie 86

[Apa14] Apache Storm. http ://storm.incubator.apache.org/. online, Retrieved on August

2014.

[APBC13] Timothy G. Amstrong, Vamsi Ponnekanti, Dhruuba Borthakur, and Mark

Callaghan. Linkbench : a database benchmark based on the facebook social

graph. In Intl Conf. on Management of Data (SIGMOD), pages 1185–1196,

2013.

[AS14] Foundation Apache Software. Apache hbase, Retrieved on March 2014.

[ASA+13] Elmore Aaron J., Das Sudipto, Pucher Alexander, Agrawal Divyakant, El

Abbadi Amr, and Yan Xifeng. Characterizing tenant behavior for placement and

crisis mitigation in multitenant dbmss. In International Conference on

Management of Data, SIGMOD ’13, pages 517–528, 2013.

[ASDA11] Elmore Aaron J., Das Sudipto, Agrawal Divyakant, and El Abbadi Amr.

Zephyr : Live migration in shared nothing database for elastic cloud platforms.

Intl Conf. on Management of Data (SIGMOD), pages 301–312, 2011.

[AWZ09] Ashraf Aboulnaga, Ziyu Wang, and Zi Ye Zhang. Packing the most onto your

cloud. In Proceedings of the First International Workshop on Cloud Data

Management, CloudDB ’09, pages 25–28. ACM, 2009.

[BALC+90] H. Boral, W. Alexander, G. Copeland L. Clay, S. Danforth, M. Franklin, B. Hart,

M. Smith, and P. Valduriez. Prototyping bubba, a highly parallel database

system. Transactions on Knowledge and Data Engineering (TKDE), 2(1), 1990.

[BBC+11] Jason Baker, Chris Bond, James C. Corbett, JJ Furman, Andrey Khorlin, James

Larson, Jean-Michel Leon, Yawei Li, Alexander Lloyd, and Vadim Yushprakh.

Megastore : Providing scalable, highly available storage for interactive services.

In Conf. on Innovative Data system Research (CIDR), pages 223–234, 2011.

[BBSU12] Simon Barber, Xavier Boyen, Elaine Shi, and Ersin Uzun. Bitter to better — how

to make bitcoin a better currency. In Financial Cryptography and Data Security,

volume 7397 of Lecture Notes in Computer Science, pages 399–414. 2012.

[BCD+92] Kurt P. Brown, Michael J. Carey, David J. DeWitt, Manish Mehta, and Jeffrey F.

Naughton. Resource allocation and scheduling for mixed database workloads.

Technical Report 1095, University of Wisconsin, Computer Sciences

Department, 1012 West Dayton Street, Madison, WI 53706, July 1992.

[BCD+11] Philip A. Bernstein, Istvan Cseri, Nishant Dani, Nigel Ellis, Ajay Kalhan, Gopal

Kakivaya, David B. Lomet, Ramesh Manne, Lev Novik, and Tomas Talius.

Bibliographie 87

Adapting microsoft sql server for cloud computing. In IEEE Intl Conf. on Data

Engineering, pages 1255–1263, 2011.

[BFH+14] Peter Bailis, Alan Fekete, Joseph M. Hellerstein, Ali Ghodsi, and Ion Stoica.

Scalable atomic visibility with ramp transactions. In ACM SIGMOD

International Conference on Management of Data, SIGMOD ’14, pages 27–38,

2014.

[BLS95] Anna Brunstrom, Scott T. Leutenegger, and Rahul Simha. Experimental

evaluation of dynamic data allocation strategies in a distributed database with

changing workloads. In Proceedings of the Fourth International Conference on

Information and Knowledge Management, CIKM, pages 395–402, 1995.

[BN09] Philip A. Bernstein and Eric Newcomer. Principles of Transaction Processing,

2nd Edition. Morgan Kaufmann Publishers Inc., 2009.

[BRCA09] Fabrício Benevenuto, Tiago Rodrigues, Meeyoung Cha, and Virgílio Almeida.

Characterizing user behavior in online social networks. In Proceedings of the 9th

ACM SIGCOMM Conference on Internet Measurement Conference, IMC, pages

49–62. ACM, 2009.

[BRD11] Philip A. Bernstein, Colin W. Reid, and Sudipto Das. Hyder - a transactional

record manager for shared flash. In CIDR, pages 9–20, 2011.

[BT14] Inc. Basho Technologies. Riak, Retrieved on March 2014.

[CABK88] George Copeland, William Alexander, Ellen Boughter, and Tom Keller. Data

placement in bubba. SIGMOD Rec., 17(3) :99–108, 1988.

[CB03] Sashikanth Chandrasekaran and Roger Bamford. Shared cache - the future of

parallel databases. In IEEE 19th International Conference on Data Engineering,

pages 840–850, 2003.

[CDG+06] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.

Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber.

Bigtable : a distributed storage system for structured data. In USENIX

Symposium on Operating Systems Design and Implementation, pages 15–15,

2006.

[CER+11] Curino Carlo, Jones Evan, Ada Popa Raluca, Malviya Nirmesh, Wu Eugene,

Madden Samuel, Balakrishnan Hari, and Zeldovich Nickolai. Relational cloud :

A database service for the cloud. In Conf. on Innovative Data Systems Research

(CIDR), pages 235–240, 2011.

Bibliographie 88

[CFH+05] Christopher Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen, Eric Jul,

Christian Limpach, Ian Pratt, and Andrew Warfield. Live migration of virtual

machines. In Conference on Symposium on Networked Systems Design and

Implementation - Volume 2, NSDI’05, pages 273–286, 2005.

[CGS03] Abhishek Chandra, Weibo Gong, and Prashant Shenoy. Dynamic resource

allocation for shared data centers using online measurements. SIGMETRICS

Perform. Eval. Rev., 31(1) :300–301, 2003.

[Chu69] W. W. Chu. Optimal file allocation in a multiple computer system. IEEE Trans.

Comput., 18 :885–889, 1969.

[CJMB11] Carlo Curino, Evan P.C. Jones, Samuel Madden, and Hari Balakrishnan.

Workload-aware database monitoring and consolidation. In Intl Conf. on

Management of Data (SIGMOD), pages 313–324, 2011.

[CJZM10] Carlo Curino, Evan Jones, Yang Zhang, and Sam Madden. Schism : a

workload-driven approach to database replication and partitioning. VLDB

Endow., 3(1-2) :48–57, 2010.

[CMH+02] Ian Clarke, Scott G. Miller, Theodore W. Hong, Oskar Sandberg, and Brandon

Wiley. Protecting free expression online with freenet. IEEE Internet Computing,

6(1) :40–49, 2002.

[CRB+11] R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. F. De Rose, , and R. Buyya.

Cloudsim : a toolkit for modeling and simulation of cloud computing

environments and evaluation of resource provisioning algorithms. Software :

Practice and Experience, 41(1) :23–50, 2011.

[CRS+08] Brian F. Cooper, Raghu Ramakrishnan, Utkarsh Srivastava, Adam Silberstein,

Philip Bohannon, Hans-Arno Jacobsen, Nick Puz, Daniel Weaver, and Ramana

Yerneni. Pnuts : Yahoo !’s hosted data serving platform. VLDB Endow.,

1 :1277–1288, 2008.

[DAE10] Sudipto Das, Divyakant Agrawal, and Amr El Abbadi. G-store : A scalable data

store for transactional multi key access in the cloud. In ACM SoCC, pages

163–174, 2010.

[DAE13] Sudipto Das, Divyakant Agrawal, and Amr El Abbadi. Elastras : An elastic,

scalable, and self-managing transactional database for the cloud. ACM Trans.

Database Syst., 38(1) :5–45, 2013.

[DGS+90] D. J. DeWitt, S. Ghandeharizadeh, D. A. Schneider, A. Bricker, H. I. Hsiao, and

R. Rasmussen. The gamma database machine project. Transactions on

Knowledge and Data Engineering (TKDE), 2(1), 1990.

Bibliographie 89

[DHJ+07] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati,

Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter

Vosshall, and Werner Vogels. Dynamo : amazon’s highly available key-value

store. ACM SIGOPS Operating Systems Review, 41 :205–220, 2007.

[DNAE11] Sudipto Das, Shoji Nishimura, Divyakant Agrawal, and Amr El Abbadi.

Albatross : lightweight elasticity in shared storage databases for the cloud using

live data migration. Proc. VLDB Endow., 4(8) :494–505, 2011.

[FJR09] Yang Fan, Shanmugasundaram Jayavel, and Yerneni Ramana. A scalable data

platform for a large number of small applications. In CIDR, 2009.

[For10] Santo Fortunato. Community detection in graphs. Physics Reports,

486(3-5) :75–174, 2010.

[Fre14] FreePastry. http ://www.freepastry.org/freepastry/. online, Retrieved on August

2014.

[G.88] Apers Peter M. G. Data allocation in distributed database systems. ACM Trans.

Database Syst., 13(3) :263–304, 1988.

[GJP11] K. Gilly, C. Juiz, and R. Puigjaner. An up-to-date survey in web load balancing.

World Wide Web, pages 105–131, 2011.

[GNS15] Ibrahima Gueye, Joseph Ndong, and Idrissa Sarr. An accurate probabilistic

model for community evolution analysis in social network. In International

Conference on Signal-Image Technology and Internet-Based Systems, SITIS,

pages 1–7. IEEE, 2015.

[GSN12] Ibrahima Gueye, Idrissa Sarr, and Hubert Naacke. Transelas : Elastic transaction

monitoring for web2.0 applications. In Data Management in Cloud, Grid and

P2P Systems, Lecture Notes in Computer Science, pages 1–12. Springer, 2012.

[GSN14a] Ibrahima Gueye, Idrissa Sarr, and Hubert Naacke. Exploiting the social structure

of online media to face transient heavy workload. In The Sixth Intl. Conf. on

Advances in Databases, Knowledge, and Data Applications, IARIA, pages

51–58, 2014.

[GSN14b] Ibrahima Gueye, Idrissa Sarr, and Hubert Naacke. Gestion d’un workload

transitoire via les graphes sociaux. In Conférence Africaine sur la Recherche en

Informatique (CARI), pages 201–212, 2014.

[GSNJ15] Ibrahima Gueye, Idrissa Sarr, Hubert Naacke, and Ndong Joseph. Supporting

fluctuations in transactional workload. In 26th International Conference on

Bibliographie 90

Database Expert Systems and Applications (DEXA), pages 295–303. Springer,

2015.

[Hea14] Matt Heaton. Hosting nirvana—the future of shared hosting !, Retrieved on June

2014.

[Hel07] Pat Helland. Life beyond distributed transactions : an apostate’s opinion. In

CIDR, pages 132–141, 2007.

[HHL+03] Ryan Huebsch, Joseph M. Hellerstein, Nick Lanham, Boon Thau Loo, Scott

Shenker, and Ion Stoica. Querying the internet with pier. In Proceedings of the

29th International Conference on Very Large Data Bases, pages 321–332, 2003.

[HI12] Abdalla Hassan I. A new data re-allocation model for distributed database

systems. Intl Journal of Database Theory And Application (IJDTA), 5, 2012.

[HIMF08] Abdalla Hassan Ismail, Tounsi Mohamed, and Marir Farhi. Using a

greedy-based approach for solving data allocation problem in a distributed

environment. In PDPTA, pages 975–980, 2008.

[HJLZ09] Mei Hui, D. Jiang, Guoliang Li, and Yuan Zhou. Supporting database

applications as a service. In IEEE 25th International Conference on Data

Engineering (ICDE), pages 832–843, 2009.

[HL90] Kien A. Hua and Chiang Lee. An adaptive data placement scheme for parallel

database computer systems. In Proceedings of the 16th International Conference

on Very Large Data Bases, VLDB ’90, pages 493–506, 1990.

[HM98] Fred Howell and Ross Mcnab. simjava : A discrete event simulation library for

java. In Intl Conf. on Web-Based Modeling and Simulation, pages 51–56, 1998.

[IDR10] SARR IDRISSA. Routage des Transactions dans les Bases de Données à Large

Echelle. PhD thesis, Université Pierre et Marie Curie (Paris VI), 2010.

[IFS15] Damian Murezzan Ilir Fetai and Heiko Schuldt. Workload-driven adaptive data

partitioning and distribution – the cumulus approach. In International Workshop

on Scalable Cloud Data Management (SCDM), pages 1–10, 2015.

[Inc14] mongoDB Inc. mongodb, Retrieved on March 2014.

[JA07] Dean Jacobs and Stefan Aulbach. Ruminations on multi-tenant databases. In

BTW, pages 514–521, 2007.

[JN12] B. Jasma and R. Nedunchezhian. A hybrid policy for fault tolerant load

balancing in grid computing environments. Journal of Network and Computer

Applications, pages 412 – 422, 2012.

Bibliographie 91

[Jon12] Evan Philip Charles Jones. Fault-Tolerant Distributed Transactions for

Partitioned OLTP Databases. PhD thesis, Massachusetts Institute Of

Technology, 2012.

[jon14] Combining database clustering and virtualization to consolidate mission-critical

servers, Retrieved on June 2014.

[KKN+08] Robert Kallman, Hideaki Kimura, Jonathan Natkins, Andrew Pavlo, Alexander

Rasin, Stanley Zdonik, Evan P. C. Jones, Samuel Madden, Michael Stonebraker,

Yang Zhang, John Hugg, and Daniel J. Abadi. H-Store : a high-performance,

distributed main memory transaction processing system. Proc. VLDB Endow.,

1(2) :1496–1499, 2008.

[LAM98] Leslie LAMPORT. The part-time parliament. ACM Trans. Comput. Syst.,

16(2) :133–169, 1998.

[LKF+13] Juchang Lee, Yong Sik Kwon, Franz Färber, Michael Muehle, Chulwon Lee,

Christian Bensberg, Joo-Yeon Lee, Arthur H. Lee, and Wolfgang Lehner. Sap

hana distributed in-memory database system : Transaction, session, and metadata

management. In ICDE, pages 1165–1173. IEEE Computer Society, 2013.

[LLMK11] Justin J. Levandoski, David B. Lomet, Mohamed F. Mokbel, and Zhao Kevin.

Deuteronomy : Transaction support for cloud data. In CIDR, pages 123–133,

2011.

[LTP+14] Bin Liu, Junichi Tatemura, Oliver Po, Wang-Pin Hsiung, and Hakan Hacigumus.

Automatic entity-grouping for oltp workloads. In Intl. Conf. on Data

Engineering (ICDE), IEEE 2014, pages 712–723, 2014.

[LXK+11] Y. Lua, Q. Xiea, G. Kliotb, A. Gellerb, J. R. Larusb, and A. Greenber.

Join-idle-queue : A novel load balancing algorithm for dynamically scalable web

services. Intl Journal on Performance evaluation, pages 1056–1071, 2011.

[MD97] Mehta Manish and David J. DeWitt. Data placement in shared-nothing parallel

database systems. The VLDB Journal, 6 :53–72, 1997.

[MDP+00] Dejan S. Milo´icic, Fred Douglis, Yves Paindaveine, Richard Wheeler, and

Songnian Zhou. Process migration. ACM Comput. Surv., 32(3) :241–299, 2000.

[Min13] Umar Farooq Minhas. Scalable and Highly Available Database Systems in the

Cloud. PhD thesis, University of Waterloo, 2013.

[MKC11] H. Mehta, P. Kanungo, and M. Chandwani. Decentralized content aware load

balancing algorithm for distributed computing environments. In Intl Conf.

Workshop on Emerging Trends in Technology (ICWET), pages 370–375, 2011.

Bibliographie 92

[MLA+12] Laure Millet, Maxime Lorrillere, Luciana Arantes, Stéphane Gançarski, Hubert

Naacke, and Julien Sopena. Facing peak loads in a p2p transaction system. In

EDCC Workshop on P2P and Dependability, P2P-Dep, pages 1–7, 2012.

[MLO86] C. Mohan, B. Lindsay, and R. Obermarck. Transaction management in the r*

dis- tributed database management system. Transactions on Database Systems,

11(4) :378–396, 1986.

[MTK+11] Kunal Mukerjee, Tomas Talius, Ajay Kalhan, Nigel Ellis, and Conor

Cunningham. Sql azure as a self-managing database service : Lessons learned

and challenges ahead. Bulletin of the IEEE Computer Society Technical

Committee on Data Engineering, 34 :61–70, 2011.

[NBAM05] Mohamed N. Bennani and Daniel A. Menasce. Resource allocation for

autonomic data centers using analytic performance models. In International

Conference on Automatic Computing, pages 229–240. IEEE Computer Society,

2005.

[NC12] Jain Kansal Nidhi and Inderveer Chana. Cloud load balancing techniques : A

step towards green computing. International Journal of Computer Science

Issues (IJCSI), Vol. 9, Issue 1, No 1 :238–246, 2012.

[New04] M. E. J. Newman. Fast algorithm for detecting community structure in networks.

Physical Review E, 69(6) :1–5, 2004.

[NMB11] A. M. Nakai, E. Madeira, and L. E. Buzato. Load balancing for internet

distributed services using limited redirection rates. IEEE Latin-American

Symposium on Dependable Computing (LADC), pages 156–165, 2011.

[NSS03] Wolfgang Nejdl, Wolf Siberski, and Michael Sintek. Design issues and

challenges for rdf- and schema-based peer-to-peer systems. SIGMOD Rec.,

32(3) :41–46, 2003.

[OST03] Beng Chin Ooi, Yanfeng Shu, and Kian-Lee Tan. Relational data sharing in

peer-based data management systems. SIGMOD Rec., 32(3) :59–64, 2003.

[PA04] Stratos Papadomanolakis and Anastassia Ailamaki. Autopart : Automating

schema design for large scientific databases using data partitioning. In

Proceedings of the 16th International Conference on Scientific and Statistical

Database Management, SSDBM, page 383–394. IEEE Computer Society, 2004.

[PCZ12] Andrew Pavlo, Carlo Curino, and Stanley Zdonik. Skew-aware automatic

database partitioning in shared-nothing, parallel oltp systems. In Intl Conf. on

Management of Data (SIGMOD), pages 61–72, 2012.

Bibliographie 93

[PDI00] Daniel Peng, Frank Dabek, and Google Inc. Large-scale incremental processing

using distributed transactions and notfications. In 9th USENIX Symposium on

Operating Systems Design and Implementation, pages 4–6, 200.

[PMFB10] Hunt Patrick, Konar Mahadev, P. Junqueira Flavio, and Reed Benjamin.

Zookeeper : Wait-free coordination for internet-scale systems. In In USENIX

Annual Technical Conference, 2010.

[Red14] Redis Inc. http ://redis.io/. online, Retrieved on August 2014.

[Redks] Redis. How fast is redis. online, Retrieved on May 2015,

url :http ://redis.io/topics/benchmarks.

[RVVN90] P.I. Rivera-Vega, R. Varadarajan, and S.B. Navathe. Scheduling data

redistribution in distributed databases. In ICDE, pages 166–173, 1990.

[SAG06] Gokul Soundararajan, Cristiana Amza, and Ashvin Goel. Database replication

policies for dynamic content applications. In Proceedings of the 1st ACM

SIGOPS/EuroSys European Conference on Computer Systems 2006, EuroSys,

pages 89–102, 2006.

[SJK+13] Jan Schaffner, Tim Januschowski, Megan Kercher, Tim Kraska, Hasso Plattner,

Michael J. Franklin, and Dean Jacobs. Rtp : robust tenant placement for elastic

in-memory database clusters. In Intl Conf. on Management of Data (SIGMOD),

pages 773–784. ACM, 2013.

[SLG+09] Gokul Soundararajan, Daniel Lupei, Saeed Ghanbari, Adrian Daniel Popescu,

Jin Chen, and Cristiana Amza. Dynamic resource allocation for database servers

running on virtual storage. In Proccedings of the 7th Conference on File and

Storage Technologies, pages 71–84, 2009.

[SMA+10] Ahmed A. Soror, Umar Farooq Minhas, Ashraf Aboulnaga, Kenneth Salem,

Peter Kokosielis, and Sunil Kamath. Automatic virtual machine configuration

for database workloads. ACM Trans. Database Syst., 35(1), 2010.

[SMA+14] Marco Serafini, Essam Mansour, Ashraf Aboulnaga, Kenneth Salem, Taha Rafiq,

and Umar Farooq Minhas. Accordion : Elastic scalability for database systems

supporting distributed transactions. PVLDB, 7(12) :1035–1046, 2014.

[SMR00] Thomas Stöhr, Holger Märtens, and Erhard Rahm. Multi-dimensional database

allocation for parallel data warehouses. In Proceedings of the 26th International

Conference on Very Large Data Bases, VLDB ’00, pages 273–284, 2000.

Bibliographie 94

[SNA13] Idrissa Sarr, Hubert Naacke, and Ould Mohamed Moctar Abderrahmane.

STRING : social-transaction routing over a ring. In Database and Expert

Systems Applications - International Conference, DEXA 2013. Proceedings, Part

II, pages 319–333, 2013.

[SNB+15] Idrissa Sarr, Hubert Naacke, Ndiouma Bame, Ibrahima Gueye, and Samba

Ndiaye. Green and distributed architecture for managing big data of biodiversity.

In Computing in Research and Development in Africa, pages 21–39. Springer

International Publishing, 2015.

[SNG10] Idrissa Sarr, Hubert Naacke, and Stéphane Gançarski. Transpeer : adaptive

distributed transaction monitoring for web2.0 applications. In ACM Symposium

on Applied Computing (SAC), pages 423–430, 2010.

[SNI15] Idrissa Sarr, Hubert Naacke, and Gueye Ibrahima. Blockchain-based model for

social transactions processing. In International Conference on Data

Management Technologies and Applications, DATA 2015, pages 309–315.

SciTePress, 2015.

[SW85] Domenico Sacca and Gio Wiederhold. Database partitioning in a cluster of

processors. ACM Trans. Database Syst., 10 :29–56, 1985.

[TBF+11] Beth Trushkowsky, Peter Bodík, Armando Fox, Michael J. Franklin, Michael I.

Jordan, and David A. Patterson. The scads director : Scaling a distributed

storage system under stringent performance requirements. In 9th USENIX

Conference on File and Stroage Technologies, FAST’11, pages 12–12, 2011.

[TD15] Serafettin Tasci and Murat Demirbas. Panopticon : An omniscient lock broker

for efficient distributed transactions in the datacenter. In International

Conference on Big Data (IEEE BigData), page 253–262, 2015.

[TDW+12] Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, Philip

Shao, and Daniel J. Abadi. Calvin : fast distributed transactions for partitioned

database systems. In Intl Conf. on Management of Data (SIGMOD), pages 1–12,

2012.

[TFA08] Schutt Thorsten, Schintke Florian, and Reinefeld Alexander. Scalaris : reliable

transactional p2p key/value store. In Workshop on Erlang, pages 41–48, 2008.

[TH08] L Tambulea and M Horvat. Dynamic distribution model in distributed database.

Intl. Journal of Computers, Communications and Control, 3 :512–515, 2008.

[TIM+03] Igor Tatarinov, Zachary Ives, Jayant Madhavan, Alon Halevy, Dan Suciu, Nilesh

Dalvi, Xin (Luna) Dong, Yana Kadiyska, Gerome Miklau, and Peter Mork. The

piazza peer data management project. SIGMOD Rec., 32(3) :47–52, 2003.

Bibliographie 95

[USC+08] Bhuvan Urgaonkar, Prashant Shenoy, Abhishek Chandra, Pawan Goyal, and

Timothy Wood. Agile dynamic provisioning of multi-tier internet applications.

ACM Trans. Auton. Adapt. Syst., 3(1) :1 :1–1 :39, 2008.

[Val93] Patrick Valduriez. Parallel database systems : Open problems and new issues.

Distrib. Parallel Databases, 1(2) :137–165, 1993.

[VCO10] Hoang Tam Vo, Chun Chen, and Beng Chin Ooi. Towards elastic transactional

cloud storage with range query support. VLDB Endow., 3 :506–514, 2010.

[Vog07] Werner Vogels. Data access patterns in the amazon.com technology platform. In

Intl Conf. on Very large data bases, pages 1–1, 2007.

[Vol14] Inc. VoltDB. Voltdb, Retrieved on March 2014.

[VP05] Patrick Valduriez and Esther Pacitti. Data management in large-scale p2p

systems. In Proceedings of the 6th International Conference on High

Performance Computing for Computational Science, pages 104–118, 2005.

[WPC10] Zhou Wei, Guillaume Pierre, and Chi-Hung Chi. CloudTPS : Scalable

transactions for Web applications in the cloud. Technical Report IR-CS-053,

Vrije Universiteit, Amsterdam, The Netherlands, February 2010.

http://www.globule.org/publi/CSTWAC_ircs53.html.

[WV01] Gerhard Weikum and Gottfried Vossen. Transactional Information Systems :

Theory, Algorithms, and the Practice of Concurrency Control and Recovery.

Morgan Kaufmann Publishers Inc., 2001.

[Xetis] Xetorthio. Jedis : a redis java client. online, Retrieved on January 2015,

url :https ://github.com/xetorthio/jedis.

[YHJ11] G. You, S. Hwang, and N. Jain. Scalable load balancing in cluster storage

systems. In Middleware, volume 7049 of Lecture Notes in Computer Science,

pages 101–122. Springer Berlin / Heidelberg, 2011.

[zerrg] Zeromq. online, Retrieved on January 2015, url :https ://http ://zeromq.org/.

[ZRL+04] Daniel C. Zilio, Jun Rao, Sam Lightstone, Guy Lohman, Adam Storm, Christian

Garcia-Arellano, and Scott Fadden. Db2 design advisor : Integrated automatic

physical database design. In Proceedings of the Thirtieth International

Conference on Very Large Data Bases - Volume 30, VLDB, pages 1087–1097.

VLDB Endowment, 2004.

Résumé 96

RésuméCette thèse étudie le cas d’une charge transactionnelle fluctuante telle qu’elle se produit dans les

applications web 2.0 où les utilisateurs interagissent les uns avec les autres. Ces applications,

notamment celles de type médias sociaux, utilisent des volumes de données très importants et

mobilisent de très nombreux utilisateurs de différentes natures (utilisateurs finaux et fournisseurs

de services). De plus, les utilisateurs ont des exigences fortes en termes de temps de réponse,

de cohérence et de coût. Notre travail consiste à proposer une solution permettant de prendre

en compte les contraintes liées aux applications web 2.0 à savoir la charge fluctuante et les exi-

gences des utilisateurs.

Précisément, notre solution tente de borner le temps de réponse des transactions tout en garan-

tissant une bonne cohérence des données et d’ajuster dynamiquement le nombre de ressources

requises en fonction de la charge. Plusieurs solutions ont été proposées pour prendre en compte

les mêmes contraintes, mais malheureusement, elles s’appuient sur des mécanismes statiques

qui ne prennent pas forcément en compte l’aspect fluctuation de la charge. Bien que ces solu-

tions permettent d’avoir des temps de réponse acceptables, force est de constater que le nombre

de ressources mobilisées dépasse de très loin la charge réelle. Autrement dit, il y’a un coût in-

utile dépensé, ce qui n’est pas favorable aux utilisateurs de type prestataires. Pour atteindre nos

objectifs, nous avons proposé une solution liée à l’organisation de l’infrastructure et la gestion

de la cohérence.

Par rapport à l’organisation de l’infrastructure, nous avons une architecture composée essen-

tiellement de deux couches : une couche qui contrôle le routage et/ou l’ordonnancement des

transactions tandis que la deuxième couche s’intéresse à l’exécution des transactions sur les

données. La raison principale de subdiviser l’architecture en deux couches est de séparer la ges-

tion des ressources nécessaires et spécifiques à chaque couche (routage et exécution des transac-

tions). Pour implémenter l’architecture proposée, nous avons distribué la couche de routage et

celle de l’exécution des transactions sur plusieurs noeuds. Ce qui permet de favoriser les accès

disjoints et de paralléliser le routage et l’exécution des transactions en vue d’un meilleur passage

à l’échelle. De plus, dans l’optique de réduire les ressources inutiles, nous avons implémenté un

mécanisme qui surveille la charge transactionnelle et au besoin d’ajouter ou de diminuer des

ressources.

Par rapport à la gestion de la cohérence, nous avons proposé deux stratégies : une première qui

regroupe les données et une deuxième qui regroupe les transactions.

La stratégie qui regroupe les données s’appuie sur les interactions des utilisateurs (graphe so-

cial). Plus précisément, les utilisateurs qui interagissent ensemble sont souvent dans les mêmes

groupes et les données qu’ils manipulent et peuvent être organisées sous forme de partitions que

nous appelons cibles. Ce regroupement permet de réduire voire d’éviter les transactions distri-

buées qui sont coûteuses et qui limitent le passage à l’échelle horizontal.

La deuxième stratégie regroupe plutôt les transactions afin de favoriser un traitement groupé de

Résumé 97

ces dernières. Dans cette approche, les transactions sont regroupées et ordonnées sur la couche

de routage en fonction des cibles. Ce regroupement permet d’améliorer le parallélisme dans

l’exécution, simplifie le contrôle de concurrence et limite la charge en termes de communica-

tion entre les couches de routage et d’exécution. Un des gains de notre solution est d’ordre

économique en minimisant le nombre de machines utilisées tout en maintenant globalement les

latences à des niveaux souhaités. Nous avons validé expérimentalement (par simulation et im-

plémentation) nos différentes propositions faites dans cette thèse afin de montrer leur faisabilité

et leur efficacité.