NoSQL - Syst `emes de gestion de donn ´ees distribu ´es
I. Mougenotmougenot@lirmm.fr
Facult ´e des Sciences Universit ´e Montpellier 2
Pr ´eambule NoSQL
Les motivations autour du NoSQL (Not Only SQL)
Recouvre diff ´erentes initiatives qui se targuent d’ ˆetre compl ´ementaires aux mod `eles relationnels et relationnels objets
1 ´evolution du Web, projets sources de donn ´ees ouvertes (Open Linked Data)
2 րvolume des donn ´eesրinterconnexion des donn ´ees
3 limites des bases de donn ´ees relationnelles :
sch ´emas tr `es ouverts : nombreuses entit ´es et nombreuses associations entre ces entit ´es
´evolutions tr `es fr ´equentes des sch ´emas
Pr ´eambule NoSQL
Quand passer par un syst `eme NoSQL ?
Alternatives au relationnel dans des cas de figure cibl ´es
recours fr ´equent `a de l’ ´evolution de sch ´emas
entit ´es munies de nombreuses caract ´eristiques souvent non renseign ´ees
de multiples associations avec des multiplicit ´es 1..* aux extr ´emit ´es des attributs organis ´es naturellement sous forme d’arborescences
Mod `ele EAV
Probl `eme pos ´e par les entit ´es ”prot ´eiformes”
Premier effort de mod ´elisation pour mieux comprendre le probl `eme pos ´e
Examen
glycemie: float cholesterolemie : float frequenceC: float 1
*
dateE: date
....
numE {unique}
poids: float
TA: float Patient
PatientId {unique}
nom: String dob: date genre: char(1)
Figure:Diagramme UML : dossier patient
Mod `ele EAV
Mod `ele relationnel : traduction du mod `ele UML pr ´ec ´edent
Patient(PatientId, nom, dob, genre)
Examen(NumE, dateE, PatientId, Poids, Glycemie, FrequenceC, . . . )
avec PatientId⊆Patient(PatientId)
Premier probl `eme : r ´evision fr ´equente du sch ´ema et notamment des colonnes des tables
Mod `ele EAV
Probl `eme pos ´e par les entit ´es ”prot ´eiformes”
Relation Examen en extension
numE dateE PatientId Poids Glycemie FrequenceC ...
1 20/10/10 3 79 null null ...
2 28/10/10 3 null 6 null ...
3 28/10/10 2 null null 170 ...
Figure:Sch ´ema relationnel inappropri ´e
Mod `ele EAV
Mod `ele Entit ´e-Attribut-Valeur
Rendre une partie du sch ´ema g ´en ´erique vu parfois comme un anti- patron
Attribut
Datatype: String UniteMesure: String
*
* AttributId {unique}
AttributNom: String Patient
PatientId {unique}
nom: String dob: date genre: char(1)
Data DateE : date value: String
Figure:Diagramme de classes r ´evis ´e
Mod `ele EAV
Sch ´ema relationnel
Patient(PatientId, nom, dob, genre)
Attribut(AttributId, AttributNom, Datatype, UniteMesure) Data (PatientId, AttributId, dateE, value)
avec PatientId⊆Patient(PatientId) et AttributId⊆ Attribut(AttributId)
Mod `ele 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
Mod `ele EAV
Illustration relations en extension
Relation Data en extension
AttributId dateE PatientId Value
1 20/10/10 3 79
3 28/10/10 3 6
2 28/10/10 2 170
Figure:Extension possible Data
Mod `ele EAV
EAV : approche hybride
Distinction de diff ´erents niveaux dans le mod `ele
Attribut
Datatype: String UniteMesure: String
* * AttributId {unique}
AttributNom: String Patient
PatientId {unique}
nom: String dob: date genre: char(1)
Data DateE : date value: String Conventionnel
EAV
Meta−donnees
Figure:Diagramme de classes r ´evis ´e
Mod `ele EAV
Dans le monde de la BD relationnelle
G ´erer trois niveaux d’information au sein m ˆeme de la base de donn ´ees Dictionnaire de donn ´ees ou m ´eta-sch ´ema : table des tables, table des attributsdans notre cas, la relation Attribut du mod `ele peut
ˆetre vue `a ce niveau, table des contraintes, . . .
Sch ´ema de donn ´ees : table Patient, table Medecin, . . . Monde r ´eel : tuples ou faits de la BD : patients Pierre Martin, Marie Monin, . . .
Des extensions au mod `ele EAV Type de donn ´ees
Prendre en charge des attributs de type LOB
Les donn ´ees de type image : rayon X, ´echographie, IRM, . . . n ´ecessitent des consid ´erations compl ´ementaires
Data DateE : date DataId {unique}
Attribut
Datatype: String UniteMesure: String
*
* AttributId {unique}
AttributNom: String Patient
PatientId {unique}
nom: String dob: date genre: char(1)
DataDate Value : date
DataText Value : varchar
DataImage Data...
Value : blob Value : ...
Figure:De nouvelles classes pour une meilleure prise en charge des types de donn ´ees associ ´ees aux valeurs des attributs
Des extensions au mod `ele EAV Type de donn ´ees
Illustration relations en extension
AttributId dateE PatientId DataId
1 20/10/10 3 1
3 28/10/10 3 2
2 28/10/10 2 3
Figure:Extension possible Data
dataId Value
1 79
2 6
3 170
Figure:Extension possible DataFloat
Des extensions au mod `ele EAV Limites des mod `eles relationnels
Mod `eles relationnels inadapt ´es
Une solution g ´en ´erique, flexible et efficace (en mati `ere de stockage) mais qui pose quelques probl `emes `a :
l’alimentation de la base de donn ´ees ( ´eclatement de l’information, n ´ecessit ´e d’ ´etendre les tests de v ´erification de la validit ´e des donn ´ees saisies),
l’interrogation (requ ˆetes SQL rendues plus complexes), l’affichage (fournir une information compl `ete et adapt ´ee `a la perception de l’usager final).
Des extensions au mod `ele EAV Limites des mod `eles relationnels
Exemple de requ ˆete simple en alg `ebre relationnelle
Donner les patients qui p `esent plus de 70 kgs et qui ont une fr ´equence de moins de 120 puls/mn
Mod `ele de d ´epart : ΠPatientId, nom, dob, genre (poids>70∧ frequenceC<120 (Patient✶Examen))
Mod `ele EAV simple :
ΠPatientId, nom, dob, genre (AttributNom=’Poids’∧Value>70 (Patient✶Data✶Attribut))
∩
ΠPatientId, nom, dob, genre (AttributNom=’FrequenceC’∧ Value<120 (Patient✶Data✶Attribut))
Des extensions au mod `ele EAV Autre extension possible
EAV/CR
CR pour Classes et Relations : ajout d’une couche objet pour plus d’expressivit ´e dans le mod `ele ainsi que la prise en charge de structures complexes, notamment en ce qui concerne les m ´etadonn ´ees
Classe
Attribut AttributType
* 1
Object 1
* SuperClasse
SousClasse
Data AssocieA
AssocieA
*
*
*
*
Figure:Diagramme de classes portant sur les aspects CR
Des extensions au mod `ele EAV Autre extension possible
Int ´er ˆets
Maˆıtrise le requ ˆetage et l’affichage
Un objet est vu comme une collection de donn ´ees qui vont pouvoir ˆetre restitu ´ees de concert `a l’usager, son voisinage avec d’autres objets va pouvoir ´egalement ˆetre exploit ´e en terme d’affichage Une classe va permettre de typer les attributs et peut de plus ˆetre recadr ´ee au travers d’une hi ´erarchie de classes : cet ajout de structuration peut ˆetre profitable pour une meilleure consultation de l’information (faciliter le requ ˆetage)
Un tel dispositif peut ˆetre mis en oeuvre au travers des surcouches
”objet/relationnel” des SGBDR et notamment de la notion de ADT
Des extensions au mod `ele EAV Autre extension possible
Conclusions EAV
Le mod `ele EAV souvent d ´ecri ´e, souligne le besoin de sch ´emas de donn ´ees ouverts
m ´etamod `ele RDF (triplet SPO) est en droite ligne de ce mod `ele syst `emes NoSQL et la notion cl ´e/valeur reprennent ce principe d’ouverture
Objectif : g ´erer de mani `ere unifi ´ee des entit ´es munies de car- act ´eristiques h ´et ´erog `enes
Introduction au NOSQL
NoSQL : se d ´emarquer des SGBD relationnels
Critiques ouvertes
pr ´epond ´erance du sch ´ema et poids fort mis sur la repr ´esentation du domaine d’int ´er ˆet : s’affranchir de sch ´emas normalis ´es vus comme des sophistications inutiles au d ´etriment de l’efficacit ´e mod `ele transactionnel et propri ´et ´es ACID : proposer une alternative moins exigeante : CAP (comprenant BASE) passage `a l’ ´echelle ou scalabilit ´e (scalability) par ajout de
serveurs au niveau de l’architecture physique : diminuer le temps de r ´eactivit ´e lors de l’afflux de nouveaux usagers, de nouvelles transactions `a servir
syst `emes distribu ´es et m ´ecanismes de tol ´erance aux pannes : fragmentation des sch ´emas et r ´eplication, m ´ediateur, entrep ˆot de donn ´ees . . .
Introduction au NOSQL
Passage `a l’ ´echelle ou scalabilit ´e
Capacit ´e de l’architecture `a s’adapter `a une mont ´ee en charge (nou- veaux usagers, nouvelles transactions) sans besoin de refonte des ap- plications
scalabilit ´e horizontale : ajouter des serveurs (noeuds) avec des m ´ecanismes de r ´epartition de charge⇐NoSQL
scalabilit ´e verticale : rendre plus performant un serveur : ajout de processeurs (CPU), barrettes m ´emoire (RAM), disques
secondaires, cartes r ´eseaux . . .
Introduction au NOSQL
Scalabilit ´e horizontale
Etablir une relation lin ´eaire entre les ressources ajout ´ees et l’accroissement des performances
1 2 3 4 5
1 2 3 4 5
Nombre Transactions/Sec
Nombre serveurs
Figure:1 serveur : 100 transactions/s ; 2 serveurs : 200 transactions/s . . .
Introduction au NOSQL
SGBDR et besoins applicatifs `a large ´echelle
Limites face aux besoins des applications `a large ´echelle sur le Web ( `a partir Web 2.0)
partionnement : les sch ´emas fragment ´es (fragmentations horizontale, verticale, hybride) distribu ´es sur l’ensemble des partitions doivent ˆetre des fragments d’un seul sch ´ema de donn ´ees initial
r ´eplication sur diff ´erents noeuds : les fondements OLTP (On Line transactional processing) imposent de maintenir une int ´egrit ´e forte sur les donn ´ees, dans une application faisant appel `a de
nombreux noeuds, la disponibilit ´e des donn ´ees va ˆetre p ´enalis ´ee (surtout si les transactions impliquent de nombreuses ´ecritures).
Introduction au NOSQL
syst `emes NoSQL : grands principes
Pens ´es comme des syst `emes de donn ´ees distribu ´es (distributed data stores)
Simplicit ´e Flexibilit ´e Efficacit ´e
Passage `a l’ ´echelle : gros volumes de donn ´ees distribu ´es et interconnect ´es
partitionnement dynamique r ´eplication `a large ´echelle architecture d ´ecentralis ´ee
Introduction au NOSQL
Compl ´ementarit ´e des syst `emes NoSQL
Figure:Persistance dite polyglotte (extrait de NoSQL distilled)
Introduction au NOSQL
Th ´eor `eme CAP
Ou th ´eror `ame de Brewer : indique qu’aucun des syst `emes distribu ´es n’est `a m ˆeme de satisfaire en m ˆeme temps les principes C, A et P :
1 Consistency ou coh ´erence des donn ´ees : toute modification de donn ´ee est suivie d’effet pour tous les noeuds du syst `eme
2 Availability ou disponibilit ´e des donn ´ees : toute requ ˆete ´emise et trait ´ee par un noeud du syst `eme, rec¸oit une r ´eponse (m ˆeme en situation d’ ´echec `a produire une r ´eponse)
3 Partition tolerance ou recouvrement des noeuds assurer une continuit ´e du fonctionnement en cas d’ajout/suppression de noeud (ou partition) du syst `eme distribu ´e
Un syst `eme distribu ´e va satisfaire deux des trois points mais ne va pou- voir satisfaire les trois - Brewer. Towards robust distributed systems - ACM 2000
Introduction au NOSQL
Th ´eor `eme CAP
Consid ´erations SGBDR / Syst `emes NoSQL
1 SGBDR : Coh ´erence et haute disponibilit ´e (pas ou peu de P, cad de diff ´erents noeuds syst `eme)
2 Syst `emes NoSQL : Choix du P (syst `eme naturellement distribu ´e) et s ´election soit du C, soit du A
1 abandon du A⇐Accepte d’attendre que les donn ´ees soient coh ´erentes
2 abandon du C⇐Accepte de recevoir des donn ´ees parfois incoh ´erentes
Introduction au NOSQL
Positionnement des syst `emes / CAP
Figure:Synth `ese CAP
Introduction au NOSQL
Parti-pris Base (issu de CAP) versus propri ´et ´es ACID
BASE : Basically Available, Soft state, Eventual consistency
Mod `ele transactionnel : les propri ´et ´es ACID (Atomique,
Coh ´erent, Isol ´e, Durable) des transactions des SGBDRs ne sont pas compl `etement respect ´ees au profit des performances et du passage `a l’ ´echelle
BASE :
r ´eplication et partitionnement/sharding pour aller vers de la haute disponibilit ´e des donn ´ees distribu ´ees sur les diff ´erents noeuds du syst `eme (faire en sorte de diminuer l’impact de pannes
´eventuelles). Le r ´esultat en est un syst `eme hautement disponible m ˆeme si des sous-ensembles de donn ´ees peuvent devenir indisponibles sur de de courtes p ´eriodes⇐”Basiquement
Introduction au NOSQL
Parti-pris Base (issu de CAP) versus propri ´et ´es ACID
BASE : Basically Available, Soft state, Eventual consistency
dans l’id ´ee les syst `emes NoSQL garantissent que les donn ´ees deviennent coh ´erentes non pas en instantan ´e mais au travers du temps. Les propri ´et ´es ACID n ´ecessitent un verrouillage
pessimiste et obligent `a v ´erifier la coh ´erence des donn ´ees `a chaque fin de transaction. BASE propose une vision optimiste en reportant `a plus tard la v ´erification de la coh ´erence de la base de donn ´ees⇐”coh ´erente `a terme”.
L’ ´etat du syst `eme peut changer au travers du temps et cela sans nouvelle mise `a jour en raison du mod `ele ”coh ´erence `a terme”⇐
”Etat l ˆache”
Introduction au NOSQL
Typologie des syst `emes NoSQL
Au regard du mode de repr ´esentation choisi principe de base : cl ´e/valeur
Syst `emes cl ´e/valeur distribu ´es Syst `emes orient ´es colonne Syst `emes orient ´es document Syst `emes orient ´es graphe
dans un certaine mesure les triples stores
Introduction au NOSQL
Illustration typologie NoSQL
Figure:
Introduction au NOSQL
Difficult ´e : absence de standards
Au regard du mode de repr ´esentation comme du syst `eme choisis
1 APIs sp ´ecifiques
2 Terminologies propri ´etaires
3 M ´ecanismes de requ ˆetage `a g ´eom ´etrie variable
1 Syst `emes ayant fait ´ecole (”proofs of concept”)
1 BigTable
2 Memcached
3 Amazon’s Dynamo
Introduction au NOSQL
Syst `emes existants
Table:Quelques syst `emes et leurs modes de repr ´esentation
Name Mode repr ´esentation 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
Introduction au NOSQL
Syst `emes existants
Table:Applications communautaires sur le Web
Name Syst `eme 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
Cl ´e/Valeur
Exemple significatif : les tweets
Id:integer {unique}
name: String password: string creation: timestamp User
Tweet
Id:integer {unique}
message: String date_T: timestamp
date_f: timestamp follows
1
*
*
* followed
follower
Figure:Mod `ele conceptuel des tweets
Cl ´e/Valeur
Key-Value : table de hachage
"Jean Mineur"
"Jean Mineur"
UserID
Username
Password
uid:234
"Balzac 00 01"
uid:234:Username
uid:234:followers uid:266, uid:333, uid:989, ...
taille key restreinte
taille value : string, ..., blob
Cl ´e/Valeur
Key-Value : ”hash ring”
Table de hachage distribu ´ee (DHT), strat ´egie de placement, r ´epartition des charges, limiter les effets des pannes
uid:234 Hash ring
0 .. 99
100 .. 199
200 .. 299
300 .. 399
... .. ...
Placement Key
Ex : hash(user:userid) : 0 .. 1000 Partitionnement
Replication sur plusieurs noeuds
Figure:Illustration Hash ring
Cl ´e/Valeur
Les op ´erations les plus courantes
Les m ´ecanismes de consultation plus sophistiqu ´es vont permettre de distinguer syst `emes cl ´e/valeur avec les syst `emes `a base de documents ou de colonnes
1 lecture `a partir de la cl ´e
2 ´ecriture (create ou put, update, delete) `a partir de la cl ´e
Cl ´e/Valeur
Les syst `emes les plus repr ´esentatifs
1 Riak : (basho) syst `eme persistant : disque et B+ Tree, distribu ´e, open source Amazon Dynamo
2 Memcachedb : volatile, non distribu ´e
3 BerkeleyDB (Oracle)
4 Amazon Dynamo
5 Tokyo Cabinet
Colonne Id ´ees pr ´ealables
Colonnes : quelques ”anciens” principes pour d ´epasser les limites du relationnel
Donn ´ees complexes, multivalu ´ees et ´eparses
mod `ele orient ´e colonne : les colonnes deviennent les lignes :
”wide and sparse data” : faciliter l’ ´evolution du sch ´ema
mod `ele NF2 Non First Normal Form : s’affranchir de la contrainte de la premi `ere forme normale et g ´erer des donn ´ees multi-valu ´ees (collections) et composites (types complexes)
Colonne Id ´ees pr ´ealables
Syst `emes orient ´es colonne
Jean 5/5/55 Montpellier
DOB LastName
Firstname PatientCode
Marc Dulac 7/7/77 Sete
6/6/66 Ales Dupont
Marie B_A_0002
... ... ... ... ...
PatientCode
Firstname
LastName
DOB
Address B_A_0001
Address
B_A_0001 B_A_0002 ...
B_A_0003
...
...
...
...
B_A_0003
Jean Marc
Martin
Marie
Dulac Martin
Dupont
5/5/55 6/6/66 7/7/77
Montpellier Ales Sete
Figure:Rotation de 90 degr ´es
Colonne Id ´ees pr ´ealables
Syst `emes orient ´es colonne : partitionnement vertical
∼”schema Aware” des triple stores
B_A_0002
...
B_A_0001
B_A_0003 PatientCode
Jean
Marc Marie
...
Firstname
B_A_0002
...
B_A_0001
B_A_0003 PatientCode
Montpellier Ales
Sete ...
Address
B_A_0002 B_A_0001
B_A_0003 PatientCode
Martin LastName
Dulac Dupont
Colonne Id ´ees pr ´ealables
Colonnes : quelques exemples de syst `emes
A l’origine dans les ann ´ees 80-90 : Decomposition Storage Model.
SBGDR sous-jacents (usage de vues mat ´erialis ´ees)
Acad ´emiques
C-Store (MIT Cambridge MA) : depuis 2005
MonetDB (CWI Amsterdam) : pionnier en la mati `ere Commerciaux
Vertica (C-Store) Sybase IQ
InfoBright MySQL
Colonne Id ´ees pr ´ealables
Domaines d’application phare pour les syst `emes orient ´es colonnes
Exploit ´es ou source d’inspiration pour :
Entrep ˆots de donn ´ees Fouille de donn ´ees
Jeux de donn ´ees scientifiques : sant ´e, ´ecologie, astrophysique, g ´enomique fonctionnelle . . .
Mod `eles RDF (triple stores) Google Big Table
Colonne Id ´ees pr ´ealables
Mod `ele NF2 : inspiration TAD (SQL3)
Donn ´ees composites et multi-valu ´ees (collection)
PatientCode Firstname Jean
LastName DOB
B_A_0002 Marie Dupont 6/6/66
Marc
... ... ... ...
...
...
Symptoms name value date B_A_0001
Ernest
Martin 5/5/55
severe 3/3/3 sneezing
itchy_troat severe 3/3/3
B_A_0003 Dulac 7/7/77 ...
Antoine
Figure:Illustration mod `ele NF2
Colonne Id ´ees pr ´ealables
Mod `ele NF2 : SGBD Objet-Relationnel
Exemples de types de donn ´ees 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
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
Pour ´eviter les confusions : Column family plut ˆot que Column oriented
paradigmes : cl ´e/valeur et colonne de mani `ere `a repr ´esenter les multiples cl ´es possibles
Colonne : : triplet : nom de colonne / valeur de colonne / estampille (g ´erer les versions et les conflits)
Famille de colonnes : : regrouper les colonnes qui sont partag ´ees par un ensemble d’individus (∼property tables et mod `ele hybride des triple store)
Super familes de colonnes : : extension du mod `ele avec la notion de super familles qui sont des collections de colonnes (poser des index `a diff ´erents niveaux)
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
IllustrationColumn family
...
...
...
row_key_x
...
...
timestamp_1
...
column_name_n column_value_n column_name_1
column_value_1
timestamp_n
row_key_x => {
column_name_1: column_value_1, ...
column_name_n: column_value_n, }
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
IllustrationColumn family
PatientCode Firstname
1256953732
LastName
1256953732
Marie Martin
PatientCode B_A_0001
1256953732
Firstname Jean 1256953732
LastName Dupont
1256953732
Address Montpellier
1256953732 B_A_0001
B_A_0002 B_A_0002
1256953732
Function Commercial
1256953732 1256953732 OfficeNumber
17−03
Figure:Exemple de deux tuples d’une famille
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
Ecriture inspir ´ee 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, }
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
IllustrationColumn family
PatientCode B_A_0001
1256953732
Firstname Jean
1256953732
LastName Dupont
1256953732
Address Montpellier
1256953732 B_A_0001
CF:Gal_Infos
CF:Allergy_Infos
B_A_0001
Sneezing mild
1256953666 severe
Itchy_Troat
1256953666
Snuffy_Nose moderate
1256953666
Watery_Eyes mild
1256953666
Itchy_Nose
severe
1256953666
Figure:Exemple de deux familles de colonnes
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
IllustrationSuper Column family
...
...
...
column_name_1 column_value_1
timestamp_1
column_name_n column_value_n timestamp_n
column_name_n: column_value_n, column_name_1: column_value_1,...
row_key_x => { row_key_x
...
...
...
Super_Column_Name_n Super_Column_Name_1
Super_Column_Name_1 {
}
Super_Column_Name_1 {
}
column_name_n’: column_value_n’, column_name_1’: column_value_1’,...
column_name_1’ ...
...
...
column_value_1’
column_name_n’
column_value_n’
timestamp_1’ timestamp_n’
Figure:Vision g ´en ´erique
NoSQL et familles de colonnes
Syst `emes NoSQL `a colonnes
Ecriture inspir ´ee 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, }
NoSQL et familles de colonnes
NoSQL : syst `emes
S’inspirent largement de Google BigTable(1)
Cassandra Hbase
(1) BigTable - A distributed storage system for distributed data - Chang et al, 2006
NoSQL et familles de colonnes HBase
HBAse : syst `eme ”column family”
Distribu ´e, privil ´egie la coh ´erence et la disponibilit ´e des donn ´ees sans oublier les performances
S’appuie sur Hadoop (projet open source Apache) qui facilite le traitement distribu ´e de larges jeux de donn ´ees et ses composants
Hadoop Core =
HDFS pour le stockage
MasterServer : namenode (mode master/slave) RegionServer : datanode
Zookeeper : infrastructure centralis ´ee et services pour g ´erer un
”cluster” de serveurs : parmi les activit ´es : synchronization, choix du serveur maˆıtre et v ´erification de la disponibilit ´e des serveurs MapReduce : mod `ele de programmation distribu ´ee
NoSQL et familles de colonnes HBase
Architecture de HBase
Figure:Vision g ´en ´erale
NoSQL et familles de colonnes HBase
Structurellement parlant :
unit ´e de base : table (keyspace) fragment ´ee en parties ´egales = r ´egions (intervalles de valeurs de cl ´es)
tables tri ´ees sur la valeur de la cl ´e
familles : nombre quelconque de colonnes
colonne (qualifier) : dont les valeurs peuvent ˆetre en nombre quelconque de versions (horodatage)
(table, row, column family, column qualifier, timestamp) ->value (la valeur de la donn ´ee est stock ´ee avec l’ensemble de ses coordonn ´ees)
`a noter : pas de super colonne avec HBase
NoSQL et familles de colonnes HBase
Organisation de la donn ´ee
Figure:
Aspects internes
Aspects internes `a l’architecture de Hbase
Structures mises en jeu
1 familles de colonnes (CF) dont les colonnes sont stock ´ees dans les m ˆemes fichiers bas niveau = HFile
2 une table est associ ´ee `a une ou `a plusieurs r ´egions (partition de valeurs) selon les besoins en mati `ere de place
3 HStore : une zone tampon par r ´egion associ ´ee `a une table :
4 MemStore : une m ´emoire assign ´ee au tri des tuples et `a l’ ´ecriture s ´equentielle du flux de donn ´ees dans les fichiers de donn ´ees (HFile) - Sort & Flush
5 CachingBlock : tampon de donn ´ees en m ´emoire vive
6 HFile : 1 `a plusieurs fichiers de donn ´ees par r ´egion
7 HLog : 1 fichier journal par RegionServer
8 Block : unit ´e d’ ´echange entre les m ´emoires vive et de masse (64 Ko `a l’ordinaire)
Aspects internes
Orchestration de diff ´erents composants
HFile 1
stores1 1
LogFile (WAL) RegionServer Region
CachingBlock HStore
Column + name : byte[]
+ value : byte[]
+ time : timestamp Table + name : string
locatedOn 1
*
*
1..*
1
associatedTo
1
1
MemStore ColumnFamily
+ name : byte[]
Figure:Diagramme de classes : structures internes
Aspects internes
Orchestration de diff ´erents composants
Figure:Extrait de HBase internals and schema design presentation
Aspects internes
M ´ecanisme de reprise
Figure:Ecriture dans fichier journal pour restauration ´eventuelle
Aspects internes
Fichiers de donn ´ees
Structure d’index : Log Structured Merge (LSM) Tree optimis ´ee pour les acc `es s ´equentiels
Figure:Ordonnancement des valeurs des colonnes sur la base de la cl ´e du tuple
Aspects internes
Fichiers de donn ´ees
Figure:
Aspects internes
Page d’accueil (WebApp)
Figure:
Aspects internes
Acc `es et traitement des donn ´ees
Acc `es plus imp ´eratif que d ´eclaratif
1 pas de langage DSL `a l’exemple de SQL pour requ ˆeter les donn ´ees
2 acc `es imperatif au travers d’API clientes : Java mais recours possible `a d’autres langages JRuby, Clojure, Scala, Jython, . . .
3 notion de coprocessor pour traiter directement les donn ´ees au niveau d’un noeud de donn ´ees (RegionServer)
4 compl ´ementarit ´e avec le framework MapReduce qui fournit des wrappers pour convertir les tables en collection de paires cl ´e/valeur en entr ´ee comme en sortie de diverses t ˆaches d’analyse
Aspects internes
En pratique
Clients HBase
API Java
Shell HBase (JRuby) Clients non-java
serveurs Thrifts (Ruby, C++, Erlang, . . . ) serveurs Rest (Stargate)
Aspects internes
Construire une table et deux colonnes avec JRuby
create ’ville’, ’iG’, ’ip10’
put ’ville’, ’01024’, ’iG:codeInsee’, ’01024’
put ’ville’, ’01024’, ’iG:nom’, ’Attignat’
put ’ville’, ’01024’, ’iG:popMun’,’2850’
put ’ville’, ’34172’, ’iG:codeInsee’, ’34172’
put ’ville’, ’34172’, ’iG:nom’, ’Montpellier’
put ’ville’, ’34172’, ’iG:popMun’, ’255080’
put ’ville’, ’34172’, ’ip10:nbreRedevables’, ’1913’
--
put ’ville’, ’34172’, ’ip10:nbreRedevables’, ’1914’
delete ’ville’, ’34172’, ’ip10:nbreRedevables’
scan ’ville’
resultats _________
ROW COLUMN+CELL
01024 column=iG:codeInsee, timestamp=1354564480805, value=01024
Aspects internes
Exemples API Java
Op ´erations ´el ´ementaires
1 op ´erations sur une table : create, scan, disable, drop
2 op ´erations sur un tuple : put, delete, get
3 notions de filtre `a partir du parcours des tuples d’une table
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
Aspects internes
Filtre : patients ˆag ´es d’au moins 26 ans
Configuration conf = HBaseConfiguration.create();
HTable table = new HTable(conf, "patient");
List<Filter> filters = new ArrayList<Filter>();
Filter famFilter = new FamilyFilter(CompareFilter.
CompareOp.EQUAL,
new BinaryComparator(Bytes.toBytes("iG")));
filters.add(famFilter);
Filter colFilter = new QualifierFilter(
CompareFilter.CompareOp.EQUAL,
new BinaryComparator(Bytes.toBytes("age")));
filters.add(colFilter);
Filter valFilter = new ValueFilter(CompareFilter.
CompareOp.GREATER_OR_EQUAL,
new BinaryComparator(Bytes.toBytes("26")));
filters.add(valFilter);
Listing 3: Exemple de filtre
Aspects internes
Filtre Suite
FilterList fl = new FilterList( FilterList.Operator.
MUST_PASS_ALL, filters);
Scan scan = new Scan();
scan.setFilter(fl);
ResultScanner scanner = table.getScanner(scan);
System.out.println("Scanning table... ");
for (Result result : scanner) { for (KeyValue kv : result.raw()) { System.out.println("kv:"+kv +", Key: " + Bytes.toString(kv.getRow())
+ ", Value: " +Bytes.toString(kv.getValue()));
} }
scanner.close();
Listing 4: Exemple de filtre