L'élasticité des bases de données sur le cloud computing - CoDE

More documents

Recommendations

Info

Les différentes tables et familles de colonnes doivent être définies au démarrage du système car elles ne peuvent pas être modifiées de manière dynamique tandis qu’à tout instant, des colonnes peuvent être ajoutées à une famille de colonnes. Les différentes familles de colonnes sont stockées ensemble sur HDFS, ce qui fait de Hbase un système orienté famille de colonnes. 3.6.3 Choix CAP et PAELC Hbase est un système CP : vu qu’il ne possède pas de système propre de réplication, lorsqu’un nœud connait une défaillance, les données dont il était responsable ne vont plus être accessibles (il n’y pas de possibilité de joindre une réplique). L’avantage le plus certain est que le système est tolérant à la partition : en cas de défaillance, seules quelques régions (voir section 3.6.4) seront inaccessibles. Hbase s’inscrit donc dans un modèle PC/EC. 3.6.4 Vue d’ensemble de l’architecture Figure 3.15 – Architecture Hbase [43] Un système Hbase repose donc sur deux clusters travaillant ensemble, un cluster HDFS et un cluster Hbase . Comme l’illustre la figure 3.15, le cluster Hbase a 3 composants : – Le maître qui assigne les régions aux serveurs de régions enregistrés. Il est aussi chargé de les surveiller. Si un serveur de région n’est plus joignable, le maître va réassigner les régions qu’il gérait. Le maître est aussi en charge de tâches administratives telles que les changements du schéma de données, etc. Il sert de point d’entrée pour toute application se connectant au système ; il communiquera quelle serveur de région stocke les données qui l’intéressent. 35
– Les Serveurs de régions prennent en charge les requêtes d’écriture et de lecture du client. Ils communiquent avec le maître qui lui transmet la liste des régions qu’ils géreront et pour lui faire savoir qu’ils sont toujours joignables. Ils communiqueront aussi avec le maître pour lui signifier qu’une nouvelle région doit être créée. – Hbase dépend du service ZooKeeper qui se charge de maintenir les informations du parc en cas de défaillance. Le maître et les serveurs de région sont tous enregistrés auprès du Zookeeper et si l’un d’eux subit une défaillance, Zookeeper se chargera de le faire réparer ou de le remplacer. Les tables sont automatiquement partitionnées horizontalement en régions que l’on peut résumer en un triplet : – la table à laquelle elle se reporte – la première entrée qu’il stocke – la première entrée qu’il ne stockera pas Initialement, une table contient une simple région mais au fur et à mesure que la taille de cette région augmente, celle-ci se divise en deux régions de tailles approximativement égales que Hbase répartira sur différents nœuds du cluster. Le maître est responsable d’assigner les régions aux serveurs de régions (comportement similaire aux nœuds de noms et nœuds de données de HDFS). On a donc affaire à une répartition des données centralisées autour de ces deux points d’entrée (le maître Hbase et le nœud de données HDFS). Le nœud de noms d’HDFS distribue, de manière presque uniforme, les nouvelles données dans les nœuds de données composant le cluster HDFS. Les données sont donc réparties de manière équitable. Mais, lorsque des nouveaux nœuds sont ajoutés au cluster, les données existantes ne vont pas être réparties sur ceux-ci ce qui entraîne un cluster non balancé (c’està-dire où les données ne sont pas réparties équitablement). Notons que les nouvelles entrées seront envoyées sur les nouveaux nœuds. Dans le cas d’une application à écritures fréquentes, le cluster retrouvera donc rapidement un état plus balancé. HDFS fournit aussi un outil qui obligera les données à se répartir de manière équitable sur les nœuds. Le maître Hbase se comporte différemment : il va toujours faire en sorte que les serveurs de régions s’occupent d’un nombre similaire de régions. 3.6.5 Réplication des données Hbase ne propose pas de système de réplication et repose sur le système répliqué de HDFS. Le concept de block est la base du modèle de réplication chez HDFS. La taille des blocks et le facteur de réplication peuvent être configurés par fichier. La réplication des blocks est assurée par le nœud de noms. Celui-ci reçoit périodiquement des “battements de coeur” (trad.Heartbeat) de chaque nœud de données (qui signifient leur bon fonctionnement) et des rapports sur les blocks (qui contiennent une liste de tous les blocks qu’il stocke). La requête d’écriture d’un client n’est pas directement transmise au nœud de noms, le client stocke d’abord le fichier localement et temporairement. Le client ne contacte le nœud de noms que lorsque le fichier a atteint la taille d’un block. Le nœud de noms insère le nom du fichier dans le système de fichiers et lui alloue des blocks. Le client transmet alors la donnée par petits morceaux (4KB) au premier nœud de données qui écrit ces morceaux et les transmet au deuxième nœud de données (supposons un facteur de réplication égal à 3). Celui-ci effectue le même processus. 36
Page 1 and 2: Faculté de Sciences Département I
Page 3 and 4: Table des matières 1 Introduction
Page 5 and 6: 5.3 Réplication de données . . .
Page 7 and 8: au cloud (les systèmes NoSQL, SQL-
Page 9 and 10: Chapitre 2 Le cloud computing et se
Page 11 and 12: dans cette couche. Cette classifica
Page 13 and 14: Le cloud dans la littérature “A
Page 15 and 16: Cette différence de vocation fait
Page 17 and 18: Par “assumer”, on entend fourni
Page 19 and 20: Définition 9. Dans un service tol
Page 21 and 22: on-OLTP applications that ured and
Page 23 and 24: Or la richesse du modèle de requê
Page 25 and 26: 3.2.5 Les solutions SQL-MR Map-Redu
Page 27 and 28: Le modèle en graphe Figure 3.3 - B
Page 29 and 30: MongoDB ne pose aucune restriction
Page 31 and 32: Réplication maître-esclave Ce mod
Page 33 and 34: 3.4.5 Modèle de consistance Par d
Page 35 and 36: Figure 3.13 - Cassandra - Un modèl
Page 37 and 38: égal au facteur de réplication, a
Page 39: Figure 3.14 - Architecture HDFS Les
Page 43 and 44: Système Modèle de données choix
Page 45 and 46: Figure 4.1 - YCSB - Cassandra - Pas
Page 47 and 48: 4.3.1 Scénario de tests Considéro
Page 49 and 50: importants que voulus durant une ce
Page 51 and 52: d’autant plus élastique que ce t
Page 53 and 54: Figure 4.7 - Perturbation de la pé
Page 55 and 56: - la distribution de génération d
Page 57 and 58: pour répartir les données. Dans u
Page 59 and 60: Rappelons que µ = 0.5 pour systèm
Page 61 and 62: - Taille initiale du cluster : 4 n
Page 63 and 64: De manière générale, on remarque
Page 65 and 66: 31.93 temps de reponse (millisecond
Page 67 and 68: temps de reponse (millisecondes) 55
Page 69 and 70: La forme de l’adaptation (α1, li
Page 71 and 72: Comme illustré en figure 4.17, la
Page 73 and 74: Figure 4.19 - Elasticité observée
Page 79 and 80: L’élasticité Tel que défini da
Page 81 and 82: Chapitre 5 Influence des choix tech
Page 83 and 84: (pour les déplacer ou pour les mod
Page 85 and 86: Remarquons que le fait de la distin
Page 87 and 88: Chapitre 6 Conclusion Dans ce trava
Page 89 and 90: étude (plus théorique que pratiqu
Page 91 and 92:
[18] E. Brewer. Towards Robust Dist
Page 93 and 94:
Annexe A Liste d’accronymes - API
Page 95 and 96:
Cassandra n’est pas évidente. Ce
Page 97 and 98:
ase sur le constat que, même si il
Page 99 and 100:
de tirer profit de toutes ses quali
Page 101 and 102:
• la couche insère les paramètr
Page 103 and 104:
[3] Apache Cassandra - Wiki, API. h
Page 105 and 106:
The R&D director’s blog Euranova
show all

L'élasticité des bases de données sur le cloud computing - CoDE

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

Delete template?

Save as template?