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