les modèles nosql
TRANSCRIPT
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.
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
(2) set amount = amount – 100
(3) update table
(1) select amount from 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
(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
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 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.
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é
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 »
Key = « product… »
Key = « product2 »
Value est un Blob/CLob
Value est un Blob/CLob
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",
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
LES MODÈLES DE DONNÉES NOSQL Le modèle famille de colonnes:
Column name
ColumnValue
Column name
ColumnValue
…
Super column name
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
Column name
ColumnValue
Column name
ColumnValue
…Row key
"1234-3213-2134-2121"
Title … Description
Product1…
Beautiful product you’ll find nowhere else
…
LES MODÈLES DE DONNÉES NOSQL
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 »)
LES MODÈLES DE DONNÉES NOSQL Le modèle famille de colonnes:
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
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
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).
LA COHÉRENCE DES DONNÉES
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
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.
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