• Aucun résultat trouvé

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

N/A
N/A
Protected

Academic year: 2022

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

Copied!
73
0
0

Texte intégral

(1)

NoSQL - Syst `emes de gestion de donn ´ees distribu ´es

I. Mougenotmougenot@lirmm.fr

Facult ´e des Sciences Universit ´e Montpellier 2



(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

(3)

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

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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)

(9)

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

(10)

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

(11)

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

(12)

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, . . .

(13)

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

(14)

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

(15)

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).

(16)

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))

(17)

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

(18)

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

(19)

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

(20)

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 . . .

(21)

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 . . .

(22)

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 . . .

(23)

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).

(24)

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

(25)

Introduction au NOSQL

Compl ´ementarit ´e des syst `emes NoSQL

Figure:Persistance dite polyglotte (extrait de NoSQL distilled)

(26)

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

(27)

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 AAccepte d’attendre que les donn ´ees soient coh ´erentes

2 abandon du CAccepte de recevoir des donn ´ees parfois incoh ´erentes

(28)

Introduction au NOSQL

Positionnement des syst `emes / CAP

Figure:Synth `ese CAP

(29)

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

(30)

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”

(31)

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

(32)

Introduction au NOSQL

Illustration typologie NoSQL

Figure:

(33)

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

(34)

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

(35)

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

(36)

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

(37)

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

(38)

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

(39)

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

(40)

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

(41)

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)

(42)

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

(43)

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

(44)

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

(45)

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

(46)

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

(47)

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

(48)

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)

(49)

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, }

(50)

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

(51)

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, }

(52)

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

(53)

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

(54)

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, }

(55)

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

(56)

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

(57)

NoSQL et familles de colonnes HBase

Architecture de HBase

Figure:Vision g ´en ´erale

(58)

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

(59)

NoSQL et familles de colonnes HBase

Organisation de la donn ´ee

Figure:

(60)

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)

(61)

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

(62)

Aspects internes

Orchestration de diff ´erents composants

Figure:Extrait de HBase internals and schema design presentation

(63)

Aspects internes

M ´ecanisme de reprise

Figure:Ecriture dans fichier journal pour restauration ´eventuelle

(64)

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

(65)

Aspects internes

Fichiers de donn ´ees

Figure:

(66)

Aspects internes

Page d’accueil (WebApp)

Figure:

(67)

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

(68)

Aspects internes

En pratique

Clients HBase

API Java

Shell HBase (JRuby) Clients non-java

serveurs Thrifts (Ruby, C++, Erlang, . . . ) serveurs Rest (Stargate)

(69)

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

(70)

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

(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

(72)

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

(73)

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

Références

Documents relatifs

Perdre ses photos de vacances : ¸ca n’a pas de

Programme des enseignements – Syst` emes d’information et conception d’entrepˆ ots de donn´ ees – Les principes et la d´ emarche du Data Mining (fouille de donn´ ees)

Une exp´ erience par coloration a montr´ e qu’une rivi` ere souterraine alimente une r´ esurgence dans la vall´ ee. La rivi` ere souterraine a un d´ ebit tr` es sensible aux

Ecrire en Java la gestion d’un tas, repr´esent´e par un tableau : cr´eer, ins´erer, minimum, supprimer (le minimum), modifier une valeur.. Vous programmerez ceci en TP, et

On fixe une cat´ egorie C et on prend comme objets les couples (R, M ) d’une monade R sur C et d’un R-module M. Que peut-on prendre comme morphismes pour faire une cat´

Reformuler et d ´ecomposer une requ ˆete utilisateur sur le sch ´ema global en des requ ˆetes sur le sch ´ema local qui sont ´evalu ´ees sur les sources de donn ´ees. Combiner les

Answering Keyword Queries Building inverted files Spelling correction Clustering. Indexing

Reformuler et d ´ecomposer une requ ˆete utilisateur sur le sch ´ema global en des requ ˆetes sur le sch ´ema local qui sont ´evalu ´ees sur les sources de donn ´ees. Combiner les