les modèles nosql

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


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

(2) set amount = amount – 100

(3) update table

(1) select amount from table

(4) set amount = amount -100

(5) update table


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

(3) update table and unlock

(1)lock amount from table

(4) set amount = amount -100

(5) update table and unlock

Bloqué en attente de la libération du verrou


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


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 1PHP

Application 2Java

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

Pics

Brand

Category

Tag1 Tag2tag3

Product description

PriceProducts

Categories

Brands

Tags

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 1PHP

Application 2Java

Application …Ruby

JSONSOAP/XML

Peu importe Peu importe 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

SERVER1 SERVER2 SERVER…VERY BIG 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

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

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

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.

http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page

http://nosql.eventbrite.com/

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

Products

Categories

Brands

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é


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.


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.


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

Blob

Key = « product1 »

Key = « product… »

Key = « product2 »

Value est un Blob/CLob




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

category:"computer",

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

…}

}Key = "product2" {

product : {…

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

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 » Value à a Blob/CLob

Prop1: …Prop2: …Prop3: …

LES MODÈLES DE DONNÉES NOSQL Le modèle famille de colonnes:

Column name

ColumnValue

Column

Title

Product1


Column name

ColumnValue

Column name

ColumnValue

…

Super column name

ProductInfo

Title Description

Product1 Beautiful product you’ll find nowhere else


Famille de colonnes

Column name

ColumnValue

Column name

ColumnValue

…Row key

"1234-3213-2134-2121"

Title … Description

Product1…

Beautiful product you’ll find nowhere else

…


Row keyColumn

name

ColumnValue

Column name

ColumnValue

…

Super column name

Column name

ColumnValue

Column name

ColumnValue

…

Super column name

…

Famille de colonnes et super colonnes

…

"1234…2121"

ProductInfo SellerInfo

Title … Description Name … Location

Product1 … l ToyStore … Paris

Keyspace.get("products », »1234…2121", "ProductInfo », "Title »)


S’il fallait comparer aux RDBMS

Il vaut mieux considérer une famille de colonnes comme suit : SortedMap[RowKey, SortedMap[ColumnKey, ColumnValue]]

Modèle relationnel Modèle famille de colonnes (terminologie Cassandra)

Schéma Keyspace

Table Famille de colonnes

Clef primaire Idem

Nom de colonne Idem

Valeur de colonne Idem

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

…

Row3000000

Row 1…Row1000000

Row 2000001…Row3000000

Row 1000001…Row2000000

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

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

Maitre

Esclave

Esclave

Mise à jour

Propagation

PropagationConsultation

Consultation

Consultation

LES MODÈLES DE RÉPARTITION Réplication point à point

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.

Maitre

Maître

Maître

Lecture / écriture

Lecture/écriture

Lecture/écriture

PropagationDes écritures

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 sous-ensemble 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


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

Conflit en lecture et en écriture toujours possible Isolation

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


Les conflits en écriture

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

1- Hayssam récupère le montantDe 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 €

LE THÉORÈME CAP Cohérence (Consistency)

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

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)

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

A V1 V0 A V1 A V1

B V1V1B V0B V0

U

N1 N1 N1

N2 N2 N2

1 2 3

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

Client Client

Lectures

Mis

es à

jour

Mises à jour

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

incohérente

A V1 V0 A V1 A V1

B V0V0B V0B V0

U

N1 N1 N1

N2 N2 N2

1 2 3

CONSISTENT HASHING Une clef est sur 160 bits La partitionnement est réalisé une

fois pour toutes et devient DEFINITIF.

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

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

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

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

W 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 LECTURERe

ad(k

ey, R

=2, N

=4)

XX

LE QUORUM D’ÉCRITURE

XX

Writ

e(ke

y, W

=2, N

=4)

DÉTECTION ET RÉSOLUTION DES CONFLITSVECTOR 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

RéplicationConflit détecté

Mise à jour

Mise à jour

RÉSOLUTION ET QUORUM

Client

GET (K, Q=2)

Value = Data.v2

Value = Data.v2

Value = Data.v1

Update K = Data.v2


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.

LE THÉORÈME CAP : POSITIONNEMENT DES BASES NOSQL

http:

//bl

og.b

eany

.co.

kr/a

rchi

ves/

275

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

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

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 [];}

}

var reduceIt = function(values) {return [values.reduce(function(total, value) { return total + 1;}, 0)];

}

Phase de Reduce : Compter le nombre de pages

Lancer le Map/Reduce sur le bucket des visites

Plusieurs phases de maps et de reduce peuvent être appliquées successivement riak.add("visites").map(doTheMap1).map(doTheMap2). reduce(reduceIt1). reduce(reduceIt2).run()

riak.add("visites").map(doTheMap).reduce(reduceIt).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

les modèles nosql

Technology