Comment choisir entre le SQL et le NoSQL ?
ELEPHANT technologies, l’ESN locale et à taille humaine spécialisée sur 2 métiers : le développement et le pilotage autour de 4 expertises : Embedded & IoT, Digital et Agile.
Aujourd’hui, retrouvez Melvyn notre elephantgénieur développeur fullstack qui nous explique comment choisir entre le SQL et le NoSQL. Il va commencer par quelques définitions, puis il comparera les deux solutions en les illustrant.
Let’s go !
Comment choisir entre le SQL et le NoSQL ?
Une phase importante a lieu au début de chaque projet informatique. Il s’agit du choix de la stack technique. Cela inclut le langage front-end, le langage back-end mais également les bases de données. A cet instant, 2 choix principaux s’offrent à nous : une base de données SQL ou une base de données NoSQL. Nous allons voir les différences entre ces 2 dernières afin de vous aider à faire votre choix.
Commençons par quelques définitions :
SQL :
Créé par Donald D. Chamberlin et Raymond F. Boyce dans les années 1970, le langage SQL (Structured Query Language) est un langage informatique utilisé pour exploiter des bases de données. Il permet de manière générale la définition, la manipulation et le contrôle de sécurité des données.
NoSQL :
Le terme NoSQL signifiant “Not Only SQL” fut inventé en 1998 par Carl Strozz, et aurait émergé en 2008 grâce à la parution en open-source de “Cassandra” (la base de données non-relationnelle qu’utilisaient Facebook en interne). Il désigne une famille de SGBD qui permet de manipuler des données au même titre que SQL. Il est apparu lorsque les grandes entreprises du web (Google, Amazon, Facebook, SourceForge.net, etc…), ont dû commencer à traiter des volumes trop importants de données.
SGBD :
Un Système de Gestion de Base de données (SGBD) est un logiciel qui permet de stocker des informations dans une base de données. Il permet de lire, écrire, modifier, trier, transformer ou même imprimer les données qui sont contenus dans la base de données. Il peut aussi bien s’agir d’un système relationnel (SQL) que d’un système non-relationnel (NoSQL).
Comparons les solutions SQL et NoSQL :
Des bases de données différentes
La principale différence entre le SQL et le NoSQL est que le premier est principalement utilisé dans les Système de Gestion de Base de Données Relationnels (SGBDR). Ce qui signifie que les informations sont rangées dans des tables distinctes. Ces dernières sont reliées entre elles par ce qu’on appelle des “relations” et chacune à une structure spécifique définie. Ainsi, pour obtenir une information particulière, il est régulièrement nécessaire de parcourir plusieurs tables et de faire appel à des “jointures” afin de regrouper les informations. En revanche, le NoSQL est utilisé dans les Systèmes de Gestion de Base de Données Non Relationnels. A noter qu’il existe plusieurs types de base de données NoSQL en fonction des besoins du projet. Il faut savoir lequel est cohérent et optimisé pour l’utilisation que vous allez en faire.
Les différents types de bases de données NoSQL :
⇒ Les bases de données orientées documents : 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).
⇒ Les bases de données clé/valeur : Chaque élément de la base est stocké sous la forme d’un nom attribut (la clé), associé à sa valeur.
⇒ Les bases de données orientées colonnes sont optimisées pour les requêtes sur de grands ensembles de données. Elles stockent ces données en colonnes plutôt qu’en lignes.
Voici un exemple de comparaison d’une base de données SQL et d’une base de données NoSQL :
Scalabilité verticale VS Scalabilité horizontale
Une autre différence très importante entre le SQL et le NoSQL est la manière dont elles peuvent évoluer.
En effet, du fait de sa structure relationnelle, toutes les tables d’une base de données SQL doivent être hébergées sur un même serveur. Ce qui signifie que si l’on veut augmenter la quantité de données manipulables, il faut rajouter de l’espace de stockage (HDD ou SSD), de la puissance (CPU) ou de la rapidité (RAM). On appelle ça “la scalabilité verticale”. Cela à un coût de plus en plus important à mesure de l’augmentation du besoin.
Les bases de données NoSQL sont non-relationnelles et donc à l’inverse des bases de données SQL, elles peuvent être hébergées sur plusieurs serveurs différents. On appelle ça “la scalabilité horizontale”. Il suffit donc d’ajouter des serveurs lorsque l’on a besoin de gérer plus de données. A noter qu’il est également possible de faire de la scalabilité verticale.
Et au niveau de l’évolution des données ?
Dans une application utilisant du SQL, le format des données doit être définit en amont afin d’établir les différentes relations qu’il pourrait y avoir entre elles. Si les données ne sont pas amenées à évoluer (ou peu) cela ne pose pas trop de problèmes. En revanche, si toute une donnée change de format pour une raison quelconque (demande du client, refonte de l’application, etc…) il devient assez complexe et chronophage de faire les modifications dû à sa structure en relations et de ce que ça implique (foreign keys, primary keys, cascades, etc…).
A contrario, dans une application NoSQL (donc sans relations), on peut changer à la volée les informations, rajouter des champs, changer le type de la donnée, etc...
Voici un tableau récapitulatif :
Conclusion
Comme nous avons pu le voir, chaque type de base de données (relationnelle ou non-relationnelle) ont des avantages et inconvénients qui leurs sont propre. En effet, il est important de bien définir les relations (s’il y en a) entre les données avant de se lancer dans un projet. Il faut également savoir si ces données sont amenées à évoluer et si les requêtes que vous allez faire seront complexes ou non. Il est également important de connaitre ou d’estimer la quantité de données que vous serez susceptible de manipuler. Cela aura un impact sur la gestion des serveurs afin de stocker la data et donc sur les coûts.
Une fois toutes ces questions répondues vous devrez être en capacité de choisir entre le SQL et le NoSQL pour vos futurs projets !
🐘 Nous remercions Melvyn pour son article, et si vous souhaitez découvrir d’autres articles techniques, c'est par ici !
Sources :
https://www.mongodb.com/fr-fr/nosql-explained
https://fr.wikipedia.org/wiki/NoSQL