NoSQL - Systèmes de gestion de données distribués

Transcription

1 NoSQL - Systèmes de gestion de données distribués I. Mougenot mougenot@lirmm.fr Faculté des Sciences Université Montpellier I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

2 Préambule NoSQL Les motivations autour du NoSQL (Not Only SQL) Recouvre différentes initiatives qui se targuent d être complémentaires aux modèles relationnels et relationnels objets 1 évolution du Web, projets sources de données ouvertes (Open Linked Data) 2 ր volume des données ր interconnexion des données 3 limites des bases de données relationnelles : schémas très ouverts : nombreuses entités et nombreuses associations entre ces entités évolutions très fréquentes des schémas I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

3 Préambule NoSQL Quand passer par un système NoSQL? Alternatives au relationnel dans des cas de figure ciblés recours fréquent à de l évolution de schémas entités munies de nombreuses caractéristiques souvent non renseignées de multiples associations avec des multiplicités 1..* aux extrémités des attributs organisés naturellement sous forme d arborescences I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

4 Modèle EAV Problème posé par les entités protéiformes Premier effort de modélisation pour mieux comprendre le problème posé Patient PatientId {unique} nom: String dob: date genre: char(1) 1 datee: date * Examen nume {unique} poids: float glycemie: float frequencec: float cholesterolemie : float TA: float... Figure: Diagramme UML : dossier patient I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

5 Modèle EAV Modèle relationnel : traduction du modèle UML précédent Patient(PatientId, nom, dob, genre) Examen(NumE, datee, PatientId, Poids, Glycemie, FrequenceC,... ) avec PatientId Patient(PatientId) Premier problème : révision fréquente du schéma et notamment des colonnes des tables I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

6 Modèle EAV Problème posé par les entités protéiformes Relation Examen en extension nume datee PatientId Poids Glycemie FrequenceC /10/ null null /10/10 3 null 6 null /10/10 2 null null Figure: Schéma relationnel inapproprié I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

7 Modèle EAV Modèle Entité-Attribut-Valeur Rendre une partie du schéma générique vu parfois comme un antipatron Patient PatientId {unique} nom: String dob: date genre: char(1) * Attribut * AttributId {unique} AttributNom: String Datatype: String UniteMesure: String Data DateE : date value: String Figure: Diagramme de classes révisé I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

8 Modèle EAV Schéma relationnel Patient(PatientId, nom, dob, genre) Attribut(AttributId, AttributNom, Datatype, UniteMesure) Data (PatientId, AttributId, datee, value) avec PatientId Patient(PatientId) et AttributId Attribut(AttributId) I. Mougenot (UM2) GMIN332 C / 73

9 Modèle EAV Illustration relations en extension PatientId Nom Dob genre 3 Pierre Martin 20/10/1970 M 2 Marie Monin 20/10/1987 F Figure: Extension possible Patient AttributId AttributNom DataType UniteMesure 1 Poids float Kg 2 FrequenceC float puls/min 3 Glycemie float mmole/l 4 Diagnostic string null Figure: Extension possible Attribut I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

10 Modèle EAV Illustration relations en extension Relation Data en extension AttributId datee PatientId Value 1 20/10/ /10/ /10/ Figure: Extension possible Data I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

11 Modèle EAV EAV : approche hybride Distinction de différents niveaux dans le modèle Patient PatientId {unique} nom: String dob: date genre: char(1) * Attribut * AttributId {unique} AttributNom: String Datatype: String UniteMesure: String Conventionnel Data DateE : date value: String Meta donnees EAV Figure: Diagramme de classes révisé I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

12 Modèle EAV Dans le monde de la BD relationnelle Gérer trois niveaux d information au sein même de la base de données Dictionnaire de données ou méta-schéma : table des tables, table des attributs dans notre cas, la relation Attribut du modèle peut être vue à ce niveau, table des contraintes,... Schéma de données : table Patient, table Medecin,... Monde réel : tuples ou faits de la BD : patients Pierre Martin, Marie Monin,... I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

13 Des extensions au modèle EAV Type de données Prendre en charge des attributs de type LOB Les données de type image : rayon X, échographie, IRM,... nécessitent des considérations complémentaires Patient PatientId {unique} nom: String dob: date genre: char(1) * Data DateE : date DataId {unique} Attribut * AttributId {unique} AttributNom: String Datatype: String UniteMesure: String DataDate DataText DataImage Data... Value : date Value : varchar Value : blob Value :... Figure: De nouvelles classes pour une meilleure prise en charge des types de données associées aux valeurs des attributs I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

14 Des extensions au modèle EAV Type de données Illustration relations en extension AttributId datee PatientId DataId 1 20/10/ /10/ /10/ Figure: Extension possible Data dataid Value Figure: Extension possible DataFloat I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

15 Des extensions au modèle EAV Modèles relationnels inadaptés Limites des modèles relationnels Une solution générique, flexible et efficace (en matière de stockage) mais qui pose quelques problèmes à : l alimentation de la base de données (éclatement de l information, nécessité d étendre les tests de vérification de la validité des données saisies), l interrogation (requêtes SQL rendues plus complexes), l affichage (fournir une information complète et adaptée à la perception de l usager final). I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

16 Des extensions au modèle EAV Limites des modèles relationnels Exemple de requête simple en algèbre relationnelle Donner les patients qui pèsent plus de 70 kgs et qui ont une fréquence de moins de 120 puls/mn Modèle de départ : Π PatientId, nom, dob, genre ( poids > 70 frequencec <120 (Patient Examen)) Modèle EAV simple : Π PatientId, nom, dob, genre ( AttributNom= Poids Value > 70 (Patient Data Attribut)) Π PatientId, nom, dob, genre ( AttributNom= FrequenceC Value <120 (Patient Data Attribut)) I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

17 EAV/CR Des extensions au modèle EAV Autre extension possible CR pour Classes et Relations : ajout d une couche objet pour plus d expressivité dans le modèle ainsi que la prise en charge de structures complexes, notamment en ce qui concerne les métadonnées SousClasse * Classe * AttributType SuperClasse 1 AssocieA * Object 1 * AssocieA Attribut * Data * Figure: Diagramme de classes portant sur les aspects CR I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

18 Intérêts Des extensions au modèle EAV Autre extension possible Maîtrise le requêtage et l affichage Un objet est vu comme une collection de données qui vont pouvoir être restituées de concert à l usager, son voisinage avec d autres objets va pouvoir également être exploité en terme d affichage Une classe va permettre de typer les attributs et peut de plus être recadrée au travers d une hiérarchie de classes : cet ajout de structuration peut être profitable pour une meilleure consultation de l information (faciliter le requêtage) Un tel dispositif peut être mis en oeuvre au travers des surcouches objet/relationnel des SGBDR et notamment de la notion de ADT I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

19 Conclusions EAV Des extensions au modèle EAV Autre extension possible Le modèle EAV souvent décrié, souligne le besoin de schémas de données ouverts métamodèle RDF (triplet SPO) est en droite ligne de ce modèle systèmes NoSQL et la notion clé/valeur reprennent ce principe d ouverture Objectif : gérer de manière unifiée des entités munies de caractéristiques hétérogènes I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

20 Introduction au NOSQL NoSQL : se démarquer des SGBD relationnels Critiques ouvertes prépondérance du schéma et poids fort mis sur la représentation du domaine d intérêt : s affranchir de schémas normalisés vus comme des sophistications inutiles au détriment de l efficacité modèle transactionnel et propriétés ACID : proposer une alternative moins exigeante : CAP (comprenant BASE) passage à l échelle ou scalabilité (scalability) par ajout de serveurs au niveau de l architecture physique : diminuer le temps de réactivité lors de l afflux de nouveaux usagers, de nouvelles transactions à servir systèmes distribués et mécanismes de tolérance aux pannes : fragmentation des schémas et réplication, médiateur, entrepôt de données... I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

21 Introduction au NOSQL Passage à l échelle ou scalabilité Capacité de l architecture à s adapter à une montée en charge (nouveaux usagers, nouvelles transactions) sans besoin de refonte des applications scalabilité horizontale : ajouter des serveurs (noeuds) avec des mécanismes de répartition de charge NoSQL scalabilité verticale : rendre plus performant un serveur : ajout de processeurs (CPU), barrettes mémoire (RAM), disques secondaires, cartes réseaux... I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

22 Introduction au NOSQL Scalabilité horizontale Etablir une relation linéaire entre les ressources ajoutées et l accroissement des performances Nombre Transactions/Sec Nombre serveurs Figure: 1 serveur : 100 transactions/s ; 2 serveurs : 200 transactions/s... I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

23 Introduction au NOSQL SGBDR et besoins applicatifs à large échelle Limites face aux besoins des applications à large échelle sur le Web (à partir Web 2.0) partionnement : les schémas fragmentés (fragmentations horizontale, verticale, hybride) distribués sur l ensemble des partitions doivent être des fragments d un seul schéma de données initial réplication sur différents noeuds : les fondements OLTP (On Line transactional processing) imposent de maintenir une intégrité forte sur les données, dans une application faisant appel à de nombreux noeuds, la disponibilité des données va être pénalisée (surtout si les transactions impliquent de nombreuses écritures). I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

24 Introduction au NOSQL systèmes NoSQL : grands principes Pensés comme des systèmes de données distribués (distributed data stores) Simplicité Flexibilité Efficacité Passage à l échelle : gros volumes de données distribués et interconnectés partitionnement dynamique réplication à large échelle architecture décentralisée I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

25 Introduction au NOSQL Complémentarité des systèmes NoSQL Figure: Persistance dite polyglotte (extrait de NoSQL distilled) I. Mougenot (UM2) GMIN332 C / 73

26 Introduction au NOSQL Théorème CAP Ou théroràme de Brewer : indique qu aucun des systèmes distribués n est à même de satisfaire en même temps les principes C, A et P : 1 Consistency ou cohérence des données : toute modification de donnée est suivie d effet pour tous les noeuds du système 2 Availability ou disponibilité des données : toute requête émise et traitée par un noeud du système, reçoit une réponse (même en situation d échec à produire une réponse) 3 Partition tolerance ou recouvrement des noeuds assurer une continuité du fonctionnement en cas d ajout/suppression de noeud (ou partition) du système distribué Un système distribué va satisfaire deux des trois points mais ne va pouvoir satisfaire les trois - Brewer. Towards robust distributed systems - ACM 2000 I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

27 Introduction au NOSQL Théorème CAP Considérations SGBDR / Systèmes NoSQL 1 SGBDR : Cohérence et haute disponibilité (pas ou peu de P, cad de différents noeuds système) 2 Systèmes NoSQL : Choix du P (système naturellement distribué) et sélection soit du C, soit du A 1 abandon du A Accepte d attendre que les données soient cohérentes 2 abandon du C Accepte de recevoir des données parfois incohérentes I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

28 Introduction au NOSQL Positionnement des systèmes / CAP Figure: Synthèse CAP I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

29 Introduction au NOSQL Parti-pris Base (issu de CAP) versus propriétés ACID BASE : Basically Available, Soft state, Eventual consistency Modèle transactionnel : les propriétés ACID (Atomique, Cohérent, Isolé, Durable) des transactions des SGBDRs ne sont pas complètement respectées au profit des performances et du passage à l échelle BASE : réplication et partitionnement/sharding pour aller vers de la haute disponibilité des données distribuées sur les différents noeuds du système (faire en sorte de diminuer l impact de pannes éventuelles). Le résultat en est un système hautement disponible même si des sous-ensembles de données peuvent devenir indisponibles sur de de courtes périodes Basiquement disponible I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

30 Introduction au NOSQL Parti-pris Base (issu de CAP) versus propriétés ACID BASE : Basically Available, Soft state, Eventual consistency dans l idée les systèmes NoSQL garantissent que les données deviennent cohérentes non pas en instantané mais au travers du temps. Les propriétés ACID nécessitent un verrouillage pessimiste et obligent à vérifier la cohérence des données à chaque fin de transaction. BASE propose une vision optimiste en reportant à plus tard la vérification de la cohérence de la base de données cohérente à terme. L état du système peut changer au travers du temps et cela sans nouvelle mise à jour en raison du modèle cohérence à terme Etat lâche I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

31 Introduction au NOSQL Typologie des systèmes NoSQL Au regard du mode de représentation choisi principe de base : clé/valeur Systèmes clé/valeur distribués Systèmes orientés colonne Systèmes orientés document Systèmes orientés graphe dans un certaine mesure les triples stores I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

32 Introduction au NOSQL Illustration typologie NoSQL Figure: I. Mougenot (UM2) GMIN332 C / 73

33 Introduction au NOSQL Difficulté : absence de standards Au regard du mode de représentation comme du système choisis 1 APIs spécifiques 2 Terminologies propriétaires 3 Mécanismes de requêtage à géométrie variable 1 Systèmes ayant fait école ( proofs of concept ) 1 BigTable 2 Memcached 3 Amazon s Dynamo I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

34 Introduction au NOSQL Systèmes existants Table: Quelques systèmes et leurs modes de représentation Name Mode représentation CAP CouchDB Document AP MongoDB Document CP Neo4j Graph CA GraphDB Graph unknown Hbase Column CP Memcachedb Key-Value unknown Riak Key-Value CP Project Voldemort Key-Value AP Cassandra Column AP Hypertable Column unknown I. Mougenot (UM2) GMIN332 C / 73

35 Introduction au NOSQL Systèmes existants Table: Applications communautaires sur le Web Name Système NoSQL Mode Google BigTable, LevelDB Column LinkedIn Voldemort Key-Value Facebook Cassandra Column Twitter Hadoop/Hbase, Cassandra Column Netflix SimpleDB, Hadoop/HBase, Cassandra Column CERN CouchDB Document Amazon Dynamo Key-Value I. Mougenot (UM2) GMIN332 C / 73

36 Clé/Valeur Exemple significatif : les tweets followed follows date_f: timestamp User Id:integer {unique} name: String password: string creation: timestamp * * follower 1 Tweet * Id:integer {unique} message: String date_t: timestamp Figure: Modèle conceptuel des tweets I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

37 Clé/Valeur Key-Value : table de hachage UserID uid:234 Username "Jean Mineur" taille key restreinte taille value : string,..., blob Password "Balzac 00 01" uid:234:username "Jean Mineur" uid:234:followers uid:266, uid:333, uid:989,... Figure: Exemples de clé/valeur I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

38 Clé/Valeur Key-Value : hash ring Table de hachage distribuée (DHT), stratégie de placement, répartition des charges, limiter les effets des pannes Partitionnement Placement Key Ex : hash(user:userid) : Hash ring Replication sur plusieurs noeuds uid: Figure: Illustration Hash ring I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

39 Clé/Valeur Les opérations les plus courantes Les mécanismes de consultation plus sophistiqués vont permettre de distinguer systèmes clé/valeur avec les systèmes à base de documents ou de colonnes 1 lecture à partir de la clé 2 écriture (create ou put, update, delete) à partir de la clé I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

40 Clé/Valeur Les systèmes les plus représentatifs 1 Riak : (basho) système persistant : disque et B+ Tree, distribué, open source Amazon Dynamo 2 Memcachedb : volatile, non distribué 3 BerkeleyDB (Oracle) 4 Amazon Dynamo 5 Tokyo Cabinet I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

41 Colonne Idées préalables Colonnes : quelques anciens principes pour dépasser les limites du relationnel Données complexes, multivaluées et éparses modèle orienté colonne : les colonnes deviennent les lignes : wide and sparse data : faciliter l évolution du schéma modèle NF2 Non First Normal Form : s affranchir de la contrainte de la première forme normale et gérer des données multi-valuées (collections) et composites (types complexes) I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

42 Colonne Systèmes orientés colonne Idées préalables PatientCode Firstname LastName DOB Address B_A_0001 Jean Martin 5/5/55 Montpellier B_A_0002 Marie Dupont 6/6/66 Ales B_A_0003 Marc Dulac 7/7/77 Sete PatientCode B_A_0001 B_A_0002 B_A_ Firstname Jean Marie Marc... LastName Martin Dupont Dulac... DOB Address 5/5/55 6/6/66 7/7/77 Montpellier Ales Sete Figure: Rotation de 90 degrés I. Mougenot (UM2) GMIN332 C / 73

43 Colonne Idées préalables Systèmes orientés colonne : partitionnement vertical schema Aware des triple stores PatientCode Firstname PatientCode Address B_A_0001 Jean B_A_0001 Montpellier B_A_0002 Marie B_A_0002 Ales B_A_0003 Marc B_A_0003 Sete PatientCode B_A_0001 LastName Martin B_A_0002 Dupont B_A_ Dulac... I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

44 Colonne Idées préalables Colonnes : quelques exemples de systèmes A l origine dans les années : Decomposition Storage Model. SBGDR sous-jacents (usage de vues matérialisées) Académiques C-Store (MIT Cambridge MA) : depuis 2005 MonetDB (CWI Amsterdam) : pionnier en la matière Commerciaux Vertica (C-Store) Sybase IQ InfoBright MySQL I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

45 Colonne Idées préalables Domaines d application phare pour les systèmes orientés colonnes Exploités ou source d inspiration pour : Entrepôts de données Fouille de données Jeux de données scientifiques : santé, écologie, astrophysique, génomique fonctionnelle... Modèles RDF (triple stores) Google Big Table I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

46 Colonne Idées préalables Modèle NF2 : inspiration TAD (SQL3) Données composites et multi-valuées (collection) PatientCode Firstname LastName DOB Symptoms B_A_0001 Jean Ernest Martin 5/5/55 name value date sneezing severe 3/3/3 itchy_troat severe 3/3/3 B_A_0002 Marie Dupont 6/6/66... B_A_0003 Marc Dulac 7/7/77... Antoine Figure: Illustration modèle NF2 I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

47 Colonne Idées préalables Modèle NF2 : SGBD Objet-Relationnel Exemples de types de données abstraits avec Oracle Create type Tsymptom as object (name varchar(15), value varchar(10) diag_date date, ) / Create type coll_symptoms as Table of Tsymptom / Create table Patient (code varchar(8), firstname coll_fsn, lastname varchar(20), dob Date, symptoms coll_symptoms); Nested table symptoms Store As allsymptoms I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

48 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Pour éviter les confusions : oriented Column family plutôt que Column paradigmes : clé/valeur et colonne de manière à représenter les multiples clés possibles Colonne : : triplet : nom de colonne / valeur de colonne / estampille (gérer les versions et les conflits) Famille de colonnes : : regrouper les colonnes qui sont partagées par un ensemble d individus ( property tables et modèle hybride des triple store) Super familes de colonnes : : extension du modèle avec la notion de super familles qui sont des collections de colonnes (poser des index à différents niveaux) I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

49 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Illustration Column family column_name_ column_name_n row_key_x column_value_ column_value_n timestamp_ timestamp_n row_key_x => { column_name_1: column_value_1,... column_name_n: column_value_n, } Figure: Vision générique I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

50 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Illustration Column family PatientCode Firstname LastName Address B_A_0001 B_A_0001 Jean Dupont Montpellier PatientCode Firstname LastName Function OfficeNumber B_A_0002 B_A_0002 Marie Martin Commercial Figure: Exemple de deux tuples d une famille I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

51 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Ecriture inspirée de la notation JSON B_A_0001 => { Gal_Infos:PatientCode: B_A_0001, Gal_Infos:Firstname: Jean, Gal_Infos:LastName: Dupont, Gal_Infos:Address: Montpellier, Allergy_Infos:Sneezing: mild, Allergy_Infos:Itchy_Troat: severe, Allergy_Infos:Snuffy_Nose: moderate, Allergy_Infos:Watery_Eyes: mild, Allergy_Infos:Itchy_Nose: severe, } I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

52 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Illustration Column family CF:Gal_Infos PatientCode Firstname LastName Address B_A_0001 B_A_0001 Jean Dupont Montpellier CF:Allergy_Infos Sneezing Itchy_Troat Snuffy_Nose Watery_Eyes Itchy_Nose B_A_0001 mild severe moderate mild severe Figure: Exemple de deux familles de colonnes I. Mougenot (UM2) GMIN332 C / 73

53 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Illustration Super Column family Super_Column_Name_1 Super_Column_Name_n row_key_x column_name_1 column_value_ column_name_n column_value_n column_name_1... column_value_1... column_name_n column_value_n timestamp_1... timestamp_n... timestamp_1... timestamp_n row_key_x => { Super_Column_Name_1 { column_name_1: column_value_1,... column_name_n: column_value_n, } Super_Column_Name_1 { column_name_1 : column_value_1,... column_name_n : column_value_n, } Figure: Vision générique I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

54 NoSQL et familles de colonnes Systèmes NoSQL à colonnes Ecriture inspirée de la notation JSON B_A_0001 => { Gal_Infos : {PatientCode: B_A_0001, Firstname: Jean, LastName: Dupont, Address: Montpellier, } Allergy_Infos: {Sneezing: mild, Itchy_Troat: severe, Snuffy_Nose: moderate, Watery_Eyes: mild, Itchy_Nose: severe, } } I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

55 NoSQL et familles de colonnes NoSQL : systèmes S inspirent largement de Google BigTable(1) Cassandra Hbase (1) BigTable - A distributed storage system for distributed data - Chang et al, 2006 I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

56 NoSQL et familles de colonnes HBase HBAse : système column family Distribué, privilégie la cohérence et la disponibilité des données sans oublier les performances S appuie sur Hadoop (projet open source Apache) qui facilite le traitement distribué de larges jeux de données et ses composants Hadoop Core = HDFS pour le stockage MasterServer : namenode (mode master/slave) RegionServer : datanode Zookeeper : infrastructure centralisée et services pour gérer un cluster de serveurs : parmi les activités : synchronization, choix du serveur maître et vérification de la disponibilité des serveurs MapReduce : modèle de programmation distribuée I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

57 NoSQL et familles de colonnes Architecture de HBase HBase Figure: Vision générale I. Mougenot (UM2) GMIN332 C / 73

58 NoSQL et familles de colonnes Structurellement parlant : HBase unité de base : table (keyspace) fragmentée en parties égales = régions (intervalles de valeurs de clés) tables triées sur la valeur de la clé familles : nombre quelconque de colonnes colonne (qualifier) : dont les valeurs peuvent être en nombre quelconque de versions (horodatage) (table, row, column family, column qualifier, timestamp) -> value (la valeur de la donnée est stockée avec l ensemble de ses coordonnées) à noter : pas de super colonne avec HBase I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

59 NoSQL et familles de colonnes Organisation de la donnée HBase Figure: I. Mougenot (UM2) GMIN332 C / 73

60 Aspects internes Aspects internes à l architecture de Hbase Structures mises en jeu 1 familles de colonnes (CF) dont les colonnes sont stockées dans les mêmes fichiers bas niveau = HFile 2 une table est associée à une ou à plusieurs régions (partition de valeurs) selon les besoins en matière de place 3 HStore : une zone tampon par région associée à une table : 4 MemStore : une mémoire assignée au tri des tuples et à l écriture séquentielle du flux de données dans les fichiers de données (HFile) - Sort & Flush 5 CachingBlock : tampon de données en mémoire vive 6 HFile : 1 à plusieurs fichiers de données par région 7 HLog : 1 fichier journal par RegionServer 8 Block : unité d échange entre les mémoires vive et de masse (64 Ko à l ordinaire) I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

61 Aspects internes Orchestration de différents composants Table + name : string 1 1..* associatedto Region * 1 RegionServer locatedon 1 HStore 1 LogFile (WAL) Column + name : byte[] + value : byte[] + time : timestamp * 1 ColumnFamily + name : byte[] 1 MemStore CachingBlock stores 1 HFile Figure: Diagramme de classes : structures internes I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

62 Aspects internes Orchestration de différents composants Figure: Extrait de HBase internals and schema design presentation I. Mougenot (UM2) GMIN332 C / 73

63 Aspects internes Mécanisme de reprise Figure: Ecriture dans fichier journal pour restauration éventuelle I. Mougenot (UM2) GMIN332 C / 73

64 Aspects internes Fichiers de données Structure d index : Log Structured Merge (LSM) Tree optimisée pour les accès séquentiels Figure: Ordonnancement des valeurs des colonnes sur la base de la clé du tuple I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

65 Aspects internes Fichiers de données Figure: I. Mougenot (UM2) GMIN332 C / 73

66 Aspects internes Page d accueil (WebApp) Figure: I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

67 Aspects internes Accès et traitement des données Accès plus impératif que déclaratif 1 pas de langage DSL à l exemple de SQL pour requêter les données 2 accès imperatif au travers d API clientes : Java mais recours possible à d autres langages JRuby, Clojure, Scala, Jython,... 3 notion de coprocessor pour traiter directement les données au niveau d un noeud de données (RegionServer) 4 complémentarité avec le framework MapReduce qui fournit des wrappers pour convertir les tables en collection de paires clé/valeur en entrée comme en sortie de diverses tâches d analyse I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

68 En pratique Aspects internes Clients HBase API Java Shell HBase (JRuby) Clients non-java serveurs Thrifts (Ruby, C++, Erlang,... ) serveurs Rest (Stargate) I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

69 Aspects internes Construire une table et deux colonnes avec JRuby create ville, ig, ip10 put ville, 01024, ig:codeinsee, put ville, 01024, ig:nom, Attignat put ville, 01024, ig:popmun, 2850 put ville, 34172, ig:codeinsee, put ville, 34172, ig:nom, Montpellier put ville, 34172, ig:popmun, put ville, 34172, ip10:nbreredevables, put ville, 34172, ip10:nbreredevables, 1914 delete ville, 34172, ip10:nbreredevables scan ville resultats ROW COLUMN+CELL column=ig:codeinsee, timestamp= , value= column=ig:nom, timestamp= , value=attignat... I. Mougenot (UM2) GMIN332 C / 73

70 Aspects internes Exemples API Java Opérations élémentaires 1 opérations sur une table : create, scan, disable, drop 2 opérations sur un tuple : put, delete, get 3 notions de filtre à partir du parcours des tuples d une table I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73

71 Aspects internes Construire une table et insertion de tuples Configuration hc = HBaseConfiguration.create(); HTableDescriptor ht = new HTableDescriptor( "patient" ); ht.addfamily( new HColumnDescriptor( "allergy" ) ); Put pierreput = new Put(new String("P_M_001").getBytes()); pierreput.add(new String("allergy").getBytes(), new String("sneezing").getBytes(), new String("mild").getBytes()); HBaseAdmin hba = new HBaseAdmin( hc ); System.out.println( "creating table...patient " ); hba.createtable( ht ); HTable table = new HTable(hc, "patient"); System.out.println( "creating row...pierre " ); table.put(pierreput); Listing 2: Une table et un tuple I. Mougenot mougenot@lirmm.fr (UM2) GMIN332 C / 73