SQL vs NoSQL : différences et applications de deux technologies de stockage de données

Le SQL et le NoSQL font partie des outils les plus utilisés aujourd’hui par les Data Analysts. Ils permettent de manipuler des données et d’extraire de la valeur de celle-ci, ce que beaucoup d'entreprises recherchent aujourd’hui. Cependant, il faut faire un choix : SQL ou NoSQL ?

SQL : c’est quoi?

Le SQL, ou Structured Query Language, est un langage de programmation qui fait aujourd’hui référence dans le monde de la Data. Il s’agit d’un langage qui permet de gérer un système de bases de données relationnelles (SGBDR).

Ces bases de données relationnelles se composent de 3 différentes caractéristiques :

• Les Tables sont composées de colonnes et de lignes (comme un tableau excel). L’ensemble des tables composent la base de données (BDD).
• Les Colonnes définissent les différentes catégories qui composent les informations d’une donnée.
• La clé primaire et la clé étrangère permettent de mettre en relation différentes tables.

‍

Prenons un exemple :

Table "Cinéma"

‍

Table " Acteurs"

Ici nous disposons de deux tables : « Cinéma » et « Acteurs ». Dans ces tables, les informations sont catégorisées : Nom, Prénom, etc ….

Enfin, « id film » est la clé qui relie les deux tables. Cette clé indique par exemple que Mark Hamill est un acteur de Star Wars parce que l’id du film est la même.

Ce système de base de données est très utilisé aujourd’hui par les Data Analyts car il apporte une excellente performance par rapport à Excel (notamment grâce au cloud) et permet de réaliser des requêtes beaucoup plus efficaces.

NoSQL : c’est quoi?

NoSQL est un système de base de données qui est dit "non relationnel". Il s’agit d’une base de données non-structurée, c'est-à-dire qu'elle ne passe pas par des relations entre tables pour récupérer des données. Moins rigides, les applications de ce système sont nombreuses.

Aujourd’hui, NoSQL est leader dans le monde des applications web qui gèrent des données en temps réel. Notamment celles qui traitent des flux de données à grande échelle (Big Data).

Il existe une collection de systèmes de BDD NoSQL, adaptés aux différentes problématiques du Big Data :

1. Documents, 
2. Clé/valeurs, 
3. Graph-based, 
4. Colonnes. 

La simplicité et la flexibilité sont les principaux avantages du NoSQL, ce qui, dans certains cas, en fait un outil puissant à la disposition des professionnels de la Data science.

‍

Différences entre SQL et NoSQL?

Comparons maintenant les deux systèmes de BDD afin d’avoir une meilleure idée de ce qui les différencie.

SQL vs NoSQL : les différences de stockage et d’organisation des données

Le SQL stocke ses données en suivant un modèle relationnel défini et fixe. 

Prenons un exemple plus concret : une bibliothèque pleine de dossiers.

Chaque dossier représente une table qui elle-même contient des colonnes (les pages du dossier). De plus, les dossiers sont reliés par un fil rouge. Ce fil relie les dossiers ayant une des informations communes, le fil représente la relation entre les dossiers.

Cette bibliothèque suit donc un schéma. Il est très facile pour quelqu’un qui regarde cette bibliothèque de comprendre les relations entre les dossiers. Il pourra aussi rapidement extraire des informations qui ont une donnée partagée entre deux dossiers.

Au contraire, le NoSQL est non-structuré.

Tu peux donc imaginer la même bibliothèque mais sans les fils rouges. De plus, certains dossiers n’ont pas le même nombre de colonnes (ou de pages). Certains dossiers ne sont pas dans la bibliothèque mais dans une autre, deux étages plus bas ou même dans un autre bâtiment ! 

Dans le monde réel, l’utilisation de cette bibliothèque est difficile mais dans le monde informatique, cette organisation apporte une grande flexibilité. En quelques commandes, il est possible de retrouver le bon dossier.

SQL vs NoSQL : la scalabilité des données 

Cette différence de stockage que nous avons vue précédemment a un impact important sur les ressources utilisées pour stocker ces données.

Si nous reprenons l’exemple de la bibliothèque avec des fils (SQL) que se passe-t-il quand on veut augmenter la taille de la base de données ? Il faut rajouter des étagères, renforcer la structure de la bibliothèque, améliorer la répartition des fils pour ne pas se perdre et utiliser une échelle pour atteindre les dossiers les plus hauts. Impossible d'ouvrir une nouvelle bibliothèque dans une pièce différente parce que les fils rouges ne pourront pas s’étendre jusque-là.

Un Data Center (DC) est une bibliothèque mais pour les données informatiques. Ajouter une étagère revient à augmenter la puissance du serveur. On parle donc d’augmenter la RAM, les CPU (processeur) et le stockage.

Cette opération s’appelle le vertical scaling (agrandissement vertical).

Nosql et la notion d'Horizontal Scaling

Pour ce qui est de la bibliothèque NoSQL c’est différent. Ici il n’y a pas de fil rouge, donc pas de problème de monopolisation de l’espace. Dès qu’une bibliothèque est pleine, on en ouvre une nouvelle ! 

Physiquement ça poserait un problème parce qu’il faudrait se déplacer pour se rendre aux différentes bibliothèques (épuisant à la longue). Mais informatiquement, aucun problème, car c’est une machine qui exécute tes commandes en quelques milli-secondes..

Cette action revient à augmenter le nombre de Data Centers et non leur puissance. On appelle cela horizontal scaling (Agrandissement horizontal).

SQL vs NoSQL : les jointures

La jointure SQL est une opération qui permet d’extraire une donnée en mettant en relation plusieurs bases de données. Comme sa définition l'indique, on a besoin d’une relation entre les BDD pour effectuer une jointure.

A l’inverse, NoSQL ne dispose pas de jointure. Il s’agit du plus gros défaut de NoSQL du point de vue des habitués de l’analyse de données. Effectivement, pour les Data Analyst, les jointures sont des actions quotidiennes et très utiles. Elles permettent d’extraire des informations nouvelles et valorisables qui dépassent celles simplement écrites dans la BDD.

‍

 {{banniere-article}}

‍

Les jointures : Une clé commune entre deux tables

Par exemple, reprenons l’exemple vu ci-dessus avec les tables « Cinéma » et « Acteurs ». Si on veut savoir le nom de tous les acteurs ayant joué dans Star Wars, on devra faire une jointure entre ces deux tables. Les jointures seront basées sur la clé commune aux deux tables, c'est-à-dire les données contenues dans la colonne « id film ». 

D’une manière plus concrète, cela revient à prendre un dossier dans notre bibliothèque puis à tirer sur le fil pour trouver un autre dossier qui est en relation avec le premier. Une fois les deux dossiers en main on peut travailler.

SQL dispose d’une multitude de jointures différentes (Inner, Outer, Cross, Left, Right). Ces jointures font de SQL un outil très pratique pour croiser les bases de données.

SQL ou NoSQL : les performances

Il est souvent avancé par les adeptes de la Data que le NoSQL est plus rapide que le SQL. Effectivement, on pourrait facilement le croire.

Le NoSQL est :

• Non-structuré,
• Stocké sur des petits fichiers séparés,
• Simplifié, il ne demande pas de jointure,
• Intuitif, il s’exécute avec des requêtes courtes et simples,
• Dénormalisé : Il ne suit pas de règle stricte de construction.

Cependant, sa composition simplifiée peut être alourdie par certains défauts. Si la base de données est trop grosse, le système va créer des redondances pendant les mises à jour. Ces redondances ont tendance à ralentir le système et diminuer les performances.

Tout dépendra de ta base de données. Dans certains cas, elle sera plus performante en SQL qu’en NoSQL. Il n’y a pas de réponse tranchée sur ce sujet.

SQL ou NoSQL : les systèmes de bases de données

Les bases de données SQL et NoSQL sont des outils théoriques. Quand il s’agit de les manipuler, on doit passer par des systèmes de bases de données. Ce sont des applications qui vont mettre en œuvre les bases de données. Un peu comme une interface entre l’utilisateur et la machine. 

Il existe plein de systèmes différents. Chaque système s’adapte aux besoins particuliers d’un Data Analyst en fonction aussi de ses préférences.

Voici quelques systèmes de gestion de bases de données relationnelles et non-relationnelles :

Les SGBDR manipulables avec SQL :

• MySQL : il s’agit d’un système de gestion de bases de données relationnelles open source. Il est un des plus utilisés dans le monde.
• PostgreSQL : il s’agit aussi d’un système de gestion de bases de données relationnelles open source qui est particulièrement apprécié pour son respect de la norme SQL.  PostgreSQL et MySQL sont concurrents.
• Oracle : ce système fournit une architecture simple et performante pour l’accès, la définition et la maintenance des données. Il s’agit d’un système professionnel et non open source comme les deux autres.

Les bases de données NoSQL

Les systèmes de gestion de bases de données non relationnelles avec NoSQL :

• MongoDB : Il s’agit d’une database NoSQL open source orientée document. MongoDB utilise des documents de type JSON pour stocker toutes les données.
• Cassandra : un système de stockage de données distribué pour le traitement de très grandes quantités de données de type Big Data.
• Oracle NoSQL Database Cloud Service : ce système permet de gérer les modèles de base de données clé-valeurs, colonnes et documents.

Tu peux imaginer le système de bases de données comme un bibliothécaire. Tu lui donnes tes dossiers, il ira les ranger au bon endroit avec les bons fils. Tu lui poses une question, il ira chercher la réponse pour toi dans la bibliothèque.

Tu souhaites te former à la Data Science ? Découvre le programme de nos formations !

‍

SQL vs NoSQL : Tableau récapitulatif

Comment choisir entre SQL et NoSQL?

Les deux systèmes de stockage et de manipulation sont deux outils extrêmement intéressants pour les Data Analysts. Alors comment choisir lequel utiliser lors du développement d’un nouveau projet Data ?

Quand choisir SQL ?

Si tu souhaites utiliser SQL, tu recherches une base de données segmentée et délimitée. Les propriétés des BDD relationnelles en font un outil approprié aux projets structurés où le Data Analyst a besoin d’utiliser certaines fonctionnalités pour manipuler et analyser son dataset.

De plus, si ton projet touche à des données fortement normalisées ou si la validité de typage est importante alors il faudra s'orienter vers le SQL. Les données normalisées se rencontrent par exemple dans le monde de la finance ou de la comptabilité. 

Si ton projet nécessite des requêtes complexes qui vont demander beaucoup de jointures alors le SQL sera ton seul allié. En effet, le NoSQL ne permet pas les fonctionnalités de jointure.

Enfin, si ton projet data nécessite d’utiliser des fonctionnalités d’écriture sur des éléments spécifiques (une ligne dans une table par exemple), il vaut mieux utiliser une base de données relationnelles. Le langage SQL est donc plus adapté car il n’a pas besoin de passer par un document comme le ferait le NoSQL. L’écriture ou la réécriture sera plus rapide et moins fastidieuse.

Quand choisir NoSQL ?

Pour le NoSQL, ton choix s’y portera si ta base de données n’est pas adaptée à une organisation délimitée et fixe. Sur un réseau social par exemple, les utilisateurs remplissent leur profil avec des informations de quantité et de nature différentes. Leurs actions génèrent également des données variées.

Ainsi, il est cohérent de choisir une BDD non relationnelle car elle apporte une grande flexibilité dans l’organisation des données.

Ensuite, si ton projet exige des fonctionnalités de lecture alors NoSQL détient des avantages par rapport au SQL. Il permet en une seule requête de récupérer beaucoup d'informations sans passer forcément par des jointures comme le fait le SQL.

Si tu dois gérer un grand volume de données dans un style proche du Big Data alors tu pourras sérieusement considérer le NoSQL en raison de ses propriétés évolutives. En effet, son système d’horizontal scaling lui permet de rester performant et rapide même face à un flux de données grandissant d’année en année.

Enfin, si tu as accès à des ressources distribuées (plusieurs serveurs) alors le NoSQL est une excellente solution car le SQL s’adapte mal à cette architecture.