Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
Un développeur pense que vous devez opter pour SQL

Le , par Coriolan, Chroniqueur Actualités
Quel est selon vous le meilleur SGBD ?
En août dernier, une étude a montré la montée en puissance du NoSQL, avec de plus en plus d’entreprises qui se tournent vers le cloud public. Ce constat peut être expliqué par plusieurs facteurs, notamment la performance des nouveaux systèmes NoSQL qui reste bonne avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse de coûts.

Mais tout le monde ne semble pas être convaincu que le NoSQL constitue une solution optimale et peut remplacer les bases de données SQL. Certains ont même regretté d’avoir opté pour les bases de données non relationnelles au lieu du bon vieux SQL.

Les mauvaises raisons pour choisir NoSQL

Dans son article, Paris Kasidiaris a listé selon lui les mauvaises raisons qui poussent les développeurs à recourir aux bases de données NoSQL. Dans la plupart des cas, ce choix est dû à une connaissance superficielle du sujet.

Plus facile pour les développeurs

Comparer la façon d’écrire un document dans le magasin de données contre l’écriture d’une nouvelle base de données avec INSERT constitue le meilleur moyen pour comparer la facilité d’utilisation de chaque solution NoSQL et SQL. En effet, l’écriture d’un objet JSON directement dans le magasin de données est plus facile qu’avoir recours à une requête SQL INSERT.

Maintenant, si on compare par exemple la façon de récupérer les utilisateurs qui se sont inscrits sur une application durant les 24 dernières heures :

Avec MySQL

Code : Sélectionner tout
1
2
3
SELECT  *
FROM    users
WHERE   signup_time >= CURDATE() - INTERVAL 1 DAY
vs. Mongo

db.users.find({
"signup_time": {
 $gt: new Date(Date.now() - 24*60*60 * 1000)
}
})
Dans le premier cas, on utilise un langage ayant des mots que les humains utilisent pour communiquer entre eux. Le deuxième cas au contraire est écrit en JavaScript, et vous êtes dans l’obligation de créer votre requête avec un objet JSON et même convertir les 24 heures en millisecondes.

Et ce n’est pas fini, si vous voulez récupérer de la base de données tous les utilisateurs qui se sont inscrits la semaine dernière et se sont connectés au moins deux fois, vous êtes dans de beaux draps.

Une simple requête relationnelle comme celle-ci ne peut tout simplement pas être exprimée directement dans un magasin de données NoSQL, mais elle peut être utilisée en SQL (une seule requête SQL ou ORM : mapping objet-relationnel). Pour contourner cette limite du NoSQL, le développeur doit recourir à la dénormalisation, c’est-à-dire la copie des mêmes données dans plusieurs documents ou tables afin de simplifier et optimiser le traitement des requêtes ou pour ajuster les données à la demande pour l’utilisateur. Une autre solution consiste à utiliser MapReduce.

Meilleure prise en compte de la montée en charge

Cet argument est souvent avancé par les partisans du NoSQL, mais encore faudrait-il d’abord que la scalabilité soit un problème pour le développeur et que le NoSQL soit plus performant que les solutions SQL lors de la montée en charge.

D’abord, la montée en charge n’est pas et ne sera peut-être jamais un problème, à part si le développeur doit faire face à des milliers de requêtes par seconde et des terrabytes de données dans sa base de données. Et même au cas où vous êtes amené à un tel scénario, des solutions (fully managed) comme AWS RDS existent.

La deuxième hypothèse est aussi erronée, NoSQL n’est pas plus performant que SQL lorsqu’il s’agit de montée en charge. MySQL est utilisé par quelques-uns des sites web les plus populaires de la planète comme Facebook, Twitter, GitHub, Basecamp et à peu près toutes les installations de PHP. Ces sites comme on peut le constater n’ont pas trouvé de soucis avec les SGBD SQL malgré l’énorme trafic qu’ils reçoivent.

Une vitesse d’écriture plus rapide

Cette supposition est vraie, mais en tant que développeur, est-ce que votre application a vraiment besoin d’écritures rapides ? À part si vous allez exécuter un service de logging ou quelque chose de similaire, dans la plupart des cas, toutes les applications se ressemblent et ont un but commun : une personne propose un contenu qui sera consommé par d’autres personnes. C’est la façon avec laquelle fonctionne le web aujourd’hui, Facebook, Twitter, YouTube, les services de partage de fichiers, votre application ne fera surement pas exception.

Ce sont donc les principales mauvaises raisons qui poussent les développeurs à choisir le NoSQL contre SQL. Ce qui est malheureux, c’est qu’elles sont mises en avant par le site web officiel de MongoDB, un site qui a surement joué un rôle vital dans cette illusion.

Les bonnes raisons pour choisir une base de données SQL

Chaque technologie utilisée a ses points forts et ses points faibles, et SQL ne sort pas du lot. Voici pourquoi SQL est presque le bon choix pour tout type d’application web.

L’écosystème

L’écosystème de SQL est juste imbattable, c’est un langage qui date de 1974, donc plus de 40 ans d’existence. Pour cette raison, les développeurs sont devant un nombre énorme d’outils et de services auxquels ils peuvent recourir.

SQL est enseigné dans toutes les universités et les écoles d’informatique du monde. Les solutions matures de SQL ne manquent pas, de PHPMyAdmin et SQLAlchemy à Pony ORM. Les opérateurs cloud publics proposent également des bases de données SQL en tant que service que vous pouvez utiliser sans effort (Amazon RDS, Google Cloud SQL and Azure SQL Database).

Les transactions et les propriétés ACID

SQL offre une chose que tous les gens responsables d’applications web en production cherchent à assurer, la tranquillité d’esprit à propos de leurs données. Cela est dû au fait que toute solution SQL dans le marché vous permet de regrouper plusieurs requêtes SQL dans des unités de travail conforme au standard ACID (appelées transactions).

En pratique, cela veut dire que vous pouvez entrer des changements sur votre base de données regroupés en une seule transaction. Vous pouvez mener toute requête qui concerne des opérations de transaction, comme start transaction, commit, ou rollback, tout en étant sûr de garantir l’atomicité, la cohérence, l’isolation et la durabilité de votre transaction.

En d’autres termes, avec SQL, vous pouvez être sûr d’arriver à votre objectif sans avoir de mauvaises surprises.

Le stockage

Un autre aspect important des systèmes de base de données SQL pour les applications en production est sa capacité à faire des économies sur l’espace de stockage. En effet, SQL a besoin d’une structure de table prédéfinie pour enregistrer les données. Cela permet d’enregistrer seulement les contenus dans chaque ligne et chaque colonne dans le disque. Au contraire, avec les solutions NoSQL, vous aurez à enregistrer tout le document (toutes les valeurs) sur le disque, puisqu’il n’existe pas de structure prédéfinie pour les documents stockés dans chaque collection. Plus vos données deviennent importantes, plus le problème s’amplifie avec plusieurs gigabytes de données NoSQL.

Cet article ne vise pas à chahuter les magasins de données NoSQL. Loin de là, il y a des solutions NoSQL dans le marché qui sont utilisées dans presque tout type d’application web en production. Il s’agit ici de montrer qu’il ne faut pas considérer NoSQL comme une solution à tous nos problèmes de stockage de données, pour la simple raison que cette solution parait être simple. On a déjà des solutions SQL matures et bien établies qui ont déjà fait leurs preuves et répondent à tous nos besoins en la matière.

Source : stateofprogress.blog

Et vous ?

Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?

Voir aussi :

Forum Décisions SGBD


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de philouZ philouZ - Membre habitué https://www.developpez.com
le 22/03/2017 à 4:30
Perso je n'utilise pas de NoSQL car je n'en ai absolument pas l'utilité. A mon sens le NoSQL ne peut avoir un intérêt que dans l'utilisation du big data avec un volume de donnée extrêmement important et je ne suis pas encore dans ce cas.

Pour du site web, des appli principalement accès gestion, du développement mobile avec accès par webservices, je n'utilise que du SQL. C'est peut-être aussi parce que je maitrise ce que je fais et que je n'ai pas besoin de me former pour l'utiliser (même si on en apprend tous les jours).

Pour répondre à la question
Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?
Je pense que ça fait plus effet de mode. Comme beaucoup de choses, ça vient de sortir alors vite tout le monde se précipite dessus et dit qu'il n'y a pas mieux. J'en vois encore qui me disent : "Comment tu n'es pas passé au big data ?".

J'attends les retours d'expériences mais je ne suis pas sûr qu'il y ait tant de monde que ça qui passe au NoSQL. La part restera faible à mon sens.

Chaque outil a son utilité...
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 22/03/2017 à 8:09
je sais pas si SQL est plus performant que NoSQL, mais dans mon cas le SGBD Cassandra est plus performant que n'importe quels SGBD SQL (Oracle database, PostgreSQL, les autres comme DB2 ou SQL server jamais essayé)

Je pense pas qu'il faut raisonner en terme de langage (sql ou pas sql) mais en terme de SGBD.
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 22/03/2017 à 8:16
Comparer du relationnel et du nosql en demandant lequel est le meilleur c'est comme comparer une formule 1 et un voiture du Dakar.
Les deux peuvent rouler vite , chacune dans leur domaine.

Evidemment que si j'ai un modele de données qui requiert des relations entre les entités , ca serait complètement stupide de partir sur du nosql parce que c'est la mode. Et inversement stocker des données indépendantes avec du relationnel n'est sans doute pas optimum.

Bref c'est un faux débat
Avatar de myNameIsFlo myNameIsFlo - Membre habitué https://www.developpez.com
le 22/03/2017 à 9:10
Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?

Dans 99% du temps le SQL car relationnel. Le NoSQL pour les informations partagées entre ferme de serveur et la très haute performance de flux en temps réel.

Je peux donner 2 cas d'utilisation de NoSql. Du cache partagé (config/tarif aérien) entre plusieurs serveurs afin de ne réduire la charge et une pile d'information alimenter par les communications de plusieurs opérateurs télécom pour analyse 'en temps réel' (de l'information poubelle, lue puis jetée) où les traitements sont massifs.

Ces besoins ne se présentent pas tous les jours. Si vous avez d'autres exemples où la contrainte oblige à utiliser du noSQL, envoyez!
Avatar de sbeex sbeex - Membre habitué https://www.developpez.com
le 22/03/2017 à 9:11
Il manque simplement une réponse : Les 2 sont super pour qui sait les utiliser à bon escient !

C'est ridicule de dire que SQL ou NoSQL est mieux... NoSQL c'est une autre philosophie et chercher à les comparer c'est un peu comparer du sel et du sucre. On ne les utilise pas pour les mêmes recettes mais les 2 sont dans l'armoire de la cuisine.

J'ai été formé sur du SQL avec Oracle donc ce milieu m'est très familier. Pourtant j'ai eu la volonté d'apprendre à utiliser NoSQL et à changer aussi ma façon de pensée car IL FAUT penser différemment en NoSQL qu'en SQL ! Et c'est à mon sens l'erreur la plus fréquente des dev de la vieille école SQL -> ils veulent retrouver les mêmes concepts ! Si je peux faire ça en SQL je veux pouvoir le faire en NoSQL ... c'est pas comme ça ^^ il faut structurer différemment il faut penser différemment.

Et au final NoSQL est vraiment bien dans des cas adaptés. le NoSQL offre une flexibilité que SQL NE PEUT PAS égaler. En sql on ajoute un champ ca implique des scripts de migrations, des problèmes car "Que fait-on avec les entrées déjà existantes ? on met à null ?"

En nosql on prend le problème différemment :
Ok on accepte un objet avec ce nouveau champ sans faire aucune modif dans notre bdd. Et simplement quand on le récupère on fait un petit test si ce champ est défini -> sinon ... et basta

Juste une autre philosophie
Avatar de vanskjære vanskjære - Membre actif https://www.developpez.com
le 22/03/2017 à 9:40
Pour ma part je n'ai eu à faire qu'a des SGDBR classique (DB2, MSSQLS, Sybase ASA).
J'ai une connaissance assez lointaine du sujet NoSQL mais comme dit précédemment il est difficile de comparer des techno prévu pour des usages différents.

[troll ON]
Plutôt pain ou baguette?
[troll OFF]
Avatar de TheGuit TheGuit - Membre du Club https://www.developpez.com
le 22/03/2017 à 10:08
Déjà la question est débile de base NoSQL regroupe tellement de concept different ! Si ce monsieur veux m'expliquer que SQL est plus rapide pour gerer des données de session que Redis je veux bien qu'il me le montre. Je suis 100% sur qu'il a tord.

En NoSQL on retrouve les base clé/valeur, les base object, les base graph, ... On est entrain de comparer des choses incomparable.

Il y'a une choses qui est très vrai par contre, les gens font souvent le choix NoSQL par effet de mode et sans en comprendre les concepts, comme toujours c'est forcément moyen.
Avatar de melka one melka one - Membre éclairé https://www.developpez.com
le 22/03/2017 à 11:01
ce qui en resort c'es que sql est ancien et de ce fait a corrigé les defaults qu'il a pu avoir et bien évidement sa communauté importante.

Code : Sélectionner tout
$gt: new Date(Date.now() - 24*60*60 * 1000)
il parle de galere pour la conversion de la date mais pas tant que sa il suffit de faire une fonction générique et de creer une librairie direction npm faut bien participé.

Code : Sélectionner tout
1
2
3
4
5
function debut(jour){
 
new Date(Date.now()-jour*24*60*60 * 1000)
 
}
Code : Sélectionner tout
$gt: debut(1)
Avatar de Shepard Shepard - Membre confirmé https://www.developpez.com
le 22/03/2017 à 14:19
Citation Envoyé par TheGuit Voir le message
Déjà la question est débile de base NoSQL regroupe tellement de concept different ! Si ce monsieur veux m'expliquer que SQL est plus rapide pour gerer des données de session que Redis je veux bien qu'il me le montre. Je suis 100% sur qu'il a tord.
Quels sont tes arguments pour dire que Redis est forcément plus rapide qu'un SGBDR ? Je ne connais pas mais d'après la description faite sur le site web c'est juste une base de données stockée directement sur la RAM, ce que la plupart des SGBDR peuvent faire aussi. Quels sont les avantages de Redis ?
Avatar de sitexw sitexw - Membre du Club https://www.developpez.com
le 22/03/2017 à 15:44
Regarde quelques benchmark sur Internet et tu verras tout de suite la différence ! Après, on parle d'un cas assez précis où il est évident que les bases de données SQL non pas l'avantage.
Pour finir, je pense qu'il faut choisir la bonne technologie au bonne endroit et non pas de mettre tous dans le même sac. Globalement une base de données SQL sera largement efficace pour beaucoup de projets. Et le NoSQL prend tout son intérêt au moment où on enregistre une grande quantité de données pour ensuite les analyser. D'où le terme "Big Data".
Donc la réponse finale est simple, il faut utiliser les deux (dans la mesure où l'on en a besoin).
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil