SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

PrezFlash :: NoSQL

fathi avatar
fathi
53 diapositives · 836 Views · Jul 24, 2014

PrezFlash :: NoSQL. Jérôme Mainaud 19 juillet 2011. 1. 1. «  NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. » Emmanuel Bernard — 2011. Il était une fois. SQL. Modèle de données relationnel. Panier PAN _ID CLI_ID DATE

PrezFlash :: NoSQL - slide 1
01 / 53PrezFlash :: NoSQL
1 / 17

Télécharger la présentation

PrezFlash :: NoSQL
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. PrezFlash :: NoSQL Jérôme Mainaud 19 juillet2011 1 1

  2. « NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. » Emmanuel Bernard — 2011

  3. Il était une fois SQL

  4. Modèle de données relationnel Panier PAN_ID CLI_ID DATE MONTANT_TOTAL TVA Client CLI_ID NOM ADRESSE CLI_ID PAN_ID Article PAN_ID CMD_ID QUANTITE PRIX_UNITAIRE

  5. SQL • Un langage de requête plus ou moins normé • Tout information est décrite par des listes de n-uplets • Opérations puissante • Sélection (where) • Projection (select) • Produit cartésien (join) • Union • Intersection • Différence

  6. Transactions ACID

  7. Marché mature • Utilisé depuis des dizaines d’années • De nombreux fournisseurs et de nombreux outils • Oracle • SQL Server • Mysql • Postgresql • MariaDB (clone de Mysql) • MS Access

  8. Bases de données relationnelles Utilisé mais pas choisi

  9. Mise en œuvre d’un SGBD-R Base de données Serveur Applicatif HTTP JDBC

  10. Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données JDBC HTTP

  11. Mise en œuvre d’un SGBD-R Base de données Serveurs Applicatifs HTTP JDBC

  12. Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données JDBC HTTP

  13. Montée en charge difficile • Les règles d’intégrité compliquent la montée horizontale • Montée en charge verticale • Coût non linéaire • Atteint une limite • Point unique de défaillance

  14. Coût des transactions ACID • La lecture est éparpillée • Lecture d’un panier de N articles • 2 requêtes • 2 IO pour lire le panier • N+1 IO pour les articles • L’écriture est lente • IO synchronisés • La durée d’une requête est difficile à prévoir • Select * fromtwhere id = ? • Select * fromtwhere date < (select max(date) fromot)

  15. Le modèle Entité Relation peu exploité • Le modèle Entité-Relation est souvent peu exploité • Utilisation du CRUD • Utilisation de caches • Memcache • Ehcache • Correspondance ORM • C’est le modèle objet qui est privilégié

  16. Repenser les bases de données Not oNLY SQL

  17. Montée en charge linéaire • Deux critères • Volume des données • Nombre de requêtes • Twitter • Janvier 2010 : 50 M/j • Juin 2011 : 200 M/j • Le coût doit augmenter linéairement

  18. Performances — temps d’accès Il est plus rapide d’interroger une autre machine que de lire sur le disque local

  19. Performances prédictibles • La performance des opérations doit être prédictible • Amazon: • Perte de 1 % de chiffre d’affaire si le temps d’affichage des pages augmente de 0,1 s • Plan qualité interne : Temps de réponse doit être < 300 ms pour 99,9 % des requêtes pour un pic de 500 requêtes par secondes • Google pénalise les sites dont les pages s’affichent en plus de 1,5 s

  20. Prise en compte des pannes • La panne est la règle • Amazon: • Un datacenter de 100 000 disques • entre 6 000 et 10 000 disques en panne par an • (25 disques par jour) • Les sources de panne sont nombreuses • Matériel serveur (disque) • Matériel réseau • Alimentation électrique • Anomalies logicielles • Mises à jour des logiciels et des OS.

  21. CAP

  22. « You can have atmosttwo of theseproperties for anysharded-data system. » Eric A. Brewer— 19 juillet 2000 Théorème CAP

  23. Théorème CAP Bases distribuées Verrous distribués Verrou pessimiste La partition minoritaire est indisponible Oracle RAC LDAP Commit à 2 phases Cache validation DNS Cache Web Expiration Résolution de conflit Verrou optimiste

  24. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 Version 1 Version 1 Client A Client B

  25. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 MAJ 1  2 Version 1 Version 1 Client A Client B

  26. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 Version 2 Version 1 Client A Client B MAJ 1  2

  27. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 Version 2 Version 2 Client A Client B Lit version 2

  28. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 MAJ 1  2 Version 1 Version 1 Client A Client B

  29. Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 Version 2 Version 1 Client A Client B MAJ 1  2 Perte du message

  30. Théorème CAP — Démonstration par l’exemple

  31. Le choix d’Amazon Lors qu’un client clique sur le bouton « acheter » Faut-il ?

  32. Cohérence à terme Continuum

  33. Cohérence par Quorum V2 V1 V1 Client A N réplicas V1 Client B V1 V1

  34. Cohérence par Quorum Le client attend E OK pour valider l’écriture V2 OK V2 Client A OK N réplicas V2 OK Client B V? V?

  35. Cohérence par Quorum Le client B lit L valeurs V2 V2 Client A N réplicas V2 Client B V? V? Si E + L > N la lecture est cohérente avec l’écriture

  36. Architecture décentralisée A,B,C W,X,Y,Z Client A D,E,F GOSSIP T,U,V G,H,I J,K,L P,Q,R,S Client B M,N,O

  37. Traiter les données Map-Reduce

  38. Map-Reduce • Technique de traitement des données de grandes tailles • Acteurs réputés: • Google • Hadoop • CouchDB • MongoDB Input Map Sort Reduce (C1V1) (K2V2) (K2[V2 V2’]) (K3V3) Traitement local Traitement global

  39. Repenser les bases de données Modèles de données

  40. Entités-relation Panier PAN_ID CLI_ID DATE MONTANT_TOTAL TVA Client CLI_ID NOM ADRESSE CLI_ID PAN_ID Article PAN_ID CMD_ID QUANTITE PRIX_UNITAIRE

  41. Entité-relation SQL NewSQL Bases entièrement en mémoire et réparties sur plusieurs nœuds avec réplication. VoltDB vFabricSQLFire (Vmware) (beta) • Oracle Database • SQL Server (Microsoft) • MySQL (Oracle) • IBM DB2 • PostgreSQL • MariaDB

  42. Clef-valeur

  43. Clef-valeur • Berkley DB (Oracle) • Cohérente • Maitre/esclave • Memcache • MemcacheDB = Memcache + BerkeleyDB • Membase (couchbase.org) • Erlang • Riak • Cohérent • Erlang • Redis (Vmware) • Cohérent • en mémoire ; écriture disque asynchrone • types évolués (liste et map) et opérations évoluées associées • Dynamo (Amazon) • Cohérent à terme • Utilisation indirecte avec les outils Amazon AWS • Voldemort (LinkedIn) • Cohérent à terme • Gigaspace • Infinityspan (RedHat, JBoss) • Hibernate OGM

  44. Bases de documents { "_id" : ObjectId("4c220a42f3924d31102bd866"), "cli_id" : ObjectId("4c220a42f3924d31102bd867"), "date" : "2011-07-19", "montant_total” : 123, "tva” : 20.16, "articles” : [ { “art_id” : ObjectId("4c220a42f3924d31102bd85b"), “qte” : 2, "pu” : 50 }, { “art_id” : ObjectId("4c220a42f3924d31102bd869"), "qte” : 1, "pu": 23 } ] } Collection de documents JSON

  45. Bases de documents

  46. Bases de documents • MongoDB • Cohérent • Bien documentée • Références • Foursquare • Bit.ly • Sourceforge • The New York Times • Github • Grooveshark • CouchDB(Apache) • Cohérent à terme • Erlang • Complexe • OrientDB • Java embarquable • Terrastore • Lotus Notes (IBM) • Cohérent à terme • RavenDB • .Net

  47. Bases orientées colonnes • Table clairsemée • La liste des colonnes peut changer d’une ligne à l’autre

  48. Bases orientées colonnes • Gère un très grand nombre de données • Ex: Cassandra • Max nombre colonnes : 2 000 000 000 • Max taille clef et du nom de colonne: 64 Kio • Max taille valeur d’une cellule : 2 Gio

  49. Bases orientées colonnes

  50. Bases orientées colonnes • Bigtable (Google) • Cohérent • Utilisable via Google App Engine • Basée sur Google File System • Simple DB (Amazon) • Cohérent à terme • Option de lecture cohérente • Utilisable comme service AWS • Hbase (Apache) • Cohérente • Base historique de Hadoop • Créée par Yahoo! • Open source • Cassandra (Apache) • Cohérent à terme • Niveau de cohérence réglable • Créée par Facebook • Grande communauté • En cours d’intégration avec la suite Hadoop • Open source