Le document traite des bases de données NoSQL et de leurs alternatives aux systèmes relationnels traditionnels SQL. Il met en lumière des concepts fondamentaux comme le théorème CAP, les performances, et les architectures décentralisées, ainsi que des exemples de différentes types de bases NoSQL comme les bases de documents et orientées colonnes. Enfin, il présente des techniques de traitement de données telles que MapReduce et discute des défis liés à la cohérence et à la montée en charge des systèmes de données modernes.

1. PrezFlash :: NoSQLJérôme Mainaud19 juillet201111

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

3. SQLIl était une fois

4. Modèle de données relationnelPanierPAN_IDCLI_IDDATEMONTANT_TOTALTVAClientCLI_IDNOMADRESSECLI_IDPAN_IDArticlePAN_IDCMD_IDQUANTITEPRIX_UNITAIRE

5. SQLUn langage de requête plus ou moins norméTout information est décrite par des listes de n-upletsOpérations puissanteSélection (where)Projection (select)Produit cartésien (join)UnionIntersectionDifférence

6. Transactions ACID

7. Marché matureUtilisé depuis des dizaines d’annéesDe nombreux fournisseurs et de nombreux outilsOracleSQL ServerMysqlPostgresqlMariaDB (clone de Mysql)MS Access

8. Bases de données relationnellesUtilisémais paschoisi

9. Mise en œuvre d’un SGBD-RBase de donnéesServeur ApplicatifHTTPJDBC

10. Mise en œuvre d’un SGBD-RServeurs ApplicatifsBase de donnéesJDBCHTTP

11. Mise en œuvre d’un SGBD-RBase de donnéesServeurs ApplicatifsHTTPJDBC

12. Mise en œuvre d’un SGBD-RServeurs ApplicatifsBase de donnéesJDBCHTTP

13. Montée en charge difficileLes règles d’intégrité compliquent la montée horizontaleMontée en charge verticaleCoût non linéaireAtteint une limitePoint unique de défaillance

14. Coût des transactions ACIDLa lecture est éparpilléeLecture d’un panier de N articles2 requêtes2 IO pour lire le panierN+1 IO pour les articlesL’écriture est lenteIO synchronisésLa durée d’une requête est difficile à prévoirSelect * 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 CRUDUtilisation de caches MemcacheEhcacheCorrespondance ORM C’est le modèle objet qui est privilégié

16. Not oNLY SQLRepenser les bases de données

17. Montée en charge linéaireDeux critèresVolume des donnéesNombre de requêtesTwitterJanvier 2010 : 50 M/jJuin 2011 : 200 M/jLe coût doit augmenter linéairement

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

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

20. Prise en compte des pannesLa panne est la règleAmazon: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 nombreusesMatériel serveur (disque)Matériel réseauAlimentation électriqueAnomalies logiciellesMises à 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 CAPBases distribuéesVerrous distribuésVerrou pessimisteLa partition minoritaire est indisponibleOracle RACLDAPCommit à 2 phasesCache validationDNSCache WebExpirationRésolution de conflitVerrou optimiste

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

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

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

27. Nœud 1Nœud 2Version 2Version 2Client AClient BThéorème CAP — Démonstration par l’exempleLit version 2

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

29. Nœud 1Nœud 2Version 2Version 1Client AClient BMAJ 1  2Théorème CAP — Démonstration par l’exemplePerte du message

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

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

32. Cohérence à termeContinuum

33. Cohérence par QuorumV1V2V1Client AN réplicasV1V1Client BV1

34. Cohérence par QuorumLe client attend E OK pour valider l’écritureV2OKV2Client AOKN réplicasV2OKV?Client BV?

35. Cohérence par QuorumLe client B lit L valeursV2V2Client AN réplicasV2V?Client BV?Si E + L > N la lecture est cohérente avec l’écriture

36. Architecture décentraliséeA,B,CW,X,Y,ZClient AD,E,FGOSSIPT,U,VG,H,IJ,K,LP,Q,R,SClient BM,N,O

37. Map-ReduceTraiter les données

38. Map-ReduceTechnique de traitement des données de grandes taillesActeurs réputés:GoogleHadoopCouchDBMongoDBMapInputSortReduce(C1V1)(K2V2)(K2[V2 V2’])(K3V3)Traitement localTraitement global

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

40. Entités-relationPanierPAN_IDCLI_IDDATEMONTANT_TOTALTVAClientCLI_IDNOMADRESSECLI_IDPAN_IDArticlePAN_IDCMD_IDQUANTITEPRIX_UNITAIRE

41. Entité-relationSQLOracle DatabaseSQL Server (Microsoft)MySQL (Oracle)IBM DB2PostgreSQLMariaDBNewSQLBases entièrement en mémoire et réparties sur plusieurs nœuds avec réplication.VoltDBvFabricSQLFire (Vmware) (beta)

42. Clef-valeur

43. Clef-valeurBerkley DB (Oracle)CohérenteMaitre/esclaveMemcacheMemcacheDB = Memcache + BerkeleyDBMembase (couchbase.org)ErlangRiakCohérentErlangRedis (Vmware)Cohérenten mémoire ; écriture disque asynchronetypes évolués (liste et map) et opérations évoluées associéesDynamo (Amazon)Cohérent à termeUtilisation indirecte avec les outils Amazon AWSVoldemort (LinkedIn)Cohérent à termeGigaspaceInfinityspan (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 documentsMongoDBCohérentBien documentéeRéférencesFoursquareBit.lySourceforgeThe New York TimesGithubGroovesharkCouchDB(Apache)Cohérent à termeErlangComplexeOrientDBJava embarquableTerrastoreLotus Notes (IBM)Cohérent à termeRavenDB.Net

47. Bases orientées colonnesTable clairseméeLa liste des colonnes peut changer d’une ligne à l’autre

48. Bases orientées colonnesGère un très grand nombre de donnéesEx: CassandraMax nombre colonnes : 2 000 000 000Max taille clef et du nom de colonne: 64 KioMax taille valeur d’une cellule : 2 Gio

49. Bases orientées colonnes

50. Bases orientées colonnesBigtable (Google)CohérentUtilisable via Google App EngineBasée sur Google File SystemSimple DB (Amazon)Cohérent à termeOption de lecture cohérenteUtilisable comme service AWSHbase (Apache)CohérenteBase historique de HadoopCréée par Yahoo!Open sourceCassandra (Apache)Cohérent à termeNiveau de cohérence réglableCréée par FacebookGrande communautéEn cours d’intégration avec la suite HadoopOpen source

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

52. GrapheNeo4jGPLTrès actifBases RDFJena (HP)Sesame (OpenRDF)BigdataLangage de requête normé : SPARQLPrezFlashWeb SémantiqueOctobre 2011

53. Questions ?Retrouvez nous sur le blog technique de Kleehttp://blog.kleegroup.com/teknicsteKnics@kleegroup.com@teKnics_Klee