1. Architectures Techniques
« noSQL »
© OCTO 2011

2. noSQL, c’est quoi?
 Ensemble de technologies alternatives aux RDBMS
 Un écosystème riche qui adresse des problématiques différentes
 Modélisation de la donnée (graphe…)
 « Data Analytics »
 « Transaction Processing »
© OCTO 2011 2

3. La fin des bases de données relationnelles?
NON…
© OCTO 2011 3

4. 40 années d’expérience.
Compatible avec
l’écosystème du SI.
Viable dans la majorité
des cas.
© OCTO 2011 4

5. 1970, premières bases de données relationnelles
Système
Centralisé
Atomicité
Optimisation Modélisation
du stockage relationnelle
Cohérence
Isolation
Durabilité
Moteur &
Stockage sur
Langage
disque
SQL
© OCTO 2011 5

6. POURTANT
© OCTO 2011 6

7. Des évolutions « hardware ».
Optimiser l’organisation de la donnée pour optimiser le stockage.
1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015
1,000,000.00
100k $/GB
POURTANT
100,000.00
10,000.00
1,000.00
HDD
100.00 RAM
10.00
1.00
0,10 $/GB
0.10
0.01
Source :http://www.mkomo.com/cost-per-gigabyte
© OCTO 2011 7

8. Des évolutions « hardware ».
Utiliser le disque pour contourner la limite de RAM.
1965 1970 1975 1980 1985 1990 1995 2000 2005 2010 2015
10 GB
1 GB
1,000.00
POURTANT
100.00
10.00
1 MB
1.00 RAM
0.10
0.01
0.00
0.00
Source : http://www.jcmit.com/memoryprice.htm
© OCTO 2011 8

9. Vers du « commodities »...
Des besoins qui dépassent la capacité d’une unique machine.
Optimisation du coût de la transaction.
$
POURTANT
$
Source : « Datacenter As A Computer »
© OCTO 2011 9

10. Vers plus de disponibilité des
systèmes.
Disponibilité (en écriture).
Tolérance à des niveaux de pannes plus importants,
à coût contraint.
POURTANT
© OCTO 2011 10

11. « Capacity Planning » &
administration simplifiée.
Elasticité et prédictibilité pour absorber les saisonnalités.
POURTANT
© OCTO 2011 11

12. L’approche « plateforme ».
et les enjeux de mutualisation sous jacent.
POURTANT
© OCTO 2011 12

13. Un constat : « scaler » un RDBMS, « ça
peut être complexe ».
Trafic en lecture.
W W
R R R
W/R
POURTANT
- Modéliser en fonction des
« patterns » d’accès.
- Dénormalisation
- Topologie Master / Slave
- Décharge les lectures
- (peut) impacter l’OPEX
- (potentielle) fenêtre
d’incohérence
- Stratégie de cache
- Améliore les temps de
réponse / débits en lecture
- Nécessite des stratégies
- De « rechargement »
- Des tolérances à la perte du cache
- (potentielle) fenêtre
d’incohérence
© OCTO 2011 13

14. Un constat : « scaler » un RDBMS, « ça
peut être complexe ».
Trafic en lecture.
W W
R R R
W/R
POURTANT
- Modéliser en fonction des
« patterns » d’accès.
- Dénormalisation
- Topologie Master / Slave
- Décharge les lectures
- (peut) impacter l’OPEX
- (potentielle) fenêtre
d’incohérence
- Partitionnement du cache
pour limiter l’impact en cas de
perte
- Impacts les « operations »
© OCTO 2011 14

15. Un constat : « scaler » un RDBMS, « ça
peut être complexe ».
Trafic en écriture.
W/R
W/R W/R W/R
POURTANT
- Modéliser en fonction des
« patterns » d’accès.
- Vers des modèles
K/V, modélidation par
évènements plutôt que
- Stratégie « scale up »
- (potentiellement) le coût
-
-
Impact à migrer sur du
« distribué »
Coût réseau induit par la
-Stratégie de partitionnement
- Complexité
d’administration, d’opérabilité
- (potentiellement) le coût
- Licence / infrastructure spécifique
distribution
stock, « append-only »
© OCTO 2011 15

16. Evolution du hardware
Vers du « commodities »
Un foisonnement
« Capacity planning » et de solutions
administration simplifiée
émergentes…
Transactionnel, Décisionnel…
Vers plus de disponibilité
des systèmes
L’approche
« plateforme »
© OCTO 2011 16

17. …construites sur
un ADN différent
© OCTO 2011 17

18. Distribution des données, de la
…construites sur
charge.
Mécanisme de partitionnement.
Routage client ou serveur suivant les implémentations.
Le partitionnement et l’association clé/serveur sont assurés via « consistent
un ADN différent
hashing ».
Client
md5(key) = GUS
JOE
#2
JOE BOB GUS «3»
BOB
GUS
© OCTO 2011 18

19. …construites sur
Tolérance à la panne.
Réplication synchrone / asynchrone.
« Fail-over » automatique.
Gestion applicative (et non plus « hardware ») de la résilience.
un ADN différent
JOE BOB GUS
GUS
BOB
JOE
© OCTO 2011 19

20. …construites sur
Elasticité de l’infrastructure.
Administration « simplifiée ».
Impact la modélisation
un ADN différent $ bin/nodetool decommision –h 10.0.0.2
JOE GUS BOB
GUS
BOB
JOE
© OCTO 2011 20

21. Challenge…
Durabilité
Atomicité
Cohérence
© OCTO 2011 21

22. Durabilité. Stockage sur disques standards voire en mémoire.
Challenge…
Réplication applicative des données.
Mécanismes de « write-behind », « write-through », « overflow ».
ms µs ns
0.000,000,000,000
Disque Cache L2, L1
Mémoire
© OCTO 2011 22

23. Relâchement de ACID.
Modélisation de la donnée en fonction des patterns d’accès.
Proche de ce qui est fait en relationnel sous contrainte de performance.
Possibilité de colocalisation des données.
Challenge… INSERT INTO…
JOE BOB GUS
© OCTO 2011 23

24. MapReduce ou l’art de distribuer le
traitement.
Traiter (plus rapidement) des volumes de données plus faibles.
Challenge…
Paralléliser ces traitements « plus unitaires ».
Co-localiser traitements et données.
Requête
Orchestrateur
Tâches Tâches
© OCTO 2011 24

25. A CID comme variable d’ajustement.
Challenge…
« Partition
Tolerant »
~ système distribué
« Availability » « Consistency »
La donnée est Les nœuds proposent
accessible la même donnée au
même moment
Source : « CAP Theorem » - Eric Brewer
© OCTO 2011 25

26. A CID vu du client.
Compromis entre cohérence, temps de réponse, tolérance à la panne en
fonction du type de la donnée.
Challenge…
Cohérence faible « Cohérence à terme »
Cohérence Forte
Aucune garantie de « Eventual « Read-your-write »
cohérence – garantie de récupérer
récupérer la dernière Consistency » &
la dernière version
donnée Quorum-based protocol
Source : « Eventually Consistent » - Werner Vogels
« Availability » « Consistency »
© OCTO 2011 26

27. « Read your write » cohérence.
Modèle Master/Slave (pour une partition donnée).
Réplication synchrone ou asynchrone.
Challenge…
Lecture « round robin » sur les partitions.
Client Write Client Write Client Read
md5(key) = 3 md5(key) = 3 md5(key) = 3
JOE
JOE JOE
© OCTO 2011 27

28. Cohérence à terme & « Quorum based
protocol »
Approche Master / Master (sur une partition donnée).
Challenge…
Compromis entre cohérence, temps de réponse, tolérance à la panne en
fonction du type de la donnée, du cas d’usage.
Résolution des conflits : suivant les implémentations.
Client Write Client Write Client Read
md5(key) = 3 md5(key) = 3 md5(key) = 3
JOE
JOE JOE
© OCTO 2011 28

29. Un nouvel univers
extrêmement riche.
Challenge…
« Partition
Tolerant »
« Data Grid »
noSQL
Amazon Dynamo clones
« Availability » « Consistency »
RDBMS
© OCTO 2011 29

30. « Data Grid : bridging the gap »
Un modèle moins en rupture, des solutions configurables.
Permet le stockage en mémoire pour privilégier la latence, le « near cache »...
Challenge…
« Distributed Event Driven Architecture » et mécanisme de notification.
RDBMS « Data Grid » noSQL
Client App Client App Client App
Near Cache
- « Disk based » - « throughput/latency oriented - « throughput oriented
- Stratégie « scale up » architecture » architecture »
- « Master/Slave » sur les - « Master/Master » sur les
partitions partitions
- Partitionnement / réplication - Partitionnement uniquement
- Cohérence configurable - « Eventually consistent »
- Cache local - « Disk based »
- « Disk / memory based »
© OCTO 2011 30

31. ET (APRÈS)
DEMAIN?
© OCTO 2011 31

32. « Big Memory » pour trouver l’équilibre
entre scalabilité horizontale et opérabilité
ET (APRÈS)
Modélisation indépendante du stockage.
DEMAIN?
© OCTO 2011 32

33. « Auto-scaling ».
ET (APRÈS)
Architectures élastiques (gérées au niveau
applicatif).
DEMAIN?
© OCTO 2011 33