590 likes | 806 Views
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
E N D
PrezFlash :: NoSQL Jérôme Mainaud 19 juillet2011 1 1
« NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. » Emmanuel Bernard — 2011
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
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
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
Bases de données relationnelles Utilisé mais pas choisi
Mise en œuvre d’un SGBD-R Base de données Serveur Applicatif HTTP JDBC
Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données JDBC HTTP
Mise en œuvre d’un SGBD-R Base de données Serveurs Applicatifs HTTP JDBC
Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données JDBC HTTP
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
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)
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é
Repenser les bases de données Not oNLY SQL
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
Performances — temps d’accès Il est plus rapide d’interroger une autre machine que de lire sur le disque local
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
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.
« You can have atmosttwo of theseproperties for anysharded-data system. » Eric A. Brewer— 19 juillet 2000 Théorème CAP
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
Théorème CAP — Démonstration par l’exemple Nœud 1 Nœud 2 Version 1 Version 1 Client A Client B
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
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
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
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
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
Le choix d’Amazon Lors qu’un client clique sur le bouton « acheter » Faut-il ?
Cohérence à terme Continuum
Cohérence par Quorum V2 V1 V1 Client A N réplicas V1 Client B V1 V1
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?
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
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
Traiter les données Map-Reduce
Map-Reduce • Technique de traitement des données de grandes tailles • Acteurs réputés: • Google • Hadoop • CouchDB • MongoDB Input Map Sort Reduce (C1V1) (K2V2) (K2[V2 V2’]) (K3V3) Traitement local Traitement global
Repenser les bases de données Modèles de données
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
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
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
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
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
Bases orientées colonnes • Table clairsemée • La liste des colonnes peut changer d’une ligne à l’autre
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
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