Tout savoir sur les bases de données NoSQL

Qu’est-ce que le NoSQL ?

 

Le NoSQL englobe une grande variété de technologies de base de données, développées afin de répondre aux exigences des applications de nouvelle génération :

  • Les développeurs travaillent sur des applications qui produisent d’énormes volumes de données d’un nouveau genre — données structurées, semi-structurées, non-structurées et polymorphes.
  • Il est loin le temps des cycles de développement en cascade, avec des mises à jour tous les 12 à 18 mois. Aujourd’hui, de petites équipes travaillent en sprints agiles. Elles itèrent et poussent rapidement le code toutes les semaines ou quinzaines, voire plusieurs fois par jour.
  • Les applications qui servaient autrefois à un groupe d’utilisateurs se voient désormais proposées sous forme de service (SaaS) à des millions d’utilisateurs du monde entier.
  • Organizations are now turning to scale-out architectures using open software technologies, commodity servers and cloud computing instead of large monolithic servers and storage infrastructure.

Or, les bases de données relationnelles n’ont pas été conçues pour faire face aux problématiques d’échelle et d’agilité des applications de nouvelle génération. En outre, elles sont bien incapables d’exploiter les modèles de stockage et de traitement à la demande que l’on rencontre d’aujourd’hui.

 

Déployez un cluster NoSQL en quelques minutes seulement avec MongoDB Atlas, la plateforme Database-as-a-Service hébergée dans le cloud

 

Testez le moyen le plus simple de découvrir MongoDB et de créer des prototypes d’applications basées sur la base de données relationnelle leader du marché.

En règle générale, le lancement d’une application adossée à une base de données nécessite une planification minutieuse afin de garantir performances, disponibilité, sécurité et reprise d’activité – et cette nécessité perdure tant que l’application reste en production. C’est pourquoi MongoDB Atlas vous fournit toutes les fonctionnalités de MongoDB, les lourdeurs opérationnelles en moins.

Ainsi, vous pouvez vous recentrer sur le développement de vos compétences et de vos applications. Au menu de la plateforme :

  • Modèle de facturation à l’utilisation
  • Montées de version fluides et réparation automatique
  • Élasticité maximale, pour des montées et des baisses de charge en toute transparence
  • Monitoring approfondi et alertes personnalisables
  • Sécurité renforcée par défaut
  • Sauvegarde continue et restauration PITR des données

 

Types de Bases de Données NoSQL

 

  • Les bases de données orientées document associent chaque clé à une structure de données complexe, baptisée « document ». Les documents peuvent contenir de nombreuses paires clé/valeur ou clé/tableau différentes, voire des documents imbriqués.
  • Les bases de données de graphe servent à stocker les informations de réseaux de données (réseaux sociaux, par exemple). Parmi elles figurent Neo4J et Giraph.
  • Les bases de données clé/valeur représentent le modèle le plus simple de BDD NoSQL. Chaque élément de la base est stocké sous la forme d’un nom d’attribut (la clé), associé à sa valeur. Parmi elles, on trouve Riak et Berkeley DB. Pour gagner en fonctionnalité, certaines bases de données clé/valeur comme Redis permettent à chaque valeur d’avoir un type (intégral, par exemple).
  • Les bases de données orientées colonnes sont optimisées pour les requêtes sur de grands ensembles de données, à l’image de Cassandra et HBase. Elles stockent ces données en colonnes plutôt qu’en lignes.

 

Avantages du NoSQL

 

Par rapport aux bases de données relationnelles, les BDD NoSQL affichent une scalabilité et des performances bien supérieures. Leur modèle de données résout par ailleurs des problématiques auxquelles l’architecture relationnelle est bien incapable de répondre :

  • Volumes importants de données structurées, semi-structurées et non-structurées en constante mutation
  • Sprints agiles, itération de schéma rapide et intégrations fréquentes de nouveau code
  • Programmation orientée objet d’une grande flexibilité et simplicité d’utilisation
  • Architectures à scalabilité horizontale reparties géographiquement sur de nombreux sites, en lieu et place des architectures monolithiques coûteuses

 

Découvrez les 5 grands critères d’évaluation des bases de données NoSQL.

Au sommaire du livre blanc gratuit :

  • Sélection du bon modèle de données : document, clé/valeur, colonne ou graphe
  • Avantages et inconvénients des systèmes cohérents et cohérents à terme
  • Atouts des pilotes idiomatiques pour accélérer la prise en main par les développeurs et le développement d’applications

 

Schémas dynamiques

 

Les bases de données relationnelles nécessitent d’abord de définir des schémas avant d’y ajouter des données. Par exemple, si vous souhaitez stocker des données clients (noms, prénoms, adresses, numéros de téléphone, etc.), vous devrez indiquer à l’avance à votre base SQL quelles données vous comptez stocker.

Cette exigence convient mal aux approches de développement agile car à chaque nouvelle fonctionnalité sur une application, vous devez presque systématiquement modifier le schéma de votre base de données. Par conséquent, au bout de quelques itérations, si vous décidez de stocker les articles favoris de vos clients en plus de leur adresse et numéro de téléphone, vous devrez ajouter cette colonne à votre base de données, puis la migrer intégralement vers le nouveau schéma.

Lorsqu’il s’agit d’une très grande base de données, ce processus prend énormément de temps et peut occasionner des interruptions de service très longues. Plus vous itérez rapidement vos applications, plus vous changerez fréquemment les données stockées dans votre application, et plus ces interruptions seront fréquentes. En outre, les bases de données relationnelles n’ont aucun moyen de traiter efficacement les données non-structurées ou inconnues à l’avance.

A contrario, les bases de données NoSQL sont spécialement conçues pour permettre l’insertion de données sans schéma prédéfini. Ainsi, elles facilitent les modifications importantes en temps réel sur les applications, sans interruption de service, avec à la clé un développement plus rapide, une intégration de code plus fiable et un allègement de la charge de travail des DBA. Jusqu’ici, pour appliquer des contrôles de qualité des données (présence de champs spécifiques, de types de données, de valeurs admissibles, etc.), les développeurs devaient ajouter du code côté application. Désormais, les bases de données NoSQL les plus avancées permettent d’appliquer des règles de validation au sein même de la BDD. On peut ainsi étendre cette gouvernance à toutes les données, tout en conservant l’agilité caractéristique des schémas dynamiques.

 

Auto-sharding

 

Du fait de leur structure, les bases de données relationnelles reposent généralement sur la scalabilité verticale d’un seul serveur – ce serveur doit héberger toute la base de données afin de garantir les performances des transactions et des jointures sur deux tables (CROSS JOIN). Le problème de cette approche est qu’elle devient vite coûteuse, qu’elle limite la scalabilité et crée un petit nombre de points de défaillance pour l’infrastructure de base de données. La scalabilité horizontale se prête donc davantage à des applications à forte croissance. Sa grande différence est qu’au lieu d’ajouter des capacités sur un seul serveur, elle ajoute tout simplement des serveurs.

 

Le « sharding » d’une base de données SQL sur plusieurs instances de serveurs est techniquement faisable. Toutefois, il repose généralement sur un SAN et d’autres dispositifs complexes visant à faire agir différents équipements comme un seul serveur. Parce que la base de données n’offre pas cette possibilité en natif, les équipes de développement entreprennent alors de déployer de multiples bases de données relationnelles à travers plusieurs machines. Les données sont alors stockées dans chaque base de façon autonome. Les applications sont codées de façon à distribuer les données et les requêtes en conséquence, puis à agréger les résultats à travers toutes les instances de la base de données. À cela s’ajoutent des lignes de code pour gérer d’éventuelles défaillances de ressources, effectuer des jointures entre les différentes bases de données, rééquilibrer et répliquer les données, etc. Au final, le sharding manuel finit même par compromettre, voire éliminer de nombreux avantages des bases de données relationnelles, comme l’intégrité transactionnelle.

 

Sur les bases de données NoSQL, le sharding s’opère généralement de façon automatique. En d’autres termes, les bases répartissent les données nativement et automatiquement à travers un nombre arbitraire de serveurs, sans que l’application n’ait à connaître la composition de ce pool. L’équilibrage des données et des requêtes s’effectuent automatiquement. En cas de panne d’un serveur, ce dernier peut être remplacé automatiquement et en toute transparence, sans perturbation pour l’application.

 

Le cloud computing facilite grandement ce processus, à l’image de fournisseurs comme Amazon Web Prestations de Service qui proposent des capacités quasi-illimitées à la demande et s’occupent de toutes les tâches d’administration de l’infrastructure. Grâce au cloud, les développeurs n’ont plus besoin de créer des plateformes complexes et coûteuses pour sous-tendre leurs applications. Ils ont ainsi les mains libres pour se concentrer sur le code, rien que le code. Pour une fraction du prix, des serveurs standard peuvent fournir les mêmes capacités de traitement et de stockage qu’un seul serveur haut de gamme.

 

Réplication

 

La plupart des bases de données NoSQL opèrent également une réplication automatique pour assurer leur disponibilité en cas de panne ou de maintenance non planifiée. Les plus avancées d’entre elles sont même auto-réparatrices, c’est-à-dire qu’elles opèrent un basculement et une restauration automatiques. Elles sont même capables de distribuer elles-mêmes les données à travers de multiples zones géographiques afin de résister à d’éventuelles pannes régionales et de respecter les obligations en termes de localisation des données. Contrairement aux bases de données relationnelles, les BDD NoSQL n’imposent généralement aucune application ni aucun module complémentaire coûteux pour effectuer la réplication.

 

Mise en Cache Intégrée

 

Un certain nombre de produits ont été conçus pour mettre en cache des données sur les systèmes de base de données SQL. Or, s’ils accélèrent grandement les performances en lecture, ils n’ont aucun effet sur les écritures. Sans compter qu’ils compliquent encore un peu plus la tâche des équipes opérationnelles. En somme, si votre application exécute principalement des opérations de lecture, un cache distribué peut avoir son utilité. Mais si votre application opère ne serait-ce qu’un nombre modeste d’écritures, un tel dispositif ne pourra pas améliorer l’expérience globale de vos utilisateurs. En clair, il ajoutera de la complexité pour rien.

De nombreuses bases de données NoSQL intègrent d’excellentes capacités de mise en cache. Elles permettent ainsi de conserver autant que possible les données fréquemment utilisées dans la mémoire système, ce qui élimine le besoin d’un cache séparé. Certaines sont même équipées d’un système intégré de gestion des bases de données en mémoire pour les charges exigeants de très hauts débits et de très faibles latences.

 

Tableau de Synthèse : SQL vs. NoSQL

 

Bases de Données SQL Bases de Données NoSQL
Types Un type (base de données SQL) avec des variations mineures De nombreux types : clé/valeur, Les bases de données orientées document, colonne, graphe, etc
Historique Développée dans les années 70 pour faire face à la première vague d’applications de stockage de données Développée à la fin des années 2000 pour résoudre les lacunes des bases de données SQL, en particulier pour répondre aux impératifs de scalabilité, de gestion de données multi-structurées, de géo-distribution et de sprints de développement agiles
Exemples MySQL, Postgres, Microsoft SQL Server, Oracle Database MongoDB, Cassandra, HBase, Neo4j
Modèle de stockage des données Chaque enregistrement (par ex., un « employé ») est stocké sur une ligne de table, chaque colonne contenant des données spécifiques à cet enregistrement (par ex., « fonction », « date d’embauche », etc.), comme dans un tableur. Les données associées sont alors stockées dans des tables distinctes, puis jointes pour l’exécution de requêtes plus complexes. Par exemple, les « bureaux » pourront se trouver dans une table et les « employés » dans une autre. Lorsqu’un utilisateur recherche l’adresse professionnelle d’un employé, le moteur de la base de données joint les tables « employés » et « bureaux » pour obtenir toutes les informations nécessaires Le modèle varie en fonction du type de base de données. Par exemple, le fonctionnement des bases clé/valeur se rapproche de celui des bases de données SQL, à la différence près qu’elles n’ont que deux colonnes (« clé » et « valeur »), les informations plus complexes étant stockées sous forme de BLOB dans les colonnes « valeur » le cas échéant. Les bases de données orientées document s’affranchissent entièrement du modèle à tables et lignes. Elles stockent ensemble toutes les données associées dans un seul et même « document » (au format JSON, XML ou autre) qui peut imbriquer les valeurs de façon hiérarchique.
Schémas La structure et les types de données doivent être définis à l’avance. Pour stocker des informations sur un nouvel élément de données, vous devez mettre toute la base de données hors service afin de la modifier. Généralement dynamiques, certains schémas appliquent des règles de validation des données. Les applications peuvent ajouter de nouveaux champs à la volée et, contrairement aux lignes de tables SQL, il est possible de stocker ensemble des données de différente nature. Pour certaines bases de données (par ex., orientées colonne), il est un peu plus difficile d’ajouter de nouveaux champs en dynamique.
Scalabilité Scalabilité verticale : on augmente les capacités d’un seul et même serveur afin de répondre à la croissance de la demande. Il est possible de répartir des bases de données SQL entre plusieurs serveurs, mais cela requiert généralement un effort technique considérable. Les BDD risquent également de perdre leurs fonctionnalités relationnelles (jointures, intégrité référentielle, transactions, etc.). Scalabilité horizontale : pour monter en capacités, un DBA peut simplement ajouter des serveurs standard ou des instances cloud. La base de données répartit automatiquement les données entre les serveurs selon les besoins.
Modèle de développement Mix of open technologies (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database) Open technologies
Prend en charge les transactions ACID multi-enregistrement Oui. En général non. MongoDB 4.0 et au-delà prennent en charge les transactions ACID multi-documents. Pour en savoir plus →
Manipulation de données Langage spécifique utilisant les instructions SELECT, INSERT et UPDATE. Par ex., SELECT champs FROM table WHERE& Via des API orientées objet
Cohérence Cohérence forte configurable En fonction du produit. Certains offrent une cohérence forte (par ex., MongoDB, avec cohérence ajustable pour les lectures), tandis que d’autres proposent une cohérence à terme (par ex., Cassandra).

Implémentation d’une Base de Données NoSQL

 

Montée en charge ou gains de performance, recherche d’alternatives viables à vos logiciels propriétaires coûteux, développement agile… il existe de nombreuses raisons de remplacer une infrastructure d’ancienne génération. Au moment de choisir votre base de données, n’oubliez pas d’étudier cinq grands critères.

MongoDB.com

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *