Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
Un développeur pense que vous devez opter pour SQL
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
vs. Mongo
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
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.db.users.find({
"signup_time": {
$gt: new Date(Date.now() - 24*60*60 * 1000)
}
})
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 :
Répondre avec citation
.
Envoyé par TheGuit
ça veut dire qu'on devrait faire 3 - 4 nouvelles tables, faire donc 3 à 4 jointures en + par an dans toutes nos requêtes sql alors qu'un simple update de la table pourrait suffir ? Je pense que c'est effectivement "propre" mais niveau esthétisme je trouve ça assez reboutant. En plus avec les ORM du style Hibernate en Java cela implique de transformer nos entités en entités hiérarchisées avec des types et de l'héritage juste pour un ou 2 champs supplémentaires. 
Partager