NoSQL, également appelé « not only SQL » et « non-SQL », est une approche de la conception de bases de données qui permet le stockage et l'interrogation de données en dehors des structures traditionnelles des bases de données relationnelles. Bien qu'elle puisse toujours stocker des données trouvées dans les systèmes de gestion de bases de données relationnelles (RDBMS), elle les stocke simplement différemment d'un SGBDR. La décision d'utiliser une base de données relationnelle plutôt qu'une base de données non relationnelle est largement contextuelle et varie en fonction du cas d'utilisation.
Au lieu de la structure tabulaire typique d'une base de documents relationnelle, les base de données NoSQL hébergent les données dans une structure de données, telle qu'un document JSON. Comme cette conception de base de données non relationnelle ne nécessite pas de schéma, elle offre une évolutivité rapide pour gérer des ensembles de données volumineux et généralement non structurés.
NoSQL est également un type de base de données distribuée, ce qui signifie que les informations sont copiées et stockées sur différents serveurs, qui peuvent être distants ou locaux. Cela garantit la disponibilité et la fiabilité des données. Si certaines données sont hors ligne, le reste de la base de données peut continuer à s'exécuter.
Aujourd'hui, les entreprises doivent gérer de gros volumes de données à des vitesses élevées avec la possibilité d'évoluer rapidement pour exécuter des applications Web modernes dans presque tous les secteurs. A l'heure de la croissance du cloud, du big data et des applications mobiles et Web, les bases de données NoSQL offrent cette vitesse et cette évolutivité, ce qui en fait un choix populaire pour leurs performances et leur facilité d'utilisation.
Le langage SQL (Structured Query Language) est souvent mentionné en relation avec NoSQL. Pour mieux comprendre la différence entre NoSQL et SQL, il peut être utile de comprendre l'histoire de SQL, un langage de programmation utilisé pour récupérer des informations spécifiques dans une base de données.
Avant les bases de données relationnelles, les entreprises utilisaient un système de base de données hiérarchique avec une structure en arborescence pour les tables de données. Ces premiers systèmes de gestion de bases de données (DBMS) permettaient aux utilisateurs d'organiser de grandes quantités de données. Cependant, ils étaient complexes, souvent propriétaires d'une application particulière, et limités dans les moyens qu'ils pouvaient utiliser pour découvrir les données. Ces limites ont finalement conduit au développement de systèmes de gestion de bases de données relationnelles, qui organisent les données dans des tableaux. SQL a fourni une interface pour interagir avec les données relationnelles, permettant aux analystes de connecter des tables en procédant à des fusions sur des zones communes.
Au fil du temps, les demandes d'utilisation plus rapide et plus disparate de grands ensembles de données sont devenues de plus en plus importantes pour les technologies émergentes, telles que les applications d'e-commerce. Les programmeurs avaient besoin de quelque chose de plus flexible que les bases de données SQL (c'est-à-dire les bases de données relationnelles). NoSQL est devenu cette alternative.
Mais si NoSQL a fourni une alternative à SQL, cette avancée n'a en aucun cas remplacé les bases de données SQL. Par exemple, imaginons que vous gérez des commandes au détail dans une entreprise. Dans un modèle relationnel, les tables individuelles gèrent séparément les données relatives aux clients, aux commandes et aux produits. Elles sont reliées entre elles par une clé unique et commune, telle que l'ID client ou l'ID commande. Bien que cela soit idéal pour stocker et récupérer rapidement des données, cela nécessite une mémoire importante. Lorsque vous souhaitez ajouter de la mémoire, les bases de données SQL ne peuvent évoluer que verticalement, et non horizontalement, ce qui signifie que votre capacité à ajouter de la mémoire est limitée au matériel dont vous disposez. De ce fait, la mise à l'échelle verticale limite finalement le stockage et la récupération des données de votre entreprise.
En comparaison, les bases de données NoSQL sont non relationnelles, ce qui élimine le besoin de connecter des tables.Leurs fonctionnalités intégrées de partitionnement et de haute disponibilité facilitent la mise à l'échelle horizontale. Si un serveur de base de données n'est pas suffisant pour stocker toutes vos données ou gérer toutes les requêtes, la charge de travail peut être répartie sur deux serveurs ou plus, ce qui permet aux entreprises de faire évoluer leurs données horizontalement.
Si chaque type de base de données a ses propres avantages, les entreprises utilisent généralement à la fois les bases de données NoSQL et les bases de données relationnelles dans une même application. Les fournisseurs de cloud actuels peuvent prendre en charge les bases de données SQL ou NoSQL. Le choix de la base de données dépend de vos objectifs.
Pour en savoir plus sur les différences entre les deux options, voir « Bases de données SQL et NoSQL : quelles différences ? »
NoSQL propose d'autres options pour organiser les données de plusieurs façons. En offrant diverses structures de données, NoSQL peut être appliqué à l'analyse des données, à la gestion du big data, aux réseaux sociaux et au développement d'applications mobiles.
Une base de données NoSQL gère les informations en utilisant l'un des principaux modèles de données suivants :
Ce modèle est généralement considéré comme la forme la plus simple des bases de données NoSQL. Ce modèle de données sans schéma est organisé en un dictionnaire de paires clé-valeur, dans lequel chaque élément possède une clé et une valeur. La clé peut ressembler à quelque chose de similaire dans une base de données SQL, comme un identifiant de panier, tandis que la valeur est un tableau de données, comme chaque article individuel dans le panier de cet utilisateur. Elle est généralement utilisée pour la mise en cache et le stockage des informations de session utilisateur, comme les paniers d'achat. Cependant, ce n'est pas idéal lorsque vous devez extraire plusieurs enregistrements à la fois. Redis et Memcached sont des exemples de bases de données clé-valeur open source.
Comme son nom l'indique, la base de données de documents stocke les données sous forme de documents. Elles peuvent être utiles pour gérer des données semi-structurées, et les données sont généralement stockées au format JSON, XML ou BSON. Cela permet de conserver les données ensemble lorsqu'elles sont utilisées dans des applications, ce qui réduit la quantité de traduction nécessaire pour utiliser les données. Les développeurs gagnent également en flexibilité car les schémas de données ne doivent pas nécessairement correspondre d'un document à l'autre (par exemple, nom ou prénom). Cependant, cela peut être problématique pour les transactions complexes et entraîner une altération des données. Les cas d'utilisation les plus courants des bases de données de documents incluent les systèmes de gestion de contenu et les profils utilisateur. MongoDB, le composant de base de données de la pile MEAN, est un exemple de base de données de documents.
Vous souhaitez en savoir plus sur MongoBD ? Consultez le tutoriel IBM sur la mise en route d'IBM Cloud Databases for MongoDB.
Ces bases de données stockent les informations en colonnes, ce qui permet aux utilisateurs d'accéder uniquement aux colonnes spécifiques dont ils ont besoin sans allouer de mémoire supplémentaire à des données non pertinentes. Cette base de données tente de résoudre les lacunes des magasins clé-valeur et de documents, mais comme il peut s'agir d'un système plus complexe à gérer, il n'est pas recommandé de l'utiliser pour les équipes et les projets plus récents. Apache HBase et Apache Cassandra sont des exemples de bases de données open source à colonnes larges. Apache HBase est construit sur Hadoop Distributed Files System, qui fournit un moyen de stocker des ensembles de données éparses et est couramment utilisé dans de nombreuses applications de big data. Apache Cassandra, quant à lui, a été conçu pour gérer de grandes quantités de données sur plusieurs serveurs et des clusters qui s'étendent sur plusieurs centres de données. Il a été utilisé pour divers cas d'utilisation, tels que les sites Web de réseaux sociaux et l'analyse de données en temps réel.
Ce type de base de données héberge généralement les données d'un graphique de connaissances. Les éléments de données sont stockés sous forme de nœuds, d'arêtes et de propriétés. Tout objet, lieu ou personne peut être un nœud. Une arête définit la relation entre les nœuds. Par exemple, un nœud peut être un client, comme IBM, et une agence comme Ogilvy. Une arête permet de classer la relation comme une relation client entre IBM et Ogilvy.
Les bases de données de graphiques sont utilisées pour stocker et gérer un réseau de connexions entre les éléments du graphique. Neo4j (lien externe à IBM), un service de base de données de graphiques basé sur Java avec une édition communautaire open source dans laquelle les utilisateurs peuvent acheter des licences pour la sauvegarde en ligne et les extensions de haute disponibilité, ou une version sous licence pré-conditionnée avec copie de sauvegarde et extensions incluses.
Avec ce type de base de données, comme IBM solidDB, les données résident dans la mémoire principale plutôt que sur le disque, ce qui rend l'accès aux données plus rapide qu'avec les bases de données traditionnelles sur disque.
De nombreuses entreprises ont fait leur entrée dans le paysage NoSQL. En plus de celles mentionnées ci-dessus, voici quelques bases de données NoSQL populaires :
Pour en savoir plus sur l'état des bases de données, voir « Un bref aperçu du paysage des bases de données ».
Chaque type de base de données NoSQL possède des atouts qui le rendent meilleur pour des cas d'utilisation spécifiques. Cependant, ces types partagent tous les avantages suivants pour les développeurs et créent le cadre pour fournir un meilleur service aux clients, notamment :
En un mot, les bases de données NoSQL offrent des performances, une disponibilité et une évolutivité élevées.
La structure et le type de base de données NoSQL que vous choisissez dépendent de la manière dont votre organisation prévoit de l'utiliser. Voici quelques utilisations spécifiques pour divers types de bases de données NoSQL.
La nécessité pour les grandes entreprises de fournir des services sans latence et d'évoluer plus rapidement a stimulé la croissance des microservices, ce qui a conduit les entreprises à examiner quel type de base de données utiliser pour les différentes applications.
Les entreprises ont constaté que l'utilisation d'une seule base de données relationnelle pour chaque composant d'une application avait ses limites, en particulier lorsqu'il existe de meilleures solutions pour des composants spécifiques. Les microservices sont une option attrayante, en partie parce qu'ils éliminent le besoin d'un seul magasin de données partagé pour l'ensemble d'une application. Au lieu de cela, l'application comporte de nombreux services, faiblement couplés et pouvant être déployés indépendamment, chacun avec son propre modèle de données et sa propre base de données, et intégré via des passerelles d'API ou un iPaaS.
L'utilisation de plusieurs bases de données au sein d'une même application, également connue sous le nom de persistance polyglotte, a contribué à créer un espace sur le marché pour que les bases de données NoSQL puissent prospérer. Aujourd'hui, les développeurs peuvent exploiter la bonne base de données pour le bon microservice sans avoir à essayer de tout faire fonctionner dans le contexte d'une base de données relationnelle unique.
Explorez les différents facteurs à prendre en compte tout en essayant de déterminer les meilleures options de base de données lors de la restructuration vers une approche de microservices.
Découvrez les microservices (ou architecture de microservices), une approche architecturale cloud native dans laquelle une application unique est composée de nombreux petits composants, ou services, liés de façon souple et pouvant être déployés de manière indépendante.