SlideShare ist ein Scribd-Unternehmen logo
1 von 60
Downloaden Sie, um offline zu lesen
NOSQL
LES CONCEPTS
Hayssam Saleh
SOMMAIRE
Les modèles
 Le Map / Reduce

POURQUOI LES BASES DE DONNÉES RELATIONNELLES


Gérer le persistance des données
Les données non volatiles sont stockées sur disque
 Un RDBMS permet de récupérer un sous-ensemble de
données de manière beaucoup plus simple et beaucoup plus
rapide qu’un accès disque.


Un simple « SELECT » avec des jointures
 versus
 Plusieurs lectures disques sur plusieurs fichiers suivi d’un filtre.

POURQUOI LES BASES DE DONNÉES RELATIONNELLES


Concurrence d’accès


Accès par plusieurs utilisateurs aux mêmes données peut
conduire à des incohérences si la concurrence d’accès n’est
pas prise en compte


Débit multiple d’un compte par exemple

(1) select amount from table

(1) select amount from table

(2) set amount = amount – 100
(3) update table
(4) set amount = amount -100
(5) update table
POURQUOI LES BASES DE DONNÉES RELATIONNELLES


Concurrence d’accès


Accès par plusieurs utilisateurs aux mêmes données peut
conduire à des incohérences si la concurrence d’accès n’est
pas prise en compte


Débit multiple d’un compte par exemple

(1) lock amount from table
(2) set amount = amount – 100

Bloqué en attente de la libération
du verrou

(3) update table and unlock
(1) lock amount from table
(4) set amount = amount -100
(5) update table and unlock
POURQUOI LES BASES DE DONNÉES RELATIONNELLES


Gestion des erreurs
Dans un système de fichiers classique, une erreur lors de la
séquence de mise à jour rend difficile le retour à une
situation antérieure.
 Les transactions dans les bases relationnelles permettent un
retour arrière transparent




Atomicité des transactions
POURQUOI LES BASES DE DONNÉES RELATIONNELLES


Modèle d’intégration


Les données mises à jour en base sont instantanément
disponibles à l’ensemble des applications qui y accèdent.



Le langage d’interrogation est indépendant du langage de
programmation et est (quasiment) identique quelque soit la
base de données relationnelle utilisée.
Application 1
PHP

Application 2
Java

Application …
Ruby

SQL
SQL

SQL
LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL


Impédance mismatch
Le modèle relationnel est éloigné du modèle mémoire
 Les solutions de mapping O/R ont montré leurs limites en
terme de performance.


Product Page
Product
description

Price
Products

Brands

Brand
Category

Pics

Tag1
Tag2
tag3

Tags

Categories
LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL


Une approche SOA des Systèmes d’information
La base de données n’est plus le point d’intégration
 L’intégration est agnostique vis à vis du langage
 Les applications deviennent multi-protocolaires


Application 1
PHP
Peu importe

SOAP/XML Application 2
Java
Peu importe

JSON

Application …
Ruby
Peu importe
LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL
L’explosion de la volumétrie des données
 Avec les RDBMS Le modèle big server


Coûteux
 La base et le serveur restent un Single Point Of Failure (SPOF)




Avec le RAC Oracle, le système de fichiers reste un SPOF

VERY BIG SERVER

SERVER1

SERVER2

SERVER…
NOSQL : LES ORIGINES


Le terme


Apparaît pour la première fois dans le nom d’une base de données
créée par Carlo Strozzi en 1998




En 2009 Johan Oskarsson cherche sur twitter un hashtag pour un
meetup sur les alternatives au bases SQL tel que Google BigTable et
Amazon Dynamo






C’est une base de données
 Qui stocke les données dans des fichiers texte, les colonnes étant tabulées.
 que l’on interroge avec des shell script UNIX

Eric Evans un développeur de Rackspace suggère le terme NoSQL
Le terme se répand sur la toile comme une trainée de poudre
A ce meetup sont présents
 Voldemort, Cassandra, Dynomite, Hbase, Hypertable, CouchDB et MongoDB

La signification



Pas de définition précise
Regroupe toutes les bases de données qui n’utilisent pas SQL comme moyen
d’accès.
POURQUOI LE NOSQL


Synthèse









Les RDBMS gèrent la persistance, la concurrence.
Les RDBMS permettent une intégration des éléments du S.I.
par le partage des données accessible au travers d’un
langage universel
L’impédance mismatch entre le modèle relationnel et le
modèle objet d’où les solutions de mapping objet/relationnel
et les problèmes de performance qui en découlent
Le nombre croissant et non quantifiable d’utilisateurs
conduit à une explosion de la volumétrie
Les RDBMS en sont pas prévus pour fonctionner en cluster

NoSQL


Qu’est ce que c’est ?
LE MODÈLE RELATIONNEL


Entité/Relation
Le modèle de données est constitué d’un ensemble de tables
 Chaque ligne d’une table est composée de colonnes
 Une colonne héberge une et une seule valeur
 Les relations sont permises par le fait qu’une colonne peut
référencer une ligne de la même table ou d’une autre table


Brands

Products
Categories
LES MODÈLES DE DONNÉES NOSQL


Modèle NoSQL


Clef / Valeur, Document , Famille de colonnes
Les données sont agrégées
 L’agrégation obéit en général au modèle de consultation
 Toutes les entités censées être restituées ensemble sont agrégées
au sein d’une même structure


Autant de tables que d’entités

Une seule et unique entité
LES MODÈLES DE DONNÉES NOSQL


Conséquence du modèle d’agrégat


Dans le modèle relationnel il est impossible de distinguer les
relations d’agrégation des relations de liaison.



Les RDBMS ne peuvent donc pas utiliser cette information
pour optimiser le modèle de stockage ou distribuer les
données sur plusieurs serveurs.
LES MODÈLES DE DONNÉES NOSQL


Quand utiliser le modèle d’agrégat


Lorsque la volumétrie le justifie. Les données doivent être
réparties sur plusieurs serveurs (sur un cluster)




L’agrégation indique au DBMS l’unité de consultation. Les
constituants d’un agrégat seront ainsi toujours stockés sur le même
nœud.

L’atomicité d’une mise à jour sera garantie pour un agrégat
mais pas pour un ensemble d’agrégats mis à jour
simultanément dans la même transaction.


Quand l’atomicité est nécessaire, il faut alors fusionner les agrégats
en un seul et unique agrégat.
LES MODÈLES DE DONNÉES NOSQL


Le modèle Clef / Valeur
Interface de type Map.
 La valeur est opaque au DBMS. Il la considère comme un
Blob


Key = « product1 »

Value est un Blob/CLob

Key = « product2 »

Value est un Blob/CLob

Key = « product… »

Value est un Blob/CLob
LES MODÈLES DE DONNÉES NOSQL


Le modèle Orienté Document
La structure de l’agrégat est visible du DBMS
 Les requêtes peuvent référencer des propriétés de l’agrégat
 Et renvoyer un sous-ensemble de l’agrégat


Key = "product1"

{
product : {
title: "product1",

Requête sur un critère du document
et extraction d’un sous ensemble

category:"computer",

tags :["tag1", "tag2", "tag2"]
…
}
}

Key = "product2"

{
product : {
…
LES MODÈLES DE DONNÉES NOSQL


Les modèles Orienté Document et Clef / valeur :


Une frontière floue
 Certains

moteurs clef/valeur permettent de rajouter des
métadonnées qui peuvent être ensuite indexées et utilisées en tant
que critères

 Lorsque

la valeur est au format JSON et XML, certains moteurs
permettent d’utiliser Apache SOLR pour de la recherche full-text sur
l’agrégat

Key = « product1 »
Prop1: …
Prop2: …
Prop3: …

Value à a Blob/CLob
LES MODÈLES DE DONNÉES NOSQL


Le modèle famille de colonnes:

Column
Column
name
Column
Value

Title
Product1
LES MODÈLES DE DONNÉES NOSQL


Le modèle famille de colonnes:
Super column name
Column
name
Column
Value

…

Column
name
Column
Value

ProductInfo
Title

Description

Product1

Beautiful product you’ll
find nowhere else 
LES MODÈLES DE DONNÉES NOSQL


Le modèle famille de colonnes:
Famille de colonnes

Row key

Column
name

Column
name

…

Column
Value

Column
Value

…
Title
"1234-3213-2134-2121"

…

Description

…

Beautiful product
you’ll find nowhere
else 

Product1
LES MODÈLES DE DONNÉES NOSQL
Famille de colonnes et super colonnes
Super column name
Column
name

Row key

…

Column
Value

Super column name

Column
name

…

Column
Value

Column
name

…

Column
Value

Column
name
Column
Value

…
ProductInfo
"1234…2121"

SellerInfo

Title

…

Description

Name

…

Location

Product1

…

l

ToyStore

…

Paris

Keyspace.get("products », »1234…2121", "ProductInfo », "Title »)
LES MODÈLES DE DONNÉES NOSQL


Le modèle famille de colonnes:
 S’il

fallait comparer aux RDBMS

Modèle relationnel
Schéma

Keyspace

Table

Famille de colonnes

Clef primaire

Idem

Nom de colonne

Idem

Valeur de colonne

 Il

Modèle famille de colonnes
(terminologie Cassandra)

Idem

vaut mieux considérer une famille de colonnes comme suit :



SortedMap[RowKey, SortedMap[ColumnKey, ColumnValue]]
LES MODÈLES DE DONNÉES NOSQL


Synthèse


Dans les modèles Clef/Valeur, Orientés documents et famille de colonnes:


L’agrégat est l’unité de données



Les opérations sur un agrégat respectent le principe ACID



L’agrégat permet au DBMS de gérer d’organiser le stockage des données
sur les noeuds du cluster



Lorsque les opérations sont groupées par agrégat, les modèles NoSQL
sont justifiés.



Lorsque un nombre de relations limité doit être établi entre plusieurs
agrégats les modèles relationnels nous permettent de conserver les
propriétés ACID.



Mais alors comment gérer un nombre important de relations entre les
objets


Les modèles relationnels font exploser les jointures



C’est là qu’intervient le modèle NoSQL communément appelé Base de données
orientée Graphe
LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE



Hayssam et Michèle ont des gouts similaires ?


Je peux proposer à Michèle tous les produits
 Les produits dans l’ordre suivant :


Les produits achetés, "aimés" ou consultés par Hayssam
LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE
 Synthèse
 Permet

la gestion des relations entre agrégats

 Organise


les données en nœuds et liens

Ce modèle est intéressant en présence d’un volume important de liens

 Inadapté

à la navigation en cluster
LES MODÈLES DE RÉPARTITION
Le modèle centralisé
 Le sharding
 Maitre / esclave
 Réplication point à point

LES MODÈLES DE RÉPARTITION


Le modèle centralisé
Probablement le modèle le plus courant
 Adapté à la grande majorité des cas
 N’est pas en contradiction avec le modèle NoSQL

LES MODÈLES DE RÉPARTITION


Le sharding
Résoudre le problème d’une trop forte charge sur les
serveurs pour l’accès à des données disjointes.
 Cible => Situation idéale (inatteignable dans la réalité)


Les utilisateurs sont uniformément répartis sur les serveurs
 Ils accèdent à des données elles-aussi uniformément réparties


Big Server
Row 1
…
Row1000000

Row 1

Row 1000001
…
Row2000000

…
Row3000000
Row 2000001
…
Row3000000
LES MODÈLES DE RÉPARTITION


Les intérêts du sharding
Meilleures performances en consultation et mises à jour
 Réduction de la volumétrie des index




Les difficultés du sharding


Non transparent


L’application doit savoir quel serveur contient quelle donnée

Jointures non autorisées entre les shards
 Perte de l’intégrité référentielle inter-shards.




Autosharding
Le DBMS est responsable de la répartition des données sur les
serveurs
 Service présent sur la majeure partie des DBMS NoSQL

LES MODÈLES DE RÉPARTITION


Maître / Esclave
Propagation

Mise à jour

Maitre

Esclave

Consultation

Propagation
Esclave






Consultation

Consultation

Les lectures se font sur n’importe quel nœud du cluster
Toutes les écritures sont effectuées sur le maître qui est chargé de
les répercuter sur les esclaves
Certaines lectures peuvent être incorrectes si l’écriture n’a pas
encore été répercutée
Inadapté à un trop important volume de données à écrire
Le maitre est un SPOF
LES MODÈLES DE RÉPARTITION


Réplication point à point
Maître

Maître

Lecture / écriture

Maitre

Lecture/écriture

Lecture/écriture

Propagation
Des écritures

Les lectures / écritures se font sur n’importe quel nœud du
cluster
 Inconsistance en cas d’écritures simultanées sur un même
sous ensemble de données à partir de différents maîtres
 Merge des écritures possible malgré tout.

LES MODÈLES DE RÉPARTITION


Synthèse
Le sharding permet de répartir les données sur plusieurs
serveurs, chaque serveur étant responsable d’un sousensemble des données
 La réplication duplique les données sur plusieurs serveurs


Le modèle maitre/esclave consiste à avoir un serveur chargé de
propager les écritures
 Le maître reste un SPOF
 Le modèle point à point permet d’écrire sur n’importe quel nœud
du cluster. Les nœuds se coordonnent ensuite pour synchroniser les
copies
 Peut provoquer des conflits lors des mises à jour de données

LA COHÉRENCE DES DONNÉES
Le modèle ACID
 Le théorème CAP
 Les quorums
 Le versioning

LA COHÉRENCE DES DONNÉES


Le modèle ACID


Atomicité




Tout ou rien

Cohérence


Les transactions qui modifient l’état de la base font en sorte que les
contraintes d’intégrité référentielle sont respectées
 Est-ce bien de la cohérence ? Non




Isolation




Conflit en lecture et en écriture toujours possible

Une transaction ne peut pas accéder aux données mise à jour par
une autre transaction avant qu’elle ne soit validée par son
propriétaire

Durabilité


Toute transaction validée (commitée) est assurée d’être prise en
compte quelque soit la panne (transaction logs).
LA COHÉRENCE DES DONNÉES


Les conflits en écriture

1- Hayssam récupère le montant
De la base soit 100€
3- Hayssam rajoute 20 €
4- Hayssam met à jour la donnée en base

2- Michèle récupère le montant
de la base soit 100€
3- Michèle rajoute 10 €
5- Michèle met à jour la base

Nouvelle valeur = 110 € 


Solution : Verrou optimiste


L’enregistrement est verrouillé avant la lecture


Risque de provoquer un inter-blocage si Hayssam attend Michèle
sur cette ressource et que Michèle attend Hayssam sur une autre
ressource
LE THÉORÈME CAP


Cohérence (Consistency)




Disponibilité (Availablity)




Garantie que les requêtes reçoivent une réponse même si un
ou plusieurs nœuds sont défaillants

Résistance au morcellement (Partition Tolerance)




Tous les nœuds du système voient exactement les mêmes
données au même moment

Aucune panne autre qu’une coupure réseau totale ne doit
empêcher le système de répondre. Idéalement, le système
doit être en mesure de réconcilier les mises à jour une fois
les nœuds à nouveaux accessibles les uns des autres

Théorème de Brewer:


Un système distribué ne peut garantir à un instant donné que
2 de ces 3 contraintes.
LE THÉORÈME CAP


Situation idéale
N
1

N
1

A

V1

N
1

A

V0

A

V1

V1

U
N
2

N
2

B
1

N
2

B

V0

2

B

V0

3

V1

V1
LE THÉORÈME CAP


CAP

Application
LE THÉORÈME CAP
CAP : Une panne du maître provoque une indisponibilité
Maître

Esclave

Esclave

Lectures
Client

Client

Mises à jour

Mises à jour


LE THÉORÈME CAP
CAP = Résistance au morcellement => la valeur lue par B est
incohérente



N
1

N
1

A

V1

N
1

A

V0

A

V1

V1

U
N
2

N
2

B
1

N
2

B

V0

2

B

V0

3

V0

V0
CONSISTENT HASHING



Chaque partition est gérée par un
et un seul vnoeud



Les vnoeud sont répartis sur les
noeuds physiques



L’ajout ou le retrait d’un nœud
physique amène le système à se
reconfigurer en déplaçant des
vnoeuds pour conserver une
répartition uniforme des
partitions.



Nombre minimum de partitions
doit être de 10.

3 nœuds et 64 partitions
–

•

La partitionnement est réalisé une
fois pour toutes et devient
DEFINITIF.



•

Une clef est sur 160 bits

22 partitions sur un nœud et 21 sur les deux autres.

On ajoute 1 nœud supplémentaire
–

Le système se reconfigure pour avoir 16 partitions par noeud.
LES QUORUMS


Qorum


Le nombre minimum de nœuds qui doivent répondre avec succès pour
considérer que l’opération s’est déroulée avec succès




N










Les R premiers nœuds qui renvoient la valeur demandée
R<N

W




Nombre de nœuds sur lesquels les données doivent être répliquées.

R




Permet de réconcilier la cohérence et la disponibilité.

Nombre de nœuds qui doivent répondre avec succès pour considérer que la
création/mise à jour a été effectuée avec succès
W<N

Les performances sont directement liées à l’importance des valeurs R &
W.

Cohérence et disponibilité



Tolérer un nœud défaillant : N = 3, R = W = 2
Tolérer deux nœuds défaillants : N = 5, R = W = 3
LE QUORUM DE LECTURE
LE QUORUM D’ÉCRITURE
DÉTECTION ET RÉSOLUTION DES CONFLITS
VECTOR CLOCKS
Chaque donnée est accompagnée d’un identifiant de
nœud et d’un timestamp
 Quand deux clients mettent à jour la même donnée, on
obtient une donnée avec deux vector clocks distincts.
 La résolution est alors à l’initiative du client.

DÉTECTION

DU CONFLIT

Réplication

Mise à jour
Mise à jour
Réplication

Conflit détecté
RÉSOLUTION ET QUORUM
Value = Data.v2

Client
GET (K, Q=2)
Value = Data.v2

Update K = Data.v2

Value = Data.v1
LA COHÉRENCE DES DONNÉES


Synthèse








Les conflits en écriture surviennent lorsque 2 clients mettent
à jour la même donnée au même moment
La prévention des conflits par une stratégie pessimiste peut
provoquer des inter-blocages
La prévention des conflits conduit à des algorithmes
bloquants qui provoquent un ralentissement des applications
Le théorème CAP indique qu’il faut choisir entre la
disponibilité et la cohérence
La cohérence ne requiert de consulter tous les noeuds du
cluster, il suffit que le quorum soit rempli
Les estampilles permettent de détecter les conflits
Le vecteur d’estampilles indiquent quand les différents
nœuds ont eu des mises à jour en conflit.
Source: http://blog.beany.co.kr/archives/275

http://blog.beany.co.kr/archives/275

LE THÉORÈME CAP : POSITIONNEMENT DES BASES NOSQL
CAS D’USAGE


Clef / Valeur


Cas d’usage








Stockage des informations de session
 Memcached ou Riak
Profil utilisateur ou Préférences
Memcached si préférences non persistantes, Riak sinon
Gestion de panier
 Riak

Cas à éviter






Relations entre les agrégats
 Bien que certaines bases comme Riak permettent naviguer d’un agrégat à un
autre
Transactions multi-agrégats
 Rend complexe le rollback
Inerrogation sur la valeur de l’agrégat
 La valeur n’est pas accessible




Même si Riak par exemple offre un mode recherche en texte intégral avec SOLR

Opérations ensemblistes
 Il n’est pas possible d’accéder à plusieurs clefs simultanément


Plusieurs aller/retour sont nécessaires entre le client et le DBMS
CAS D’USAGE


Orienté Document


Cas d’usage






Logging d’événements
 Les données pourront être shardées par application ou type
d’événements (commande / Paiement / ect …)
CMS / Blog
 Publication de sites Web, Gestion des commentaires …
Real time Web Analytics
 Les agrégats peuvent être mis à jour







Nombre de pages vues, nombre de visiteurs
Les agrégats étant sans schéma, de nouvelles métriques peuventêtre
ajoutées à tout moment

Applications e-commerce
 Supporter n’importe quel type de produit avec n’importe quelle
propriété.

Cas à éviter


Transactions multi-document
CAS D’USAGE


Orienté colonnes


Cas d’usage
Logging d’événements
 CMS, Plateforme de Blog
 Compteurs
 Famille de colonne CounterColumnType
 Propriétés avec une date d’expiration
 Bannières publicitaires
 Accès en démo




Cas à éviter


Inadapté pour un prototype
 Requiert de concevoir les familles de colonnes en amont de
l’utilisation
CAS D’USAGE


Graphes


Cas d’usage
Réseaux sociaux
 Services de géolocalisation, routage ou dispatching
 Moteurs de recommandation




Cas à éviter
Volume de données trop important pour résider sur un seul serveur
 Mise à jour de propriétés sur un nombre important de noeuds

L’ANALYSE DE DONNÉES


Map / Reduce : Principe fonctionnel


La phase de mapping lit les données de la base et génère une map de clef/valeur




Parallélisation : Chaque couple sera traité par un acteur

Ne fonction de réduction les entrées avec la même clef pour les agréger en une
seule valeur

Map

Combine

Map

Job'
request

Map

Map

Map

Reduce
MAPREDUCE


Exemple : Calculer le nombre de pages dans la catégorie AUTO accédées
entre le 1er janvier et le 7 janvier

{ "categories" : [ “Assurance”,” Auto”, “Promotion” ],
"interaction" : { "age" : -1,
"domain" : null,
"name" : "INTERACTION_ID",
"path" : null,
"value" : "4b40fb8b-55eb-4319-9745-fccfe2be8f88"
},
"keywords" : [ “ABC” ],
"nodePath" : "/sites/ACME-SPACE/home/community/publications",
"requestData" : { "accept" : "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"accept-charset" : "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"accept-encoding" : "gzip,deflate,sdch",
"accept-language" : "en-US,en;q=0.8,fr;q=0.6",
"connection" : "keep-alive",
"cookie" : "JSESSIONID=62b7421a-8e85-42aa-a0fd-816c34456502; INTERACTION_ID=4b40fb8b-55eb-4319-9745-fccfe2be8f88",
"host" : "127.0.0.1:8080",
"ipAddress" : "127.0.0.1",
"referer" : "http://127.0.0.1:8080/cms/en/sites/ACME-SPACE/home/activities/satellites.html",
"user-agent" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11"
},
"sessionId" : "62b7421a-8e85-42aa-a0fd-816c34456502",
"tags" : [ “Avantages” ],
"time" : 1353415058212,
"userid" : " guest "
}
MAP / REDUCE : UN EXEMPLE CONCRET


Phase de Mapping : Un objet est à retenir s’il référence la catégorie Auto
var doTheMap = function(value) {
try {
var obj = Riak.mapValuesJson(value)[0];
if (obj.categories.indexOf("Auto") > -1 &&
new Date(2012,0,1).getTime() >= obj.time &&
new Date(2012,0,7).getTime() <= obj.time )
return [obj];
else
return [];
}
catch (error) {
return [];
}
}



Phase de Reduce : Compter le nombre de pages
var reduceIt = function(values) {
return [values.reduce(function(total, value) { return total + 1;}, 0)];
}



Lancer le Map/Reduce sur le bucket des visites
riak.add("visites").map(doTheMap).reduce(reduceIt).run()




Plusieurs phases de maps et de reduce peuvent être appliquées successivement
riak.add("visites").map(doTheMap1).map(doTheMap2). reduce(reduceIt1). reduce(reduceIt2).run()
L’ANALYSE DE DONNÉES


Synthèse
Map-reduce est un pattern de parallélisation des calculs sur
un cluster
 La Phase de mapping lit les données d’un agrégat et
implemnte la condition qui consiste à retenir la donnée
 La phase de réduction prend la liste des valeurs d’une clef et
la réduit à une valeur unique

Questions

Weitere ähnliche Inhalte

Was ist angesagt?

BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQLLilia Sfaxi
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherLilia Sfaxi
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdfZkSadrati
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataLilia Sfaxi
 
Présentation des bases de données NoSql
Présentation des bases de données NoSqlPrésentation des bases de données NoSql
Présentation des bases de données NoSqlSidi LEKHALIFA
 
Quand utiliser MongoDB … Et quand vous en passer…
Quand utiliser MongoDB	… Et quand vous en passer…Quand utiliser MongoDB	… Et quand vous en passer…
Quand utiliser MongoDB … Et quand vous en passer…MongoDB
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceLilia Sfaxi
 
Introduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudouxIntroduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudouxLaurent Broudoux
 
Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuéekamar MEDDAH
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQLAntoine Augusti
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDBMongoDB
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : SparkLilia Sfaxi
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkAmal Abid
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQLSamy Dindane
 
Spark (v1.3) - Présentation (Français)
Spark (v1.3) - Présentation (Français)Spark (v1.3) - Présentation (Français)
Spark (v1.3) - Présentation (Français)Alexis Seigneurin
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingLilia Sfaxi
 

Was ist angesagt? (20)

BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big Data
 
Présentation des bases de données NoSql
Présentation des bases de données NoSqlPrésentation des bases de données NoSql
Présentation des bases de données NoSql
 
Quand utiliser MongoDB … Et quand vous en passer…
Quand utiliser MongoDB	… Et quand vous en passer…Quand utiliser MongoDB	… Et quand vous en passer…
Quand utiliser MongoDB … Et quand vous en passer…
 
BigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-ReduceBigData_Chp2: Hadoop & Map-Reduce
BigData_Chp2: Hadoop & Map-Reduce
 
introduction à MongoDB
introduction à MongoDBintroduction à MongoDB
introduction à MongoDB
 
Introduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudouxIntroduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudoux
 
Presentation cassandra
Presentation cassandraPresentation cassandra
Presentation cassandra
 
Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuée
 
NoSQL MeetUp
NoSQL MeetUpNoSQL MeetUp
NoSQL MeetUp
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Td dw1
Td dw1Td dw1
Td dw1
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDB
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : Spark
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - Spark
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
Spark (v1.3) - Présentation (Français)
Spark (v1.3) - Présentation (Français)Spark (v1.3) - Présentation (Français)
Spark (v1.3) - Présentation (Français)
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 

Andere mochten auch

Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)gdusbabek
 
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureBig Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureMicrosoft
 
Techday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataTechday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataArrow Group
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop QuébecMathieu Dumoulin
 
Architectures techniques NoSQL
Architectures techniques NoSQLArchitectures techniques NoSQL
Architectures techniques NoSQLOCTO Technology
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Hatim CHAHDI
 
Hadoop et son écosystème
Hadoop et son écosystèmeHadoop et son écosystème
Hadoop et son écosystèmeKhanh Maudoux
 

Andere mochten auch (12)

Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)
 
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureBig Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
 
NoSQL et Big Data
NoSQL et Big DataNoSQL et Big Data
NoSQL et Big Data
 
NoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradasNoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradas
 
Techday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataTechday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big Data
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop Québec
 
NoSQL databases
NoSQL databasesNoSQL databases
NoSQL databases
 
Architectures techniques NoSQL
Architectures techniques NoSQLArchitectures techniques NoSQL
Architectures techniques NoSQL
 
Une introduction à HBase
Une introduction à HBaseUne introduction à HBase
Une introduction à HBase
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
 
Introduction à Hadoop
Introduction à HadoopIntroduction à Hadoop
Introduction à Hadoop
 
Hadoop et son écosystème
Hadoop et son écosystèmeHadoop et son écosystème
Hadoop et son écosystème
 

Ähnlich wie Les modèles NoSQL

Base de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreBase de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreMICHRAFY MUSTAFA
 
Serveur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementServeur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementLudovic REUS
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdfhbadir
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de donnéeszied kallel
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTCHAKER ALLAOUI
 
11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .net11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .netHamza SAID
 
Architectures réparties en environnement web
Architectures réparties en environnement webArchitectures réparties en environnement web
Architectures réparties en environnement webAmaury Bouchard
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBRomain Cambien
 
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - IntroductionBlandine Larbret
 
Apache cassandra introduction
Apache cassandra introductionApache cassandra introduction
Apache cassandra introductionzied kallel
 
xml_bd_ouahdikrid.ppt
xml_bd_ouahdikrid.pptxml_bd_ouahdikrid.ppt
xml_bd_ouahdikrid.pptLeilaAmrane
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamTelecomValley
 
java BDD jdbc
java BDD jdbcjava BDD jdbc
java BDD jdbcvangogue
 
Play SQL at PostgreSQL Lyon User Group
Play SQL at PostgreSQL Lyon User GroupPlay SQL at PostgreSQL Lyon User Group
Play SQL at PostgreSQL Lyon User Grouparagot1
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICLa FeWeb
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs Microsoft
 
Bd relationnelles
Bd relationnellesBd relationnelles
Bd relationnellesmakram05
 

Ähnlich wie Les modèles NoSQL (20)

Base de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreBase de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvre
 
Serveur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementServeur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développement
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdf
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de données
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
 
Adopte une BDD
Adopte une BDDAdopte une BDD
Adopte une BDD
 
11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .net11 visual basic .net - acces aux donnees avec ado .net
11 visual basic .net - acces aux donnees avec ado .net
 
Architectures réparties en environnement web
Architectures réparties en environnement webArchitectures réparties en environnement web
Architectures réparties en environnement web
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
 
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
Apache cassandra introduction
Apache cassandra introductionApache cassandra introduction
Apache cassandra introduction
 
xml_bd_ouahdikrid.ppt
xml_bd_ouahdikrid.pptxml_bd_ouahdikrid.ppt
xml_bd_ouahdikrid.ppt
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
 
BDRO.pdf
BDRO.pdfBDRO.pdf
BDRO.pdf
 
java BDD jdbc
java BDD jdbcjava BDD jdbc
java BDD jdbc
 
Play SQL at PostgreSQL Lyon User Group
Play SQL at PostgreSQL Lyon User GroupPlay SQL at PostgreSQL Lyon User Group
Play SQL at PostgreSQL Lyon User Group
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs
 
Bd relationnelles
Bd relationnellesBd relationnelles
Bd relationnelles
 

Mehr von ebiznext

Spark / Mesos Cluster Optimization
Spark / Mesos Cluster OptimizationSpark / Mesos Cluster Optimization
Spark / Mesos Cluster Optimizationebiznext
 
Machine learning
Machine learningMachine learning
Machine learningebiznext
 
EBIZNEXT-RIAK
EBIZNEXT-RIAKEBIZNEXT-RIAK
EBIZNEXT-RIAKebiznext
 
Elasticsearch performance tuning
Elasticsearch performance tuningElasticsearch performance tuning
Elasticsearch performance tuningebiznext
 
Machine Learning - Spark / MLlib
Machine Learning - Spark / MLlibMachine Learning - Spark / MLlib
Machine Learning - Spark / MLlibebiznext
 
Realtime Web avec Kafka, Spark et Mesos
Realtime Web avec Kafka, Spark et MesosRealtime Web avec Kafka, Spark et Mesos
Realtime Web avec Kafka, Spark et Mesosebiznext
 
Scala io2013 : Our journey from UML/MDD to Scala macros
Scala io2013 : Our journey from UML/MDD to Scala macrosScala io2013 : Our journey from UML/MDD to Scala macros
Scala io2013 : Our journey from UML/MDD to Scala macrosebiznext
 

Mehr von ebiznext (7)

Spark / Mesos Cluster Optimization
Spark / Mesos Cluster OptimizationSpark / Mesos Cluster Optimization
Spark / Mesos Cluster Optimization
 
Machine learning
Machine learningMachine learning
Machine learning
 
EBIZNEXT-RIAK
EBIZNEXT-RIAKEBIZNEXT-RIAK
EBIZNEXT-RIAK
 
Elasticsearch performance tuning
Elasticsearch performance tuningElasticsearch performance tuning
Elasticsearch performance tuning
 
Machine Learning - Spark / MLlib
Machine Learning - Spark / MLlibMachine Learning - Spark / MLlib
Machine Learning - Spark / MLlib
 
Realtime Web avec Kafka, Spark et Mesos
Realtime Web avec Kafka, Spark et MesosRealtime Web avec Kafka, Spark et Mesos
Realtime Web avec Kafka, Spark et Mesos
 
Scala io2013 : Our journey from UML/MDD to Scala macros
Scala io2013 : Our journey from UML/MDD to Scala macrosScala io2013 : Our journey from UML/MDD to Scala macros
Scala io2013 : Our journey from UML/MDD to Scala macros
 

Les modèles NoSQL

  • 2. SOMMAIRE Les modèles  Le Map / Reduce 
  • 3. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Gérer le persistance des données Les données non volatiles sont stockées sur disque  Un RDBMS permet de récupérer un sous-ensemble de données de manière beaucoup plus simple et beaucoup plus rapide qu’un accès disque.  Un simple « SELECT » avec des jointures  versus  Plusieurs lectures disques sur plusieurs fichiers suivi d’un filtre. 
  • 4. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Concurrence d’accès  Accès par plusieurs utilisateurs aux mêmes données peut conduire à des incohérences si la concurrence d’accès n’est pas prise en compte  Débit multiple d’un compte par exemple (1) select amount from table (1) select amount from table (2) set amount = amount – 100 (3) update table (4) set amount = amount -100 (5) update table
  • 5. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Concurrence d’accès  Accès par plusieurs utilisateurs aux mêmes données peut conduire à des incohérences si la concurrence d’accès n’est pas prise en compte  Débit multiple d’un compte par exemple (1) lock amount from table (2) set amount = amount – 100 Bloqué en attente de la libération du verrou (3) update table and unlock (1) lock amount from table (4) set amount = amount -100 (5) update table and unlock
  • 6. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Gestion des erreurs Dans un système de fichiers classique, une erreur lors de la séquence de mise à jour rend difficile le retour à une situation antérieure.  Les transactions dans les bases relationnelles permettent un retour arrière transparent   Atomicité des transactions
  • 7. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Modèle d’intégration  Les données mises à jour en base sont instantanément disponibles à l’ensemble des applications qui y accèdent.  Le langage d’interrogation est indépendant du langage de programmation et est (quasiment) identique quelque soit la base de données relationnelle utilisée. Application 1 PHP Application 2 Java Application … Ruby SQL SQL SQL
  • 8. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL  Impédance mismatch Le modèle relationnel est éloigné du modèle mémoire  Les solutions de mapping O/R ont montré leurs limites en terme de performance.  Product Page Product description Price Products Brands Brand Category Pics Tag1 Tag2 tag3 Tags Categories
  • 9. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL  Une approche SOA des Systèmes d’information La base de données n’est plus le point d’intégration  L’intégration est agnostique vis à vis du langage  Les applications deviennent multi-protocolaires  Application 1 PHP Peu importe SOAP/XML Application 2 Java Peu importe JSON Application … Ruby Peu importe
  • 10. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL L’explosion de la volumétrie des données  Avec les RDBMS Le modèle big server  Coûteux  La base et le serveur restent un Single Point Of Failure (SPOF)   Avec le RAC Oracle, le système de fichiers reste un SPOF VERY BIG SERVER SERVER1 SERVER2 SERVER…
  • 11. NOSQL : LES ORIGINES  Le terme  Apparaît pour la première fois dans le nom d’une base de données créée par Carlo Strozzi en 1998   En 2009 Johan Oskarsson cherche sur twitter un hashtag pour un meetup sur les alternatives au bases SQL tel que Google BigTable et Amazon Dynamo     C’est une base de données  Qui stocke les données dans des fichiers texte, les colonnes étant tabulées.  que l’on interroge avec des shell script UNIX Eric Evans un développeur de Rackspace suggère le terme NoSQL Le terme se répand sur la toile comme une trainée de poudre A ce meetup sont présents  Voldemort, Cassandra, Dynomite, Hbase, Hypertable, CouchDB et MongoDB La signification   Pas de définition précise Regroupe toutes les bases de données qui n’utilisent pas SQL comme moyen d’accès.
  • 12. POURQUOI LE NOSQL  Synthèse       Les RDBMS gèrent la persistance, la concurrence. Les RDBMS permettent une intégration des éléments du S.I. par le partage des données accessible au travers d’un langage universel L’impédance mismatch entre le modèle relationnel et le modèle objet d’où les solutions de mapping objet/relationnel et les problèmes de performance qui en découlent Le nombre croissant et non quantifiable d’utilisateurs conduit à une explosion de la volumétrie Les RDBMS en sont pas prévus pour fonctionner en cluster NoSQL  Qu’est ce que c’est ?
  • 13. LE MODÈLE RELATIONNEL  Entité/Relation Le modèle de données est constitué d’un ensemble de tables  Chaque ligne d’une table est composée de colonnes  Une colonne héberge une et une seule valeur  Les relations sont permises par le fait qu’une colonne peut référencer une ligne de la même table ou d’une autre table  Brands Products Categories
  • 14. LES MODÈLES DE DONNÉES NOSQL  Modèle NoSQL  Clef / Valeur, Document , Famille de colonnes Les données sont agrégées  L’agrégation obéit en général au modèle de consultation  Toutes les entités censées être restituées ensemble sont agrégées au sein d’une même structure  Autant de tables que d’entités Une seule et unique entité
  • 15. LES MODÈLES DE DONNÉES NOSQL  Conséquence du modèle d’agrégat  Dans le modèle relationnel il est impossible de distinguer les relations d’agrégation des relations de liaison.  Les RDBMS ne peuvent donc pas utiliser cette information pour optimiser le modèle de stockage ou distribuer les données sur plusieurs serveurs.
  • 16. LES MODÈLES DE DONNÉES NOSQL  Quand utiliser le modèle d’agrégat  Lorsque la volumétrie le justifie. Les données doivent être réparties sur plusieurs serveurs (sur un cluster)   L’agrégation indique au DBMS l’unité de consultation. Les constituants d’un agrégat seront ainsi toujours stockés sur le même nœud. L’atomicité d’une mise à jour sera garantie pour un agrégat mais pas pour un ensemble d’agrégats mis à jour simultanément dans la même transaction.  Quand l’atomicité est nécessaire, il faut alors fusionner les agrégats en un seul et unique agrégat.
  • 17. LES MODÈLES DE DONNÉES NOSQL  Le modèle Clef / Valeur Interface de type Map.  La valeur est opaque au DBMS. Il la considère comme un Blob  Key = « product1 » Value est un Blob/CLob Key = « product2 » Value est un Blob/CLob Key = « product… » Value est un Blob/CLob
  • 18. LES MODÈLES DE DONNÉES NOSQL  Le modèle Orienté Document La structure de l’agrégat est visible du DBMS  Les requêtes peuvent référencer des propriétés de l’agrégat  Et renvoyer un sous-ensemble de l’agrégat  Key = "product1" { product : { title: "product1", Requête sur un critère du document et extraction d’un sous ensemble category:"computer", tags :["tag1", "tag2", "tag2"] … } } Key = "product2" { product : { …
  • 19. LES MODÈLES DE DONNÉES NOSQL  Les modèles Orienté Document et Clef / valeur :  Une frontière floue  Certains moteurs clef/valeur permettent de rajouter des métadonnées qui peuvent être ensuite indexées et utilisées en tant que critères  Lorsque la valeur est au format JSON et XML, certains moteurs permettent d’utiliser Apache SOLR pour de la recherche full-text sur l’agrégat Key = « product1 » Prop1: … Prop2: … Prop3: … Value à a Blob/CLob
  • 20. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Column Column name Column Value Title Product1
  • 21. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Super column name Column name Column Value … Column name Column Value ProductInfo Title Description Product1 Beautiful product you’ll find nowhere else 
  • 22. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Famille de colonnes Row key Column name Column name … Column Value Column Value … Title "1234-3213-2134-2121" … Description … Beautiful product you’ll find nowhere else  Product1
  • 23. LES MODÈLES DE DONNÉES NOSQL Famille de colonnes et super colonnes Super column name Column name Row key … Column Value Super column name Column name … Column Value Column name … Column Value Column name Column Value … ProductInfo "1234…2121" SellerInfo Title … Description Name … Location Product1 … l ToyStore … Paris Keyspace.get("products », »1234…2121", "ProductInfo », "Title »)
  • 24. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes:  S’il fallait comparer aux RDBMS Modèle relationnel Schéma Keyspace Table Famille de colonnes Clef primaire Idem Nom de colonne Idem Valeur de colonne  Il Modèle famille de colonnes (terminologie Cassandra) Idem vaut mieux considérer une famille de colonnes comme suit :  SortedMap[RowKey, SortedMap[ColumnKey, ColumnValue]]
  • 25. LES MODÈLES DE DONNÉES NOSQL  Synthèse  Dans les modèles Clef/Valeur, Orientés documents et famille de colonnes:  L’agrégat est l’unité de données  Les opérations sur un agrégat respectent le principe ACID  L’agrégat permet au DBMS de gérer d’organiser le stockage des données sur les noeuds du cluster  Lorsque les opérations sont groupées par agrégat, les modèles NoSQL sont justifiés.  Lorsque un nombre de relations limité doit être établi entre plusieurs agrégats les modèles relationnels nous permettent de conserver les propriétés ACID.  Mais alors comment gérer un nombre important de relations entre les objets  Les modèles relationnels font exploser les jointures  C’est là qu’intervient le modèle NoSQL communément appelé Base de données orientée Graphe
  • 26. LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE  Hayssam et Michèle ont des gouts similaires ?  Je peux proposer à Michèle tous les produits  Les produits dans l’ordre suivant :  Les produits achetés, "aimés" ou consultés par Hayssam
  • 27. LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE  Synthèse  Permet la gestion des relations entre agrégats  Organise  les données en nœuds et liens Ce modèle est intéressant en présence d’un volume important de liens  Inadapté à la navigation en cluster
  • 28. LES MODÈLES DE RÉPARTITION Le modèle centralisé  Le sharding  Maitre / esclave  Réplication point à point 
  • 29. LES MODÈLES DE RÉPARTITION  Le modèle centralisé Probablement le modèle le plus courant  Adapté à la grande majorité des cas  N’est pas en contradiction avec le modèle NoSQL 
  • 30. LES MODÈLES DE RÉPARTITION  Le sharding Résoudre le problème d’une trop forte charge sur les serveurs pour l’accès à des données disjointes.  Cible => Situation idéale (inatteignable dans la réalité)  Les utilisateurs sont uniformément répartis sur les serveurs  Ils accèdent à des données elles-aussi uniformément réparties  Big Server Row 1 … Row1000000 Row 1 Row 1000001 … Row2000000 … Row3000000 Row 2000001 … Row3000000
  • 31. LES MODÈLES DE RÉPARTITION  Les intérêts du sharding Meilleures performances en consultation et mises à jour  Réduction de la volumétrie des index   Les difficultés du sharding  Non transparent  L’application doit savoir quel serveur contient quelle donnée Jointures non autorisées entre les shards  Perte de l’intégrité référentielle inter-shards.   Autosharding Le DBMS est responsable de la répartition des données sur les serveurs  Service présent sur la majeure partie des DBMS NoSQL 
  • 32. LES MODÈLES DE RÉPARTITION  Maître / Esclave Propagation Mise à jour Maitre Esclave Consultation Propagation Esclave      Consultation Consultation Les lectures se font sur n’importe quel nœud du cluster Toutes les écritures sont effectuées sur le maître qui est chargé de les répercuter sur les esclaves Certaines lectures peuvent être incorrectes si l’écriture n’a pas encore été répercutée Inadapté à un trop important volume de données à écrire Le maitre est un SPOF
  • 33. LES MODÈLES DE RÉPARTITION  Réplication point à point Maître Maître Lecture / écriture Maitre Lecture/écriture Lecture/écriture Propagation Des écritures Les lectures / écritures se font sur n’importe quel nœud du cluster  Inconsistance en cas d’écritures simultanées sur un même sous ensemble de données à partir de différents maîtres  Merge des écritures possible malgré tout. 
  • 34. LES MODÈLES DE RÉPARTITION  Synthèse Le sharding permet de répartir les données sur plusieurs serveurs, chaque serveur étant responsable d’un sousensemble des données  La réplication duplique les données sur plusieurs serveurs  Le modèle maitre/esclave consiste à avoir un serveur chargé de propager les écritures  Le maître reste un SPOF  Le modèle point à point permet d’écrire sur n’importe quel nœud du cluster. Les nœuds se coordonnent ensuite pour synchroniser les copies  Peut provoquer des conflits lors des mises à jour de données 
  • 35. LA COHÉRENCE DES DONNÉES Le modèle ACID  Le théorème CAP  Les quorums  Le versioning 
  • 36. LA COHÉRENCE DES DONNÉES  Le modèle ACID  Atomicité   Tout ou rien Cohérence  Les transactions qui modifient l’état de la base font en sorte que les contraintes d’intégrité référentielle sont respectées  Est-ce bien de la cohérence ? Non   Isolation   Conflit en lecture et en écriture toujours possible Une transaction ne peut pas accéder aux données mise à jour par une autre transaction avant qu’elle ne soit validée par son propriétaire Durabilité  Toute transaction validée (commitée) est assurée d’être prise en compte quelque soit la panne (transaction logs).
  • 37. LA COHÉRENCE DES DONNÉES  Les conflits en écriture 1- Hayssam récupère le montant De la base soit 100€ 3- Hayssam rajoute 20 € 4- Hayssam met à jour la donnée en base 2- Michèle récupère le montant de la base soit 100€ 3- Michèle rajoute 10 € 5- Michèle met à jour la base Nouvelle valeur = 110 €   Solution : Verrou optimiste  L’enregistrement est verrouillé avant la lecture  Risque de provoquer un inter-blocage si Hayssam attend Michèle sur cette ressource et que Michèle attend Hayssam sur une autre ressource
  • 38. LE THÉORÈME CAP  Cohérence (Consistency)   Disponibilité (Availablity)   Garantie que les requêtes reçoivent une réponse même si un ou plusieurs nœuds sont défaillants Résistance au morcellement (Partition Tolerance)   Tous les nœuds du système voient exactement les mêmes données au même moment Aucune panne autre qu’une coupure réseau totale ne doit empêcher le système de répondre. Idéalement, le système doit être en mesure de réconcilier les mises à jour une fois les nœuds à nouveaux accessibles les uns des autres Théorème de Brewer:  Un système distribué ne peut garantir à un instant donné que 2 de ces 3 contraintes.
  • 39. LE THÉORÈME CAP  Situation idéale N 1 N 1 A V1 N 1 A V0 A V1 V1 U N 2 N 2 B 1 N 2 B V0 2 B V0 3 V1 V1
  • 41. LE THÉORÈME CAP CAP : Une panne du maître provoque une indisponibilité Maître Esclave Esclave Lectures Client Client Mises à jour Mises à jour 
  • 42. LE THÉORÈME CAP CAP = Résistance au morcellement => la valeur lue par B est incohérente  N 1 N 1 A V1 N 1 A V0 A V1 V1 U N 2 N 2 B 1 N 2 B V0 2 B V0 3 V0 V0
  • 43. CONSISTENT HASHING   Chaque partition est gérée par un et un seul vnoeud  Les vnoeud sont répartis sur les noeuds physiques  L’ajout ou le retrait d’un nœud physique amène le système à se reconfigurer en déplaçant des vnoeuds pour conserver une répartition uniforme des partitions.  Nombre minimum de partitions doit être de 10. 3 nœuds et 64 partitions – • La partitionnement est réalisé une fois pour toutes et devient DEFINITIF.  • Une clef est sur 160 bits 22 partitions sur un nœud et 21 sur les deux autres. On ajoute 1 nœud supplémentaire – Le système se reconfigure pour avoir 16 partitions par noeud.
  • 44. LES QUORUMS  Qorum  Le nombre minimum de nœuds qui doivent répondre avec succès pour considérer que l’opération s’est déroulée avec succès   N      Les R premiers nœuds qui renvoient la valeur demandée R<N W   Nombre de nœuds sur lesquels les données doivent être répliquées. R   Permet de réconcilier la cohérence et la disponibilité. Nombre de nœuds qui doivent répondre avec succès pour considérer que la création/mise à jour a été effectuée avec succès W<N Les performances sont directement liées à l’importance des valeurs R & W. Cohérence et disponibilité   Tolérer un nœud défaillant : N = 3, R = W = 2 Tolérer deux nœuds défaillants : N = 5, R = W = 3
  • 45. LE QUORUM DE LECTURE
  • 47. DÉTECTION ET RÉSOLUTION DES CONFLITS VECTOR CLOCKS Chaque donnée est accompagnée d’un identifiant de nœud et d’un timestamp  Quand deux clients mettent à jour la même donnée, on obtient une donnée avec deux vector clocks distincts.  La résolution est alors à l’initiative du client. 
  • 48. DÉTECTION DU CONFLIT Réplication Mise à jour Mise à jour Réplication Conflit détecté
  • 49. RÉSOLUTION ET QUORUM Value = Data.v2 Client GET (K, Q=2) Value = Data.v2 Update K = Data.v2 Value = Data.v1
  • 50. LA COHÉRENCE DES DONNÉES  Synthèse        Les conflits en écriture surviennent lorsque 2 clients mettent à jour la même donnée au même moment La prévention des conflits par une stratégie pessimiste peut provoquer des inter-blocages La prévention des conflits conduit à des algorithmes bloquants qui provoquent un ralentissement des applications Le théorème CAP indique qu’il faut choisir entre la disponibilité et la cohérence La cohérence ne requiert de consulter tous les noeuds du cluster, il suffit que le quorum soit rempli Les estampilles permettent de détecter les conflits Le vecteur d’estampilles indiquent quand les différents nœuds ont eu des mises à jour en conflit.
  • 52. CAS D’USAGE  Clef / Valeur  Cas d’usage      Stockage des informations de session  Memcached ou Riak Profil utilisateur ou Préférences Memcached si préférences non persistantes, Riak sinon Gestion de panier  Riak Cas à éviter    Relations entre les agrégats  Bien que certaines bases comme Riak permettent naviguer d’un agrégat à un autre Transactions multi-agrégats  Rend complexe le rollback Inerrogation sur la valeur de l’agrégat  La valeur n’est pas accessible   Même si Riak par exemple offre un mode recherche en texte intégral avec SOLR Opérations ensemblistes  Il n’est pas possible d’accéder à plusieurs clefs simultanément  Plusieurs aller/retour sont nécessaires entre le client et le DBMS
  • 53. CAS D’USAGE  Orienté Document  Cas d’usage    Logging d’événements  Les données pourront être shardées par application ou type d’événements (commande / Paiement / ect …) CMS / Blog  Publication de sites Web, Gestion des commentaires … Real time Web Analytics  Les agrégats peuvent être mis à jour     Nombre de pages vues, nombre de visiteurs Les agrégats étant sans schéma, de nouvelles métriques peuventêtre ajoutées à tout moment Applications e-commerce  Supporter n’importe quel type de produit avec n’importe quelle propriété. Cas à éviter  Transactions multi-document
  • 54. CAS D’USAGE  Orienté colonnes  Cas d’usage Logging d’événements  CMS, Plateforme de Blog  Compteurs  Famille de colonne CounterColumnType  Propriétés avec une date d’expiration  Bannières publicitaires  Accès en démo   Cas à éviter  Inadapté pour un prototype  Requiert de concevoir les familles de colonnes en amont de l’utilisation
  • 55. CAS D’USAGE  Graphes  Cas d’usage Réseaux sociaux  Services de géolocalisation, routage ou dispatching  Moteurs de recommandation   Cas à éviter Volume de données trop important pour résider sur un seul serveur  Mise à jour de propriétés sur un nombre important de noeuds 
  • 56. L’ANALYSE DE DONNÉES  Map / Reduce : Principe fonctionnel  La phase de mapping lit les données de la base et génère une map de clef/valeur   Parallélisation : Chaque couple sera traité par un acteur Ne fonction de réduction les entrées avec la même clef pour les agréger en une seule valeur Map Combine Map Job' request Map Map Map Reduce
  • 57. MAPREDUCE  Exemple : Calculer le nombre de pages dans la catégorie AUTO accédées entre le 1er janvier et le 7 janvier { "categories" : [ “Assurance”,” Auto”, “Promotion” ], "interaction" : { "age" : -1, "domain" : null, "name" : "INTERACTION_ID", "path" : null, "value" : "4b40fb8b-55eb-4319-9745-fccfe2be8f88" }, "keywords" : [ “ABC” ], "nodePath" : "/sites/ACME-SPACE/home/community/publications", "requestData" : { "accept" : "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "accept-charset" : "ISO-8859-1,utf-8;q=0.7,*;q=0.3", "accept-encoding" : "gzip,deflate,sdch", "accept-language" : "en-US,en;q=0.8,fr;q=0.6", "connection" : "keep-alive", "cookie" : "JSESSIONID=62b7421a-8e85-42aa-a0fd-816c34456502; INTERACTION_ID=4b40fb8b-55eb-4319-9745-fccfe2be8f88", "host" : "127.0.0.1:8080", "ipAddress" : "127.0.0.1", "referer" : "http://127.0.0.1:8080/cms/en/sites/ACME-SPACE/home/activities/satellites.html", "user-agent" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11" }, "sessionId" : "62b7421a-8e85-42aa-a0fd-816c34456502", "tags" : [ “Avantages” ], "time" : 1353415058212, "userid" : " guest " }
  • 58. MAP / REDUCE : UN EXEMPLE CONCRET  Phase de Mapping : Un objet est à retenir s’il référence la catégorie Auto var doTheMap = function(value) { try { var obj = Riak.mapValuesJson(value)[0]; if (obj.categories.indexOf("Auto") > -1 && new Date(2012,0,1).getTime() >= obj.time && new Date(2012,0,7).getTime() <= obj.time ) return [obj]; else return []; } catch (error) { return []; } }  Phase de Reduce : Compter le nombre de pages var reduceIt = function(values) { return [values.reduce(function(total, value) { return total + 1;}, 0)]; }  Lancer le Map/Reduce sur le bucket des visites riak.add("visites").map(doTheMap).reduce(reduceIt).run()   Plusieurs phases de maps et de reduce peuvent être appliquées successivement riak.add("visites").map(doTheMap1).map(doTheMap2). reduce(reduceIt1). reduce(reduceIt2).run()
  • 59. L’ANALYSE DE DONNÉES  Synthèse Map-reduce est un pattern de parallélisation des calculs sur un cluster  La Phase de mapping lit les données d’un agrégat et implemnte la condition qui consiste à retenir la donnée  La phase de réduction prend la liste des valeurs d’une clef et la réduit à une valeur unique 