Je vois beaucoup de confusion sur la place et le but des nombreuses nouvelles solutions de bases de données (« bases de données NoSQL ») par rapport aux solutions de bases de données relationnelles qui existent depuis de nombreuses années. Laissez-moi donc essayer d’expliquer les différences et les meilleurs cas d’utilisation pour chacune d’entre elles.
D’abord, clarifions ces solutions de bases de données en deux groupes :
1) Les bases de données relationnelles, qui peuvent également être appelées systèmes de gestion de bases de données relationnelles (SGBDR) ou bases de données SQL. Les plus populaires d’entre elles sont Microsoft SQL Server, Oracle Database, MySQL et IBM DB2. Ces SGBDR sont surtout utilisés dans des scénarios de grandes entreprises, à l’exception de MySQL, qui est surtout utilisé pour stocker des données pour des applications web, généralement dans le cadre de la populaire pile LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) Les bases de données non relationnelles, également appelées bases de données NoSQL, les plus populaires étant MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis et Neo4j. Ces bases de données sont généralement regroupées en quatre catégories : Key-value stores, Graph stores, Column stores, et Document stores (voir Types de bases de données NoSQL).
Toutes les bases de données relationnelles peuvent être utilisées pour gérer des applications orientées transaction (OLTP), et la plupart des bases de données non relationnelles qui sont dans les catégories Document stores et Column stores peuvent également être utilisées pour OLTP, ce qui ajoute à la confusion. Les bases de données OLTP peuvent être considérées comme des bases de données « opérationnelles », caractérisées par des transactions fréquentes et courtes qui incluent des mises à jour et qui touchent une petite quantité de données et où la concurrence de milliers de transactions est très importante (exemples : applications bancaires et réservations en ligne). L’intégrité des données étant très importante, elles prennent en charge les transactions ACID (Atomicité, Cohérence, Isolation, Durabilité). Ceci s’oppose aux entrepôts de données, qui sont considérés comme des bases de données « analytiques » caractérisées par des requêtes longues et complexes qui touchent une grande quantité de données et nécessitent beaucoup de ressources. Les mises à jour sont peu fréquentes. Un exemple est l’analyse des ventes au cours de la dernière année.
Les bases de données relationnelles travaillent généralement avec des données structurées, tandis que les bases de données non relationnelles travaillent généralement avec des données semi-structurées (c’est-à-dire XML, JSON).
Regardons chaque groupe plus en détail :
Bases de données relationnelles
Une base de données relationnelle est organisée sur la base du modèle relationnel des données, tel que proposé par E.F. Codd en 1970. Ce modèle organise les données en une ou plusieurs tables (ou « relations ») de lignes et de colonnes, avec une clé unique pour chaque ligne. En général, chaque type d’entité décrit dans une base de données possède sa propre table, dont les lignes représentent les instances de ce type d’entité et les colonnes les valeurs attribuées à cette instance. Étant donné que chaque ligne d’une table possède sa propre clé unique, les lignes d’une table peuvent être liées à des lignes d’autres tables en stockant la clé unique de la ligne à laquelle elle doit être liée (cette clé unique étant appelée « clé étrangère »). Codd a montré que des relations de données d’une complexité arbitraire peuvent être représentées en utilisant cet ensemble simple de concepts.
Presque tous les systèmes de bases de données relationnelles utilisent SQL (Structured Query Language) comme langage d’interrogation et de maintenance de la base de données.
Les raisons de la domination des bases de données relationnelles sont : la simplicité, la robustesse, la flexibilité, la performance, l’évolutivité et la compatibilité dans la gestion des données génériques.
Mais pour offrir tout cela, les bases de données relationnelles doivent être incroyablement complexes en interne. Par exemple, une instruction SELECT relativement simple pourrait avoir des dizaines de chemins d’exécution de requête potentiels, qu’un optimiseur de requête évaluerait au moment de l’exécution. Tout cela est caché aux utilisateurs, mais sous le capot, le SGBDR détermine le meilleur « plan d’exécution » pour répondre aux requêtes en utilisant des choses comme des algorithmes basés sur les coûts.
Pour les grandes bases de données, en particulier celles utilisées pour les applications web, la principale préoccupation est l’évolutivité. Comme de plus en plus d’applications sont créées dans des environnements qui ont des charges de travail massives (c’est-à-dire Amazon), leurs exigences d’évolutivité peuvent changer très rapidement et devenir très grandes. Les bases de données relationnelles évoluent bien, mais généralement uniquement lorsque cette évolution se fait sur un seul serveur (« scale-up »). Lorsque la capacité de ce serveur unique est atteinte, il faut passer à l’échelle inférieure et répartir la charge sur plusieurs serveurs, ce qui correspond à l’informatique dite distribuée. C’est à ce moment-là que la complexité des bases de données relationnelles commence à poser des problèmes quant à leur potentiel de mise à l’échelle. Si vous essayez de passer à des centaines ou des milliers de serveurs, la complexité devient insurmontable. Les caractéristiques qui rendent les bases de données relationnelles si attrayantes sont les mêmes qui réduisent aussi considérablement leur viabilité en tant que plates-formes pour les grands systèmes distribués.
Bases de données non relationnelles
Une base de données NoSQL fournit un mécanisme de stockage et de récupération des données qui est modélisé par des moyens autres que les relations tabulaires utilisées dans les bases de données relationnelles.
Les motivations pour cette approche comprennent :
- Simplicité de la conception. Ne pas avoir à gérer le « décalage d’impédance » entre l’approche orientée objet pour écrire des applications et les tables et lignes basées sur le schéma d’une base de données relationnelle. Par exemple, le stockage de toutes les informations relatives à la commande du client dans un seul document, plutôt que d’avoir à joindre de nombreuses tables, ce qui permet de réduire le code à écrire, à déboguer et à maintenir
- Une meilleure mise à l’échelle « horizontale » vers des grappes de machines, ce qui résout le problème lorsque le nombre d’utilisateurs simultanés monte en flèche pour les applications accessibles via le web et les appareils mobiles. L’utilisation de documents facilite grandement la mise à l’échelle, car toutes les informations relatives à la commande d’un client sont regroupées en un seul endroit, au lieu d’être réparties sur plusieurs tables. Les bases de données NoSQL répartissent automatiquement les données sur les serveurs sans qu’il soit nécessaire de modifier l’application (auto-sharding), ce qui signifie qu’elles répartissent nativement et automatiquement les données sur un nombre arbitraire de serveurs, sans que l’application ait besoin de connaître la composition du pool de serveurs. Les données et la charge des requêtes sont automatiquement équilibrées entre les serveurs, et lorsqu’un serveur tombe en panne, il peut être remplacé rapidement et de manière transparente sans interruption de l’application
- Contrôle plus fin de la disponibilité. Des serveurs peuvent être ajoutés ou supprimés sans interruption de l’application. La plupart des bases de données NoSQL prennent en charge la réplication des données, en stockant plusieurs copies des données à travers le cluster ou même à travers les centres de données, pour assurer la haute disponibilité et la reprise après sinistre
- Pour capturer facilement tous les types de données « Big Data » qui incluent les données non structurées et semi-structurées. Permettre une base de données flexible qui peut facilement et rapidement accueillir tout nouveau type de données et qui n’est pas perturbée par les changements de structure du contenu. En effet, les bases de données de documents sont dépourvues de schéma, ce qui vous permet d’ajouter librement des champs aux documents JSON sans avoir à définir au préalable des modifications (schéma sur lecture plutôt que schéma sur écriture). Vous pouvez avoir des documents avec un nombre de champs différent de celui des autres documents. Par exemple, un dossier de patient qui peut ou non contenir des champs énumérant les allergies
- Vitesse. Les structures de données utilisées par les bases de données NoSQL (c’est-à-dire les documents JSON) diffèrent de celles utilisées par défaut dans les bases de données relationnelles, ce qui rend de nombreuses opérations plus rapides dans les bases de données NoSQL que dans les bases de données relationnelles, car il n’est pas nécessaire de joindre les tables (au prix d’un espace de stockage accru en raison de la duplication des données – mais l’espace de stockage est tellement bon marché de nos jours que ce n’est généralement pas un problème). En fait, la plupart des bases de données NoSQL ne supportent même pas les jointures
- Coût. Les bases de données NoSQL utilisent généralement des grappes de serveurs de commodité bon marché, tandis que les SGBDR ont tendance à s’appuyer sur des serveurs et des systèmes de stockage propriétaires coûteux. De plus, les licences des systèmes SGBDR peuvent être assez coûteuses alors que de nombreuses bases de données NoSQL sont open source et donc gratuites
L’adéquation particulière d’une base de données NoSQL donnée dépend du problème qu’elle doit résoudre.
Les bases de données NoSQL sont de plus en plus utilisées dans les applications big data et web en temps réel. Elles sont devenues populaires avec l’introduction du web, lorsque les bases de données sont passées d’un maximum de quelques centaines d’utilisateurs sur une application interne à l’entreprise à des milliers ou des millions d’utilisateurs sur une application web. Les systèmes NoSQL sont aussi appelés « Not only SQL » pour souligner qu’ils peuvent aussi supporter des langages d’interrogation de type SQL.
De nombreux magasins NoSQL compromettent la cohérence (au sens du théorème CAP) au profit de la disponibilité et de la tolérance aux partitions. Parmi les raisons qui bloquent l’adoption des magasins NoSQL, on peut citer l’utilisation de langages d’interrogation de bas niveau, l’absence d’interfaces standardisées et les investissements énormes dans le SQL existant. En outre, la plupart des magasins NoSQL n’ont pas de véritables transactions ACID ou ne prennent en charge les transactions que dans certaines circonstances et à certains niveaux (par exemple, au niveau des documents). Enfin, les SGBDR sont généralement beaucoup plus simples à utiliser car ils disposent d’interfaces graphiques alors que de nombreuses solutions NoSQL utilisent une interface en ligne de commande.
Comparaison des deux
L’une des limitations les plus sévères des bases de données relationnelles est que chaque élément ne peut contenir qu’un seul attribut. Si nous prenons l’exemple d’une banque, chaque aspect de la relation d’un client avec une banque est stocké sous forme d’éléments de ligne distincts dans des tables distinctes. Ainsi, les données de base du client se trouvent dans une table, les détails du compte dans une autre table, les détails du prêt dans une autre encore, les investissements dans une autre table, etc. Toutes ces tables sont liées les unes aux autres par l’utilisation de relations telles que les clés primaires et les clés étrangères.
Les bases de données non relationnelles, plus précisément les magasins clé-valeur d’une base de données ou les paires clé-valeur, sont radicalement différentes de ce modèle. Les paires clé-valeur vous permettent de stocker plusieurs éléments liés dans une « rangée » de données dans la même table. Nous mettons le mot « rangée » entre guillemets car une rangée ici n’est pas vraiment la même chose que la rangée d’une table relationnelle. Par exemple, dans une table non relationnelle pour la même banque, chaque ligne contiendrait les coordonnées du client ainsi que les détails de son compte, de son prêt et de ses investissements. Toutes les données relatives à un client seraient commodément stockées ensemble sous la forme d’un seul enregistrement.
Cette méthode de stockage des données semble manifestement supérieure, mais elle présente un inconvénient majeur : les key-value stores, contrairement aux bases de données relationnelles, ne peuvent pas imposer de relations entre les éléments de données. Par exemple, dans notre base de données clés-valeurs, les détails du client (nom, sécurité sociale, adresse, numéro de compte, numéro de traitement du prêt, etc.) seraient tous stockés dans un seul enregistrement de données (au lieu d’être stockés dans plusieurs tables, comme dans le modèle relationnel). Les transactions du client (retraits du compte, dépôts du compte, remboursements du prêt, frais bancaires, etc.) seraient également stockées sous la forme d’un autre enregistrement de données unique.
Dans le modèle relationnel, il existe une méthode intégrée et infaillible pour garantir et appliquer la logique et les règles commerciales au niveau de la couche de base de données, par exemple qu’un retrait est imputé au bon compte bancaire, par le biais de clés primaires et de clés étrangères. Dans les magasins clés-valeurs, cette responsabilité incombe directement à la logique applicative et beaucoup de gens sont très mal à l’aise à l’idée de laisser cette responsabilité cruciale à l’application. C’est l’une des raisons pour lesquelles les bases de données relationnelles continueront à être utilisées.
Cependant, lorsqu’il s’agit d’applications web qui utilisent des bases de données, l’aspect de l’application rigoureuse de la logique métier n’est souvent pas une priorité absolue. La plus grande priorité est la capacité à servir un grand nombre de requêtes d’utilisateurs, qui sont généralement des requêtes en lecture seule. Par exemple, sur un site comme eBay, la majorité des utilisateurs se contentent de naviguer et de regarder les articles affichés (opérations en lecture seule). Seule une fraction de ces utilisateurs fait des offres ou réserve les articles (opérations en lecture-écriture). Et n’oubliez pas que nous parlons de millions, voire de milliards, de pages vues par jour. Les administrateurs du site eBay sont plus intéressés par un temps de réponse rapide pour assurer un chargement plus rapide des pages pour les utilisateurs du site, plutôt que par les priorités traditionnelles consistant à appliquer les règles commerciales ou à assurer un équilibre entre les lectures et les écritures.
Les bases de données à modèle relationnel peuvent être affinées et configurées pour exécuter des opérations en lecture seule à grande échelle par le biais d’entrepôts de données, et donc potentiellement servir un grand nombre d’utilisateurs qui interrogent une grande quantité de données, en particulier lorsqu’on utilise des architectures MPP relationnelles comme Analytics Platform System, Teradata, Oracle Exadata ou IBM Netezza, qui prennent toutes en charge la mise à l’échelle. Comme mentionné précédemment, les entrepôts de données se distinguent des bases de données classiques en ce qu’ils sont utilisés pour une analyse plus complexe des données. Cela diffère de la base de données transactionnelle (OLTP), dont l’utilisation principale est de soutenir les systèmes opérationnels et d’offrir des rapports quotidiens à petite échelle.
Cependant, le véritable défi est le manque d’évolutivité du modèle relationnel lorsqu’il s’agit d’applications OLTP, ou de toute solution avec beaucoup d’écritures individuelles, ce qui est le domaine des architectures SMP relationnelles. C’est là que les modèles non relationnels peuvent vraiment briller. Ils peuvent facilement répartir leurs charges de données sur des dizaines, des centaines, voire des milliers de serveurs dans des cas extrêmes (pensez à Google Search). Chaque serveur ne traitant qu’un petit pourcentage du total des demandes des utilisateurs, le temps de réponse est très bon pour chaque utilisateur individuel. Bien que ce modèle de calcul distribué puisse être construit pour des bases de données relationnelles, il est très difficile à mettre en œuvre, en particulier lorsque les écritures sont nombreuses (c’est-à-dire OLTP), ce qui nécessite des techniques comme le sharding, qui requiert généralement un codage important en dehors de la logique métier de l’application. Ceci est dû au fait que le modèle relationnel insiste sur l’intégrité des données à tous les niveaux, qui doit être maintenue, même si les données sont accédées et modifiées par plusieurs serveurs différents. C’est la raison pour laquelle le modèle non relationnel est l’architecture de choix pour les applications web telles que le cloud-computing et les réseaux sociaux.
Donc, en résumé, les SGBDR ne souffrent d’aucune mise à l’échelle horizontale pour les charges de transaction élevées (millions de lectures-écritures), tandis que les bases de données NoSQL résolvent les charges de transaction élevées, mais au prix de l’intégrité des données et des jointures.
N’oubliez pas que de nombreuses solutions utiliseront une combinaison de bases de données relationnelles et non relationnelles (voir Qu’est-ce que la persistance polyglotte ?).
N’oubliez pas non plus que vous n’avez peut-être pas besoin de la performance d’une base de données non relationnelle et qu’au lieu de cela, aller simplement avec le stockage de fichiers dans HDFS et l’utilisation d’Apache Hive sera suffisant (Apache Hive est une infrastructure d’entrepôt de données construite au-dessus d’Hadoop pour fournir un résumé de données, une requête et une analyse qu’elle fournit via un langage de type SQL appelé HiveQL).
Et pour terminer sur une note qui ajoute à la confusion, nous avons une autre catégorie qui se forme appelée NewSQL : NewSQL est une catégorie de SGBDR modernes qui cherchent à fournir les mêmes performances évolutives que les systèmes NoSQL pour les charges de travail OLTP en lecture-écriture tout en conservant les garanties ACID d’un système de base de données relationnel traditionnel. Les inconvénients sont qu’ils ne sont pas adaptés aux requêtes de type OLAP et qu’ils ne conviennent pas aux bases de données de plus de quelques téraoctets. Les exemples incluent VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix et Altibase.
Une image montrant les catégories dans lesquelles s’insèrent de nombreux produits :
Un excellent graphique qui montre comment toutes les technologies s’insèrent dans le cloud Azure provient de Understanding NoSQL on Microsoft Azure :
L’essentiel pour l’utilisation d’une solution NoSQL est si vous avez une application OLTP qui a des milliers d’utilisateurs et a une très grande base de données nécessitant une solution scale-out et/ou utilise des données JSON, en particulier si ces données JSON ont diverses structures. Vous bénéficiez également de la haute disponibilité car les solutions NoSQL stockent plusieurs copies des données. Gardez simplement à l’esprit que pour les performances, vous pouvez sacrifier la cohérence des données, ainsi que la possibilité de joindre des données, d’utiliser SQL et de faire des mises à jour rapides en masse.
Plus d’infos:
MySQL vs MongoDB
MySQL vs. MongoDB : regard sur les bases de données relationnelles et non relationnelles
10 choses à savoir sur les bases de données NoSQL
Introduction aux bases de données
Différence entre SQL et NoSQL : comparaison
Différences entre bases de données SQL et NoSQL expliquées avec quelques exemples de DB
NoSQL, NewSQL ou SGBDR : Comment choisir
NewSQL – RDBMS on Steroids
Bases de données NoSQL vs NewSQL Choisissez le bon outil pour le bon travail
SQL vs NoSQL : vous voulez bien avoir un stockage relationnel par défaut
Oracle défend les BD relationnelles contre les concurrents NoSQL
Comprendre le NoSQL sur Microsoft Azure
Rencontrez l’avant-garde des nouvelles bases de données relationnelles
Vers SQL ou NoSQL ? C’est la question des bases de données
Théorème CAP : Revisité
Qu’y a-t-il de vraiment nouveau avec NewSQL ?
MongoDB vs MySQL : Une étude comparative sur les bases de données
Fonctionnalités et différences des bases de données SQL et NoSQL
.