Lorraine JUG (dec 2010) - NoSQL, des grands du Web aux entreprises
-
Upload
michael-figuiere -
Category
Documents
-
view
2.395 -
download
0
description
Transcript of Lorraine JUG (dec 2010) - NoSQL, des grands du Web aux entreprises
NoSQL
Des grands du Web aux entreprises
08/12/2010
Speaker
Michaël Figuière
@mfiguiere
blog.xebia.fr
JUGsNoSQL UG
A propos de NoSQL
No SQL
A propos de NoSQL
No SQL
Not Only
A propos de NoSQL
No SQLRelational
Not Only
Contrairement aux idées reçues
• NoSQL n’est pas un remplaçant des SGBDR
• NoSQL reste un domaine d’innovation
• NoSQL est un écosystème riche et complexe
The right tool for the right job
Mais déjà déployé en production !
« Le diable est dans le détail »
Au commencement
• Performance
• Disponibilité (> 99.99 %)
• Résilience
• Scalabilité horizontale
Des cas d’usage différents mais des besoins similaires : - Création de Dynamo
- Dernier incident majeur en 2004- < 40 min d’indisponibilité par an
- Création de BigTable + MapReduce- Toutes les pages Web du monde- Fonctionnement online et offline
Amazon : naissance de Dynamo
Fill cart Checkout Payment Process order Prepare Send
Stockage clé-valeur suffisant,disponibilité en écriture
Besoin en requêtes complexes,indisponibilité temporaire acceptable
Comment assurer la scalabilité avec un SGBDR ?
Réplication synchrone ou asynchrone
Mise en oeuvretypique avec MySQL
Sharding avec un SGBDR
Sharding avec un SGBDR
Sur serveur B
Sur serveur A
Sharding avec un SGBDR
Sur serveur B
Sur serveur A
??
Sharding avec un SGBDR
Sur serveur B
Sur serveur A
Dénormalisation
Dénormalisation
Sharding avec un SGBDR
Sur serveur B
Sur serveur A
Dénormalisation
Dénormalisation
On perd alors beaucoup de l’intérêt du relationnel !
Sharding avec un SGBDR : les problèmes
• Pour garder de bonnes performances, les relations many-to-many et many-to-one nécessitent d’être dénormalisées
• Gestion du resharding
• Code applicatif complexifié
D’une table de hachage à une BDD clé-valeur
Ensemble des cléspartitionnées selon
leur préfixe
D’une table de hachage à une BDD clé-valeur
Ensemble des clés
Consistent hashing
D’une table de hachage à une BDD clé-valeur
Une partition parinstance
Multiples partitionspar instance
Organisation des noeuds en anneau
Noeud
Noeud
NoeudNoeud
Noeud
Noeud
ReplicaPartition 1
ReplicaPartition 2
ReplicaPartition N
Organisation des noeuds en anneau
Noeud
Noeud
NoeudNoeud
Noeud
Noeud
Communication de proche en prochepour diffuser les changements de
topologie
Interactions Client / Serveur
Client
Client
Client
Client
Noeud
Noeud
NoeudNoeud
Noeud
Noeud
Interactions Client / Serveur
Client
Client
Client
Client
Noeud
Noeud Noeudreplica
Noeudreplica
NoeudNoeudreplica
?
Organisation des noeuds en anneau
Client
Client
Client
Client
Noeud
Noeud Noeudreplica
Noeudreplica
NoeudNoeudreplica
Agit en tantque proxy
Que devient ACID ?
• Tout accès réseau est faillible
• Des concessions doivent être faites sur le modèle de données
• Des concessions doivent être faites sur la consistance
Le théorème CAP
Consistance
Disponibilité
Toléranceaux défaillances Impossible
BDD relationnellesBDD NoSQL
Consistance éventuelle
Client
Client
Client
Client
Noeud
Noeud Noeudreplica
Noeudreplica
NoeudNoeudreplica
Transfère les requêtes R/W vers tous les réplicas
Consistance selon nombre de réponses attendues
4 réplicas
A A A A
Temps
Ecriture avec attented’accusé d’un seul noeud
Consistance selon nombre de réponses attendues
4 réplicas
A A A A
B A A A
Temps
Ecriture avec attented’accusé d’un seul noeud
Consistance selon nombre de réponses attendues
R + W < N
Lecture avec attente de réponse de 2 noeuds
4 réplicas
A A A A
B A A A
B A A A
Temps
Consistance selon nombre de réponses attendues
R + W = N
Ecriture avec attented’accusé de 2 noeuds
Lecture avec attente de réponse de 2 noeuds
A A A A
B B A A
B B A A
Consistance selon nombre de réponses attendues
R + W > N
Ecriture avec attented’accusé de 2 noeuds
Lecture avec attente de réponse de 3 noeuds
A A A A
B B B A
B B B A
Consistance apparente pour le client
Client
Client
Client
Client
Noeud
Noeud Noeudreplica
Noeudreplica
NoeudNoeudreplica
Transfère les requêtes R/W vers tous les réplicas
1
2
2
2
3
3
3
4
Atomicité et Isolation
• Les données ne sont plus co-localisées
• Les transactions distribuées nuiraient à la disponibilité et aux performances
• Atomicité et Isolation par opération sur une clé
Localisation non prédictible dans le temps
Durabilité
• Ecriture sur un ou plusieurs disques
• Ecriture multiples en mémoire
• En mémoire avec écriture asynchrone sur disque
La réplication permet de renforcer la durabilité
La réplication apporte la durabilité
Pas de durabilité
Base de données orientées clé-valeur
= HashMap !
Exemple avec Riak
Base de données orientées document
La BDD est consciente du contenu. Les requêtes complexes sont possibles
Exemple avec MongoDB
Base de données orientées colonnes
BDD relationnelle BDD orientée colonnes
A chaque ID de ligne correspond une liste de couples clé-valeur
Exemple avec Cassandra
A propos de Cassandra
Base de données orientées graphe
Exemple avec Neo4j
L’intérêt pour l’entreprise
• Stockage polyglotte : une meilleure adéquation entre la BDD et les données
• Scalabilité linéaire : être à même de répondre aux besoins les plus gourmands
• Haute disponibilité : du multi-serveurs au multi-datacenters
• Elasticité : une intégration naturelle à la logique du Cloud Computing
• Curseur pour s’adapter : + de consistence ou + de fiabilité (R + W > N)
• Et finalement... la possibilité crée le besoin !
NoSQL en production ?
• En production chez de nombreux « Grands du Web »
• Outillage encore réduit
• Monitoring par JMX
• Backups peuvent être problématiques avec des volumes importants
Cas d’usage : batch distribué
Application HBase Hadoop
Stockage des informations en
production
Exploitationdes résultats
Traitement batch distribué
Stockagedes résultats
Cas d’usage : stockage polyglotte
Application
Lucene
MySQL
Cassandra
Redis
Recherche desproduits
Stockage de données de sessions
Stockage du catalogue produits
Stockage des comptes clients
Questions / Réponses
?