Introduction aux bases noSQL

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. SQL Il était une fois

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. Not oNLY SQL Repenser les bases de données

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. Théorème CAP « You can have atmosttwo of theseproperties for anysharded-data system. » Eric A. Brewer— 19 juillet 2000

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. Nœud 1 Nœud 2 Version 1 Version 1 Client A Client B Théorème CAP — Démonstration par l’exemple

25. 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

26. 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

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

28. 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

29. 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 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 V1 V2 V1 Client A N réplicas V1 V1 Client B 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 V? Client B V?

35. Cohérence par Quorum Le client B lit L valeurs V2 V2 Client A N réplicas V2 V? Client B 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. Map-Reduce Traiter les données

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

39. Modèles de données Repenser les bases 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 Oracle Database SQL Server (Microsoft) MySQL (Oracle) IBM DB2 PostgreSQL MariaDB NewSQL Bases entièrement en mémoire et réparties sur plusieurs nœuds avec réplication. VoltDB vFabricSQLFire (Vmware) (beta)

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

51. Graphe Bases qui permettent d’étudier globalement les relations entre entités. Ex: Graph social

52. Graphe Neo4j GPL Très actif Bases RDF Jena (HP) Sesame (OpenRDF) Bigdata Langage de requête normé : SPARQL PrezFlash Web Sémantique Octobre 2011

53. Questions ? Retrouvez nous sur le blog technique de Klee http://blog.kleegroup.com/teknics teKnics@kleegroup.com @teKnics_Klee