Télécharger pour lire hors ligne
Téléchargé parCédric Villa
Relational databases & NoSQL databases
Le document examine les différences entre les bases de données relationnelles et NoSQL, en détaillant leurs structures, avantages et inconvénients. Il s'intéresse notamment à la normalisation, aux schémas flexibles, et aux performances des systèmes, tout en évoquant des cas d'utilisation concrets et l'importance de choisir la bonne technologie pour des problèmes spécifiques. Enfin, il aborde les défis de scalabilité et le théorème CAP en systèmes distribué.
Contenu connexe
![[Breizhcamp 2015] MongoDB et Elastic, meilleurs ennemis ?](https://cdn.slidesharecdn.com/ss_thumbnails/mongodbetelasticmeilleursennemis-150612210744-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Relational databases & NoSQL databases
- 1. BASES DE DONNÉES RELATIONNELLES &NOSQL CédricVilla - @zestprod - 18/09/2015 DevelopR6 - CNRS
- 2.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. DOCUMENT BASED DATABASE Structure imbriquée Web 2.0JSON (REST) Ergonomie
- 14.
- 15. Structure imbriquée Pas derelations dans le SGBD Pas ACID DOCUMENT BASED DATABASE
- 16. Système de cache Construireet retourner un format adapté (ex. elastic search) Plus difficile à débogguer DOCUMENT BASED DATABASE
- 17.
- 18. SCHEMALESS + • Agilité(liberté lors du développement) • Productivité
- 19. SCHEMALESS - • Extractionde l’information • Métaphore du tiroir de bureau • Difficulté de migration
- 21. MODÈLES CLÉS /VALEURS Redis,(virtuellement n’importe quel NoSQL), etc. SET foo bar GET foo => bar
- 22. HYBRIDES Ex: Postgres etle type « hstore »
- 23. BDD CÔTÉ CLIENT HTML5- Web SQL Database + Web Storage
- 24.
- 25. DEVELOPPER AVEC UNEBDD • Abondance de doc, frameworks, etc. • Tous les langages
- 26.
- 27.
- 28. MAPPING OBJET • Onmanipule des objets • Object.create(attribute: « value », etc.) • Objet.find(name: « john ») • Les requêtes sont générées dans le language du SGDB
- 29. MAPPING OBJET • +Documentation: Dans le modèle • + On peut ignorer le SGDB derrière (différences entre développement et production)
- 30. MAPPING OBJET • NoSQL Idemque pour BDD relationnelles • Avantages • ++ Documentation: dans le modèle • + Encore moins de gestion de la BDD
- 31. MAPPING OBJET • Semblesimple • Ce n’est pas « fool-proof » • boucle for + modification en base
- 32.
- 33. PERFORMANCES • Dépendent: • Dela RAM • Des entrées/sorties du stockage (I/O) • Du CPU
- 34. AVANT D’ENVISAGER UN PLUSGROS SERVEUR • Mise en cache • D’une page complète (ou 304) • D’un fragment HTML • Du résultat d’une requête
- 35.
- 36. BDD RAPIDES • EnRAM • Pas d’écriture disque (systématique) • Cluster
- 37. BDD RAPIDES • Miseen cache • Données extraites • Fragments HTML • Sessions • Files d’attentes
- 38. BDD RAPIDES • Pasde persistence / ACID sinon: pas mieux que BDD relationnelle
- 39.
- 40.
- 41. VERTICAL SCALING 4 GoRAM 2 CPU 1 HDD 5400 RPM
- 42. VERTICAL SCALING 16 GoRAM 8 CPU 1 SSD (x100)
- 43. SI GOOGLE FAISAITÇA • Connait 30 trillions de documents • Crawle 20 milliards de pages / jour
- 45. RETOUR À LARÉALITÉ • 2 millions d’ordinateurs répartis • dans +60 data centers • sur le globe
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. MISE À L’ÉCHELLE Méthode(ex.) Technologie Mise en oeuvre Code Déploiement / Provisionning Puppet, Docker, etc. Trivial Stockage File System en réseau AWS-S3, NFS, etc. Trivial BDD ? ? ?
- 53. load balancer SQL: MASTER/ MASTER
- 54. load balancer Résultat ✓ Cohérence(ACID) ✓ Disponibilité • Limitation par I/O
- 55. load balancer Méthode adaptéepour • Garantir la disponibilité d’une base Pas adaptée pour • Scaling horizontal
- 56. THÉORÈME CAP • Dansun système distribué, impossible de garantir en même temps: • Cohérence (tous les clients partagent la même vue des données) • Disponibilité (lecture / écriture pour tous les clients) • Tolérance au partionnement (le système fonctionne malgré la séparation physique des données)
- 57.
- 58. load balancer Théorème deCAP ✓ Cohérence • Disponibilité ✓ Tolérance au partionnement
- 59. CAP - COMPROMIS (QUELQUESEXEMPLES) Availability (disponibilité) Consistency (cohérence) Partition Tolerance Data Models MySQL / Postgres oui oui - Relationnel MongoDB - oui oui Document Redis - oui oui Key-Value Cassandra oui - oui Orienté Colonne CouchDB oui - oui Document * utilisation du SGBD par défaut
- 60. BASE Basically Available Soft state Eventualconsistency
- 61. •Les données •sont temporaires etpas à jour •doivent être « réconciliée » •vont finir par être cohérentes
- 62.
- 63. QUELLE BDD UTILISER POUR MONAPPLICATION ?
- 64. PROBLEMES • Abondance desolutions • Contradictions • Buzz / Hype et évolutions
- 65. THE RIGHT TOOL FORTHE RIGHT JOB Lebon outil pour le bon usage.
- 66. CHOIX D’UNE BASEDE DONNÉE • Attention au « One size fits all » • 1 marteau = tous les problèmes sont des clous • Pas optimal • Arrachage de cheveux
- 67. DIVISER LE PROBLÈMEEN SOUS PROBLÈMES • Plusieurs technologies de BDD • ex: Redis + Postgres + MongoDB • Microservices / machines virtuelles • Chaque techno est adaptée à un sous-problème
- 68. CONNAITRE PLUSIEURS TECHNOLOGIES • Forces,faiblesses • Les essayer, se familiariser • Identifier un problème qui nécessite une BDD en particulier
- 69. SE POSER LESBONNES QUESTIONS • Ex pour Google • Est-ce que c’est ok d’afficher une donnée pas à jour ? • Est-ce que je dois réduire: • Le temps de crawling ? • Ou le temps de traitement des requêtes ?
- 70. EX: CRAIGSLIST (PETITES ANNONCES) •MySQL • Memcached • Redis • MongoDB • Sphinx • Filesystem
- 71. EX: CRAIGSLIST (PETITES ANNONCES) •SQL (MySQL) • Vertical (SSD) + RAM • Horizontal • Cache (consultation 99%)
- 72. EX: CRAIGSLIST (PETITES ANNONCES) •NoSQL (MongoDB) • Utilisé pour les archives • Schemaless • Scaling
- 73. • http://instagram-engineering.tumblr.com/post/40781627982/handling- growth-with-postgres-5-tips-from Scaling Postgres(Instagram) • https://muut.com/blog/technology/redis-as-primary-datastore-wtf.html Un mec qui a détourné Redis pour son forum • http://www.sarahmei.com/blog/2013/11/11/why-you-should-never- use-mongodb/ Titre « troll » mais très instructif (Diaspora, problèmes de MongoDB dans la vraie vie) • https://www.percona.com/live/mysql-conference-2012/sessions/living- sql-and-nosql-craigslist-pragmatic-approach Craigslist - Cohabitation de SQL et de NoSQL