Ce document présente une introduction au NoSQL, en comparant les bases de données relationnelles (RDBMS) avec les systèmes NoSQL et en soulignant les limitations des RDBMS en termes de scalabilité et de consistance. Il aborde les différents types de bases NoSQL, leurs caractéristiques, ainsi que des concepts comme le sharding, la réplication et le modèle d'agrégation. Enfin, il discute également des techniques de traitement de données comme MapReduce et les principes du polyglot persistence.

1. Introduction
NoSQL
Laurent Broudoux (@lbroudoux) | Janvier 2014

2. Quelques mots...
Laurent Broudoux
Le jour ...
Architecte IT Senior chez MMA
Mots-clés : Java, SOA, Agile, Software factories
La nuit …
Coder, geek, open source comitter (voir http://github.com/lbroudoux)
Me joindre / suivre
@lbroudoux
laurent.broudoux@gmail.com
http://lbroudoux.wordpress.com

3. Comprendre SQL vs NoSQL
? ? ??
? ? ? ?
??

4. Les bases relationnelles et SQL ?
●
Modèle prédominant pour stocker de l'information
depuis + de 30 ans !
Nécessité de nombreuses
lectures / écritures en
simultané. Les RDBMS
proposent un système de
gestion de transaction
efficace permettant
d'éviter le pire !
Ecosystème riche et
Les RDBMS ont imposé un
collaboration
paradigme de
indispensable. L'écriture
modélisation et un
puis les lecture dans un
lanqage de requêtage
RDBMS est un modèle
(SQL) standards
fréquent d'intégration
globalement partagé
applicative.
entre tous les vendeurs.

5. Les limites des bases relationnelles (i)
Impedance mismatch
orders
id : 1001
customer : lbroudoux
line items :
customers
bird
8
3.25 €
26 €
rabbit
4
22 €
88 €
cat
2
112 €
224 €
order lines
payment details :
card
Master Card
card number
1234-5678-9101
expiry
12/2014
credit cards

6. Les limites des bases relationnelles (ii)
Scalabilité
Le modèle de consistance des RDBMS
empêche l'utilisation de plusieurs
machines pour répartir la charge (au moins
en écriture)
Pour augmenter la performance d'accès à la base, pas d'autres
moyens que d'acheter un plus gros serveur, puis un autre, puis un
autre, …

7. Eléments de contexte
●
Plusieurs tendances forment le terreau d'un changement
–
La SOA (Service Oriented Architecture)
●
–
Intégration applicative maintenant basée sur la notion de service
Le cloud et les besoins en très haute disponibilité
●
●
–
Prédominance des clusters
Approche commodity hardware
La réalité économique
●
Coût des machines très haute performance
●
Facturation « au cœur » par les vendeurs

8. NoSQL ?
Terme apparu en 2009 avec plusieurs
interprétations possibles :
–
No SQL
–
Not Only SQL
Pas de définition formelle mais des
caractéristiques communes partagées par les
bases dites NoSQL :
–
–
Conçu pour être exécutée dans un cluster,
–
Tendance à être Open Source,
–
NoSQL s'écarte du modèle
de données relationnel pour
généralement proposer un
modèle par agrégat.
N'utilise pas de modèle relationnel et donc
pas le langage SQL
Généralement sans schéma et donc
permettant de stocker n'importe quelle
donnée dans n'importe quelle « ligne »

9. Relations & Agrégats (i)
●
Soit un modèle relationnel exemple, exprimé en UML, en
utilisant des associations

10. Relations & Agrégats (ii)
●
Soit sa projection sur le modèle relationnel physique
Normalisation, pas de répétition, agnostique à l'usage
–
Orders
Customers
Id
Name
Id
CustomerId
ShippingAddressId
123
Broudoux
99
123
66
Products
BillingAddress
Id
Name
Price
Id
CustomerId
AddressId
27
Rabbit
3.25
55
123
66
Items
Address
Id
OrderId
ProductId
Quantity
Price
Id
City
991
99
27
3
9.75
66
Parigne Le Polin
Payments
Id
OrderId
CardNumber
TxnId
BillingAddressId
991
99
1234-4567-8910
a23ef75cd65b78
66
Street

11. Relations & Agrégats (iii)
●
Reprenons le même modèle selon l'approche « agrégat »
–
On utilisera plutôt des compositions pour marquer les agrégats
Un agrégat
représente une
unité de
manipulation des
données et
de gestion de
la cohérence

12. Relations & Agrégats (iv)
●
Soit sa projection en
JSON (notation
communément utilisé
dans le monde NoSQL)
–
Dénormalisation
–
2 agrégats principaux
–
Relations entre
agrégats arbitraires et
assurées
applicativement

13. Conséquences de l'approche agrégats
●
L'approche agrégat règle les problèmes d'impédance
mismatch mais :
–
Difficile de déterminer clairement les limites entre agrégats
–
Le coté schemaless est un + mais à double tranchant
Difficile de réaliser certaines requêtes non prévues (penser à
l'analytique)
●
●
L'approche agrégat présente tout de même l'énorme avantage
de limiter le vérouillage transactionnel à l'agrégat
–
ACID pour RDBMS
–
BASE pour NoSQL
●
Basic Availability Soft-state Eventually consistent

14. Modèles de
Distribution

15. Sharding (i)
Chaque shard lit et écrit
ses propres données

16. Sharding (ii)
●
Bénéfices
–
Performance
●
En écriture car scaling horizontal
●
En lecture lorsque géolocalisation des données
–
–
●
Espace disque des machines
Résilience localisée
Préoccupations
–
Répartition équitable des données
–
Localisation des accès communs - d'où les agrégats ;-)
–
Sharding as application logic ?!

17. Réplication Maître / Esclave (i)
Maître
Toutes les écritures sont
faites sur le maître
Lectures peuvent être faites
depuis le maître ou les esclaves
Les
changements se
propagent vers
les esclaves
Esclaves

18. Réplication Maître / Esclave (ii)
●
Bénéfices
–
Pour les applications avec beaucoup de lectures
●
●
–
●
Performance
Résilience
Elasticité par le provisioning de nouveaux esclaves
Préoccupations
–
Inconsistance possible en lecture (local read-write à gérer
par le driver)
–
Résilience pour l'écriture fonction de la capacité de
changement de rôle (maître est un SPOF)
–
Algorithme de vote automatique et split brain !

19. Réplication Peer to Peer (i)
Noeud
Tous les nœuds lisent
et écrivent toutes les
données
Les nœuds
communiquent
uniquement
leurs écritures
Noeud

20. Réplication Peer to Peer (ii)
●
Bénéfices
–
–
Elasticité par le povisionning transparent
–
●
Résilience en lecture comme en écriture
Performances des lectures
Préoccupations
–
Inconsistances car écritures simultanées possibles
–
Performances des écritures
–
Voir les quorums ...
Volume de données à synchroniser et sens de synchro !
●

21. Combinaison Sharding & Réplication
Maître / Esclave
Maître pour 2
Esclave pour 2
Maître pour 2
Maître pour 1
Esclave pour 2
Esclave pour 1
shards
shard – Esclave
pour 1 shard
shards
shards
shard
shard

22. Combinaison Sharding & Réplication
Peer to Peer

23. Théorème CAP
« Il est impossible pour un système distribué de
satisfaire plus de 2 des 3 propriétés suivantes :
Cohérence, Disponibilité et Résistance au
morcellement »
- Eric Brewer, 2000

24. Théorème CAP
Cohérence
Disponible
[Consistancy]
[Availability]
Tous les clients
voient les
CA
mêmes données
CP
Le système continue
de fonctionner en
cas de panne de
noeuds
AP
Le système continue de
fonctionner même en cas
d'échec de communication
entre noeuds
Résistance au morcellement
[Partition tolerance]

25. « Relâcher la consistance »
●
Ecritures inconsistantes
–
–
●
Classiquement : pessimiste (verrou) ou optimiste
(versionning)
NoSQL : Ces approches ne fonctionnent pas si le système est
distribué !
Lectures inconsistantes
–
Classiquement : transaction et verrouillage de plusieurs
tables
–
NoSQL : Cette approche ne fonctionne pas si les données
sont réparties sur plusieurs agrégats !

26. « Relâcher la consistance »
●
Stratégies alternatives
–
Enregistrer les écritures inconsistantes, résoudre plus tard
(ex : Amazon Cart)
–
Réduire la fenêtre d'inconsistance en relâchant la durabilité
–
Les Quorums
●
« Combien de nœuds pour considérer la consistance comme
forte ? »
●
Soit W le nombre de nœuds devant acquitter une écriture
●
Soit N le nombre de réplicats d'une donnée (replication factor)
●
Soit R le nombre de nœuds devant acquitter une lecture
Consistance forte quand : W > N / 2 et R + W > N

27. Map Reduce
Computation

28. Map Reduce ?
●
L'avènement des agrégats est en grande partie due aux
clusters
–
–
●
Compromis dans la façon de stocker les données mais pas
seulement …
Nécessité de revoir la façon dont les données sont manipulées !
Dans « l'ancien monde », il y avait 2 choix :
–
Faire le traitement sur le client : liberté dans la plate-forme,
délestage du serveur mais seulement si peu de données
–
Faire le traitement sur le serveur : contrainte environnement,
peu de données à transférer mais charge !

29. Map Reduce ?
●
Avec un cluster :
–
–
●
Plein de puissance car plein de machines !
Mais encore plus la nécessité de transférer le moins de
données possible et de réaliser le travail sur le nœud
possédant les données !
Map-Reduce est un pattern inspiré de la programmation
fonctionnelle
K
map
V
K
V
K
V
reduce
K
R
Map transforme chaque
Reduce récolte toutes les paires
élément d'une collection et
ayant la même clé et réalise le
émet des paires clé / valeur
calcul pour retourner un résultat

30. Mon premier Map Reduce (i)
Agrégat représentant une facture client : « Quel est le total
des ventes par produit ? »
id : 1001
customer : lbroudoux
line items :
bird :
bird
8
3.25 €
26 €
rabbit
4
22 €
88 €
cat
2
112 €
224 €
shipping address : ...
payment details : ...
map
rabbit :
cat :
Price : 26 €
quantity : 8
Price : 88 €
quantity : 4
Price : 224 €
quantity : 2
La fonction « map » lit les enregistrements depuis la base et émet des paires de
clés / valeurs. On choisit la clé en fonction du critère de regroupement voulu.

31. Mon premier Map Reduce (ii)
Le système rassemble toutes les paires ayant la même clé
avant de les transmettre à la fonction de réduction
price : 26
quantity : 8
bird :
price : 13 €
quantity : 4
reduce
bird :
price : 46.5 €
quantity : 14
price : 7.5 €
quantity : 2
La fonction « reduce » prend plusieurs paires de clés / valeurs ayant la même clé et
les aggrège en une seule.

32. Partitionnement et combinaison
●
●
●
Sous la forme la plus simple, un job map-reduce exécute
la fonction reduce une seule fois …
… mais n'oublions pas qu'un système NoSQL est
naturellement distribué ...
Que se passe t-il quand il y a plusieurs millions
d'agrégats à traiter ?
–
Quelle quantité de données à transférer ?
–
Quelle performance ?
Il est possible d'augmenter le parallélisme en partitionnant
les résultats de la fonction map.

33. Map Reduce partitionné
bird
rabbit
2
rabbit
4
cat
m
12
6
bird
rabbit
3
fish
20
fish
m
3
6
bird
{
{
12
cat
6
rabbit
2
rabbit
4
bird
12
bird
3
cat
6
rabbit
2
rabbit
4
bird
3
rabbit
3
rabbit
3
fish
20
fish
20
fish
6
fish
r
6
r
Le partitionnement permet à la fonction « reduce » de s'exécuter en parallèle sur
différentes clés, voir sur différents noeuds

34. Partionnement et combinaison
●
La plupart des données transférées est répétitive
–
Même ensemble de clés
Il est possible de diminuer le volume de données en combinant
les résultats de la fonction map avant de les transférer.
map
combine
Local
reduce
Potentiellement distant

35. Map Reduce combiné
bird
rabbit
3
fish
20
bird
15
cat
2
rabbit
5
fish
6
fish
26
rabbit
2
cat
3
bird
12
cat
m
3
1
r
combine
r
La fonction « combine » permet de réduire les données à transférer au travers du
réseau avant la réduction. Une telle fonction est aussi par nature une fonction de
réduction.

36. Panorama
Bases NoSQL
Implémentons !

37. Bases clés / valeurs (i)
C'est quoi ?
●
●
Grossièrement : une simple hash table où tous les accès se font
en utilisant la clé primaire
Seulement 3 opérations possibles :
–
–
●
Get : récupérer la valeur d'une clé
–
●
Put : donner une valeur à une clé
Delete : effacer la clé et sa valeur
Support de structures basiques (list, hash, set)
Parfois, notion de bucket ou couplage à un moteur d'indexation (ex :
Riak)
●
Très haute performance (in-memory possible)
●
RESTful !

38. Bases clés / valeurs (ii)
A utiliser pour ...
–
De l'information très volatile
●
–
Session utilisateur, données d'un panier d'achat
De l'information très peu volatile et accéder très fréquemment
●
Descriptions produit, paramétrage applicatif
A éviter pour ...
–
Des données possédant des relations
●
Relations entre agrégats ou corrélation entre données de
différents ensemble de clés
–
Des opérations impliquant de multiples clés
–
Des besoins de requêtage par les données

39. Bases document (i)
C'est quoi ?
●
Bases stockant des documents qui peuvent être des arbres
Xml, JSON, BSON, etc …
–
●
Documents souvent regroupés par Collection
–
●
●
Pensez à des bases clés-valeurs où le contenu est examinable
2 documents de la même Collection ne possèdent pas
nécessairement la même structure
Requêtes possibles en utilisant des syntaxes analogues à
Xpath, Xquery, Javascript, JXPath
Parfois, fonctions d'agrégation : sum, count, group

40. Bases document (ii)
A utiliser pour ...
–
Données avec partie structurée et partie non structurée
●
–
Données de publication variables
●
–
Evénements des applicatifs (sharding possible par application)
CMS, Blogging avec commentaires, contenu dynamique, etc …
Données de suivi temps réel ou analytiques
A éviter pour ...
–
Opérations nécessitant consistance sur plusieurs agrégats
–
Des structures d'agrégat très changeante avec des besoins de
requêtage forts
●
Inconvénient du schemaless

41. Bases column-family (i)
C'est quoi ?
●
Données définies par une clé à laquelle peut correspondre
plusieurs familles de colonnes étant elles même des maps de
données
Famille de
colonnes
name
''broudoux''
« profile »
billingAddress
data ...
payment
data ...
odr1001
data ...
odr1002
data ...
Famille de
odr1003
data ...
colonnes
odr1004
data ...
123
Clé de ligne
« orders »
●
Langage de requête souvent pauvre
Clé de colonne
Valeur de colonne

42. Bases column-family (ii)
A utiliser pour ...
–
Données avec partie structurée et partie non structurée
●
–
Evénements des applicatifs (sharding possible par application)
Données de publication variables
●
CMS, Blogging avec commentaires, contenu dynamique, etc …
–
Compteurs et analytiques
–
Données avec TTL
A éviter pour ...
–
Des besoins de requêtage complexes
–
Des besoins de calcul d'agrégation simples (nécessité de
passer systématiquement par Map-Reduce aujourd'hui)

43. Bases graph (i)
C'est quoi ?
●
Stockage sous forme d'entités (nodes) et d'associations (edges)
●
Les nodes possèdent des propriétés (penser à un objet)
●
Les edges possèdent un type (likes, author)
●
Optimisées pour traverser le graph rapidement dans n'importe
quel sens
–
●
« Quelles sont les personnes employées par X dont les amis aiment le
film Y ? »
Modèle de distribution contraint : pas de sharding automatique,
seulement réplication
●
Langages de requête « exotiques » : Gremlin, Cypher
●
Parfois, complété par un moteur d'indexation

44. Bases graph (ii)
A utiliser pour ...
–
Les moteurs de recommandations
●
–
Les données naturellement connectées
●
–
« Les autres clients ayant acheté ce produit ont aussi acheté ... »
Réseaux sociaux
Les services basés sur la localisation ou le calcul d'itinéraires
A éviter pour ...
–
Les cas où de nombreux nœuds doivent être mis à jour

45. Panorama des solutions
Clé / valeurs
Document
Column family
Graph
En
mémoire
Persistante
sur disque
Neo4j

46. Au delà de NoSQL...
« Polyglot Persistence » from Thoughtworks NoSQL Intro

47. Au delà de NoSQL...
BigData et Hadoop FileSystem
–
Principes analogues mais appliqués à un file system
●
Sharding, replication, quorums pour la lecture / écriture
●
Map/Reduce pour la manipulation des données

48. Merci !