Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises
Upcoming SlideShare
Loading in...5
×
 

Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises

on

  • 2,036 views

 

Statistics

Views

Total Views
2,036
Views on SlideShare
2,036
Embed Views
0

Actions

Likes
2
Downloads
45
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises Presentation Transcript

  • NoSQLDes grands du Web aux entreprises14/03/2011
  • Speaker @mfiguiere blog.xebia.fr Michaël Figuière Distributed Architectures NoSQLSearch Engines
  • A propos de NoSQL No SQL
  • A propos de NoSQL Not Only No SQL
  • A propos de NoSQL Not Only No SQL Relational
  • Contrairement aux idées reçues• NoSQL n’est pas un remplaçant des SGBDR The right tool for the right job• NoSQL reste un domaine d’innovation Mais déjà déployé en production !• NoSQL est un écosystème riche et complexe « Le diable est dans le détail »
  • Au commencementDes cas d’usage différents mais desbesoins similaires : - Création de Dynamo - Dernier incident majeur en 2004• Performance - < 40 min d’indisponibilité par an• Disponibilité (> 99.99 %)• Résilience• Scalabilité horizontale - Création de BigTable + MapReduce - Toutes les pages Web du monde - Fonctionnement online et offline
  • Amazon : naissance de Dynamo Besoin en requêtes complexes, indisponibilité temporaire acceptable Fill cart Checkout Payment Process order Prepare Send Stockage clé-valeur suffisant, disponibilité en écriture
  • Comment assurer la scalabilité avec un SGBDR ? Mise en oeuvre typique avec MySQL Réplication synchrone ou asynchrone
  • Sharding avec un SGBDR
  • Sharding avec un SGBDRSur serveur A Sur serveur B
  • Sharding avec un SGBDRSur serveur A Sur serveur B ? ?
  • Sharding avec un SGBDRSur serveur A Dénormalisation Sur serveur B Dénormalisation
  • Sharding avec un SGBDRSur serveur A Dénormalisation Sur serveur B 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és partitionné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 par Multiples partitions instance par instance
  • Organisation des noeuds en anneau Noeud Noeud Noeud Noeud Noeud Replica Noeud Partition 1 Replica Replica Partition 2 Partition N
  • Organisation des noeuds en anneau Noeud Noeud Communication de Noeud proche en proche Noeud pour diffuser les changements de topologie Noeud Noeud
  • Interactions Client / Serveur Client Noeud Noeud Client Noeud Noeud Client Client Noeud Noeud
  • Interactions Client / Serveur Client Client ? Noeud Noeud replica Noeud Noeud replica Client Noeud Client replica Noeud
  • Organisation des noeuds en anneau Client Noeud Noeud replica Client Noeud Noeud replica Client Noeud Client replica Noeud Agit en tant que 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 Sur ces 3 propriétés, seules 2 sont réalisables Consistance à la fois Disponibilité Tolérance aux défaillances
  • Le théorème CAPBDD NoSQL BDD relationnelles Consistance Disponibilité Tolérance aux défaillances Impossible
  • Consistance éventuelle Client Noeud Noeud replica Client Noeud Noeud replica Client Noeud Client replica Noeud Transfère les requêtes R/W vers tous les réplicas
  • Consistance selon nombre de réponses attendues Temps A A A A 4 réplicas
  • Consistance selon nombre de réponses attendues Temps A A A A 4 réplicas B A A A Ecriture avec attente d’accusé d’un seul noeud
  • Consistance selon nombre de réponses attendues Temps R+W<N A A A A 4 réplicas B A A A B A A ALecture avec attente de Ecriture avec attente réponse de 2 noeuds d’accusé d’un seul noeud
  • Consistance selon nombre de réponses attendues R+W=N A A A A B B A A B B A ALecture avec attente de Ecriture avec attente réponse de 2 noeuds d’accusé de 2 noeuds
  • Consistance selon nombre de réponses attendues R+W>N A A A A B B B A B B B ALecture avec attente de Ecriture avec attente réponse de 3 noeuds d’accusé de 2 noeuds
  • Consistance apparente pour le client 1 Client Noeud Noeud 2 replica 3 Client 4 2 Noeud Noeud 3 replica Client 3 2 Noeud Client replica Noeud Transfère les requêtes R/W vers tous les réplicas
  • Atomicité et Isolation• Les données ne sont plus co-localisées Localisation non prédictible dans le temps• Les transactions distribuées nuiraient à la disponibilité et aux performances• Atomicité et Isolation par opération sur une clé
  • Durabilité• Ecriture sur un ou plusieurs disques La réplication permet de renforcer la durabilité• Ecriture multiples en mémoire La réplication apporte la durabilité• En mémoire avec écriture asynchrone sur disque Pas de durabilité
  • Base de données orientées clé-valeur = HashMap !
  • Exemple avec Riak
  • 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
  • Exemple avec MongoDB
  • Base de données orientées colonnes A chaque ID de ligne correspond une liste de couples clé-valeur BDD relationnelle BDD orientée colonnes
  • 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 : BI sur la BDD de production Stockage des informations en Traitement batch production distribué Application HBase Hadoop Exploitation Stockage des résultats des résultats
  • Cas d’usage : stockage polyglotte Recherche des Solr produits Stockage du catalogue produits MySQL Application Stockage des Cassandra comptes clients Stockage de Redis données de sessions
  • Questions / Réponses ?