Tag Archives: mongodb

SQL vs noSQL : Quelles différences, pour quels projets?

Posted by: Bruno Raffet / no comments / TAGS: , , , , ,

Préambule

Les bases de données SQL (Structured Query Language) existent depuis plus de quatre décennies. L’utilisation a explosé à la fin des années 1990 avec l’augmentation des applications Web et des solutions open source telles que MySQL, PostgreSQL et SQLite.
Même si les bases de données NoSQL existent depuis les années 1960, elles n’ont que récemment pris de l’ampleur avec l’arrivée des solutions telles que MongoDB, CouchBase, Redis et Apache Cassandra. L’acronyme « noSQL » a deux interprétations qui ne sont pas aujourd’hui tranchées :
  • Pour les uns il s’agit de « No SQL » c’est-à-dire l’utilisation d’un autre langage de requête et affirmant au passage la possible fin d’un cycle où le SQL était tout puissant
  • Pour les autres, il s’agit de « Not Only SQL » c’est-à-dire l’utilisation combinée de SQL avec d’autre mécanismes de recherche d’information
Quoi qu’il en soit, aujourd’hui le débat entre Sql/noSql déchaîne les passions et tourne parfois à la guerre sainte ! Avant d’aller plus loin, dissipons un certain nombre de mythes.

Mythe N°1 : noSQL remplacera SQL

Ben voyons !… Ce serait comme dire que les bateaux ont été remplacés par les voitures parce qu’elles étaient d’une technologie plus récente. SQL et NoSQL font la même chose : stocker des données, mais ils le font chacun à leur manière avec des approches bien différentes. Le choix d’une technologie BD est crucial pour un projet et peut soit le booster ou l’entraver. Le NoSQL ne remplace pas le SQL, c’est juste une alternative.

Mythe N°2 : NoSQL est meilleur que SQL, et … réciproquement !

Certains projets sont mieux adaptés à l’utilisation d’une base de données SQL. Certains sont mieux adaptés à NoSQL. Et certains pourraient même les utiliser soit de façon interchangeable. On ne peut donc appliquer de façon uniforme un même « parti pris technologique » sur tous les projets.

Mythe N°3 : SQL et NoSQL sont clairement des technos diamétralement opposées

Ce n’est pas forcément vrai. Certaines bases de données SQL adoptent les fonctionnalités NoSQL et vice versa. Les choix risquent de devenir de plus en plus floues, et les bases de données hybrides telle que NewSQL pourraient offrir des options intéressantes à l’avenir.

Mythe N°4 : La base de données dépend du langage et environnement de développement

Il est vrai que nous nous sommes habitués aux « bundles technologiques », véritables offres groupées telles que : LAMP/WAMP (Linux/Windows, Apache, MySQL, PHP), MEAN (MongoDB -NoSQL-, Express, Angular, Node.js), .NET (IIS, C#/VB et SQL Server) Java (avec Apache et Oracle), …
Il existe bien sûr des raisons pratiques, historiques et commerciales pour lesquelles ces piles technologiques existent et continuent d’évoluer. Mais elles ne présument pas qu’elles sont des règles immuables. Vous pouvez utiliser une base de données MongoDB NoSQL dans votre projet PHP, .NET., Java ou ColdFusion. Vous pouvez vous connecter à MySQL ou SQL Server avec Node.js. Bref, ne laisser pas les habitudes dicter le type de base de données dont votre projet a besoin.

Les différences

1- « Les tables SQL » vs « Les documents noSQL »

Première différence de taille. SQL organise le stockage de données sur le principe de tables reliées entre elles. La structure et les types des données sont rigides, c’est-à-dire fixés à l’avance avant d’implémenter une logique métier.
noSQL stocke et manipule des documents qui correspondent à des collections d’objets.
Exemple :
{
ISBN: 9780992461225,
title: “JavaScript: Novice to Ninja”,
author: “Darren Jones”,
format: “ebook”,
price: 29.00
}
Là où noSQL repousse les limites, c’est que l’on peut stocker toutes les données que l’on souhaite dans n’importe quel document ! La base de données NoSQL ne se plaint pas. Exemple :
{
ISBN: 9780992461225,
title: “JavaScript: Novice to Ninja”,
author: “Darren Jones”,
year: 2014,
format: “ebook”,
price: 29.00,
description: “Learn JavaScript from scratch!”,
rating: “5/5″,
review: [

{ name: "A Reader", text: "The best JavaScript book I've ever read." },
{ name: "JS Expert", text: "Recommended to novice and expert developers alike." }
]

}

Les tables SQL imposent un modèle de données strictes, donc il est difficile de faire des erreurs. NoSQL est plus flexible et pardonnable, mais la possibilité de stocker des données n’importe où peut entraîner des problèmes de cohérence.

2- « Le schéma SQL » vs « La logique noSQL »

Dans une base de données SQL, il est impossible d’ajouter des données tant que vous ne définissez des tables et des types de champs dans ce que l’on appelle un schéma. De plus, ce schéma SQL contient d’autres informations : Clés primaires – index, contraintes, fonction, procédures stockées …
Votre schéma de données doit être conçu et mis en œuvre avant que toute logique métier puisse être développée pour manipuler des données. Il est possible de faire des mises à jour plus tard, mais de gros changements peuvent être compliqués.
Dans une base de données NoSQL, la logique est toute autre ! Les données peuvent être ajoutées n’importe où, à tout moment. Il n’est pas nécessaire de spécifier une conception de document ou même une collection à l’avance. Par exemple, dans MongoDB, la déclaration suivante créera un nouveau document dans une nouvelle collection de livres si elle n’a pas été précédemment créée :
db.book.insert(
ISBN: 132456789,
title: “Le cerveau du nabab”,
author: “Curt Siodmak”,
format: “live de poche”,
price: 29.00
);
Une base de données NoSQL peut être plus adaptée aux projets où les exigences initiales en matière de données sont difficiles à déterminer. Cela dit, ne pas confondre difficulté et paresse ! Négliger de concevoir un bon stock de données au début du projet, hypothèque vos chances de succès.
Il faut noter que la représentation des données en collection et le résultat en flux JSON des requêtes permet de consommer les données très rapidement et facilement par les applications front (web, mobile) qui incluent de plus en plus les appels Ajax.

3- « La Normalization SQL » vs « La Denormalisation NoSQL »

Par les termes anglo-saxons « Normalization » et « Denormalisation » on veut préciser la façon dont les données sont ou pas dupliquées(noSQL) ou reliées par des clés étrangères (SQL) .
Supposons que nous voulons ajouter la notion d’ « Editeur » à notre base de données de librairie. Un Editeur pourrait offrir plus d’un titre, donc, dans le cadre d’une base de données SQL, nous serions naturellement incité à créer une nouvelle table « Editeur » :
id name country email
SP001  Gallimard  France  contact@publisher.com
Et d’ajouter ensuite un champ publisher_id à notre table de livre (clé étrangère).
ISBN  title  author format price publisher_id
123456789 La blonde de pékin James Hadley Chase ebook 22.00 SP001
987654321  Le cerveau du nabab Curt Siodmak live de poche 29.00 SP001
Cela réduit au minimum la redondance des données. Nous ne répétons pas l’information de l’éditeur pour chaque livre – seulement la référence à celui-ci. Cette technique est connue sous le nom de normalisation et présente des avantages pratiques. Nous pouvons mettre à jour un seul éditeur sans modifier les données du livre.
Nous pouvons également utiliser ces techniques de normalisation dans NoSQL. Exemple :
Collection Livre
{
ISBN: 123456789,
title: ” La blonde de pékin”,
author: “James Hadley Chase”,
format: “ebook”,
price: 22.00,
publisher_id: “SP001″
}
Collection Editeur
{
id: “SP001″
name: ” Gallimard “,
country: “France”,
email: ” contact@publisher.com”
}
Toutefois, cela n’est pas toujours pratique, pour des raisons qui apparaîtront plus loin. Nous pouvons opter pour « dénormaliser » notre document et répéter les informations de l’éditeur pour chaque livre :
{
title: ” La blonde de pékin”,
author: [ "James Hadley Chase " ],
published_date: ISODate(“1988-05-03″),
pages: 256,
language: “Français”,
publisher: {
id: “SP001″
name: ” Gallimard “,
country: “France”,
email: ” contact@publisher.com”
}
}{
title: “Péri en mer”,
author: “Charles Williams”,
published_date: ISODate(“1986-11-21″),
pages: 192,
language: “English”,
publisher: {
id: “SP001″
name: ” Gallimard “,
country: “France”,
email: ” contact@publisher.com”
}
}
Là, des développeurs pourraient être choqués par cette représentation de données qui admet une duplication des données. C’est pourtant le principe de « noSQL denormalization » !
Cela conduit à des requêtes beaucoup plus rapides, mais la mise à jour des informations (« downsides ») de l’éditeur dans plusieurs enregistrements sera considérablement plus lente.

4- « La logique de jointure SQL » vs « pas de jointure dans NoSQL »

Les requêtes SQL offrent une puissante clause JOIN. Nous pouvons obtenir des données reliées dans plusieurs tables en utilisant une seule instruction SQL. Par exemple :
SELECT book.title, book.author, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;
Cela renvoie tous les titres de livres, auteurs et noms d’éditeurs associés (en supposant que l’un a été défini).
NoSQL n’a pas toujours d’équivalent de JOIN, et cela peut étonner ceux qui ont une expérience SQL.
Par exemple avec Mongo DB, si nous avons utilisé des collections normalisées (comme décrit ci-dessus), nous devons récupérer séparément la collection de livres et d’éditeur et c’est le code qui devra les associer en implémentant une logique métier. C’est pour cette raison que la « dénormalization » est souvent essentielle.
Il faut noter que d’autres SGDB ont implémenté un langage de requête proche du SQL autorisant l’usage de jointure. C’est le cas, par exemple de couchBase qui a créé le N1QL permettant de requêter une base noSQL suivant des principes proches du SQL.
En voici un exemple :
SELECT usr.personal_details, orders
FROM users_with_orders usr
USE KEYS “Tamekia_13483660″
LEFT JOIN orders_with_users orders
ON KEYS ARRAY s.order_id FOR s IN usr.shipped_order_history END
Donnant le résultat :
{
“results”: [
{
"personal_details": {
"age": 39,
"display_name": "Tamekia Akin",
"email": "Tamekia.Akin@snailmail.com",
"first_name": "Tamekia",
"last_name": "Akin",
"state": "Massachusetts"
}
}
]
}
Voir le tutorial http://query.pub.couchbase.com/tutorial/#25
Au passage, cela milite pour une barrière qui sera de plus en plus floue entre les noSql et SQL.

5- « Intégrité SQL » vs « NoSQL Data Integrity »

La plupart des bases de données SQL vous permettent d’appliquer des règles d’intégrité de données à l’aide de contraintes de clés étrangères. Dans notre exemple, cela empêche de supprimer des Editeurs si un ou plusieurs livres leur sont toujours attribués.
Le schéma SQL applique ces règles qui prévient la création de données invalides ou d’enregistrements orphelins.
Ces mêmes options d’intégrité de données ne sont pas disponibles dans les bases de données NoSQL. Vous pouvez stocker ce que vous voulez indépendamment de tout autre document. Idéalement, un seul document sera la seule source de toutes les informations sur un élément.
Par exemple, MongoDB acceptera tout ce qui est fourni. Cela signifie que plusieurs développeurs, applications, sous-systèmes peuvent effectivement détruire les données de l’autre en réutilisant accidentellement les noms de champs ou en utilisant de mauvaises commandes.
Une des premières choses que vous devez faire avec MongoDB est d’écrire une couche de données très claire et de s’assurer que « tout le monde » l’utilise correctement. Sinon, vous risquez vraiment de détruire « silencieusement » des données.
Ce qu’il faut retenir c’est que les bases de données SQL peuvent valider vos données et vos mises à jour (définition de contraintes), mais elles les rendent du coup très strictes. Les bases de données NoSQL sont plus flexibles mais ne valident pas les données : il en revient au développeur d’ajouter des contrôles dans la logique du programme car la base de données elle-même n’empêchera pas les erreurs.

6- « Transaction SQL » vs « Transaction NoSQL »

Dans les bases de données SQL, plusieurs mises à jour peuvent être exécutées au sein d’une même transaction afin de garantir le succès ou l’échec de l’exécution du code SQL. On n’imagine pas la vente d’un livre (ajout au journal de vente) dans décroitre le stock (décrémenter le stock du livre qui vient d’être vendu).
Dans une base de données NoSQL, la modification d’un document unique est atomique (si vous mettez à jour trois valeurs dans un document, les trois sont mis à jour avec succès ou ils restent inchangés°. Cependant, il n’y a pas vraiment d’équivalent de la transaction SQL pour les mises à jour de plusieurs documents. Il semble alors clair qu’il faille gérer la notion d’atomicité dans le code.
Il faut noter cependant que NewSQL, éditée par la société VoltDb, annonce gérer les transactions ACID à l’instar des bases de données relationnelles.

7- Syntaxe « CRUD SQL » vs « CRUD NoSQL »

La création, la lecture de mise à jour et la suppression de données sont à la base de tous les systèmes de base de données (CRUD Create, Read, Uodate, Delete).
SQL est un langage déclaratif qui est devenu une norme internationale ( même si la plupart des sgbd implémentent des syntaxes subtilement différentes).
Les bases de données NoSQL utilisent des appels javascrip-looking avec des arguments JSON. Les opérations de base sont simples, mais cela peut très vite devenir compliqué pour des requêtes plus complexes.
SQL NoSQL
 Ajoute un nouveau livre
INSERT INTO book (
`ISBN`, `title`, `author`
)
VALUES (
’123456789′,
‘La blonde de pékin’,
‘James Hadley Chase’
); “,
db.book.insert({
ISBN: “123456789″,
title: “La blonde de pékin”,
author: “James Hadley Chase”
});
Met à jour le prix d’un livre
UPDATE book
SET price = 19.99
WHERE ISBN = ’123456789′
db.book.update(
{ ISBN: ’123456789′ },
{ $set: { price: 19.99 } }
);
Retourne tous les livres dont le prix est > 10
SELECT title FROM book
WHERE price > 10;
db.book.find(
{ price: { >: 10 } },
{ _id: 0, title: 1 }
);
Le deuxième objet JSON est connu comme une projection: il définit les champs renvoyés (_id est renvoyé par défaut pour qu’il soit désactivé).
Compte le nombre de livres pour l’éditeur « SitePoint/SP001 »
SELECT COUNT(1) FROM book
WHERE publisher_id = ‘SP001′;
db.book.count({
“publisher.name”: “Gallimard”
});
Retourne le nombre de livre par type de format
SELECT format, COUNT(1) AS `total`
FROM book
GROUP BY format;
db.book.aggregate([
{ $group:
{
_id: "$format",
total: { $sum: 1 }
}
}
]);
Ceci est connu sous le nom d’agrégation: un nouveau jeu de documents est calculé à partir d’un ensemble d’origine.
Supprime les livres édités par « SitePoint/SP001 »
DELETE FROM book
WHERE publisher_id = ‘SP001′;
Alternativement, il est possible de supprimer l’enregistrement de l’éditeur et de supprimer en les enregistrements de livres associés si les clés étrangères sont spécifiées de manière appropriée.
db.book.remove({
“publisher.name”: “Gallimard”
});
On notera également que l’architecture orientée « document » de noSQL se prêterait plutôt bien à l’utilisation d’ORM car les documents qu’elle stocke sont essentiellement des objets eux-mêmes. Malheureusement, il n’y a pas beaucoup de bibliothèques Java ORM disponibles. Notons l’existence pour MongoDB de morphia (une bibliothèque Java type-safe pour MongoDB) et Spring-Data (la mise en œuvre MongoDB au sein du framework Spring) ou encore Mongoose si vous programmez en NodeJs.

8- Performance SQL vs NoSQL

C’est sûrement la comparaison la plus controversée ! NoSQL est régulièrement cité comme étant plus rapide que SQL. Et ce n’est pas surprenant. Le principe de « denormalization » induit une représentation plus simple et permet donc de récupérer toutes les informations sur un élément spécifique dans une seule requête. Il n’y a donc pas besoin de liens JOIN ou de requêtes SQL complexes. Mais la redondance des informations alourdie considérablement les opérations de mise à jour.
En résumé, les bases de données « orientées document » ne sont pas intrinsèquement plus rapides. Par exemple, MongoDB est inutilement lent dans de nombreux cas où SQL est particulièrement rapide. En particulier sous-performant sur les requêtes d’agrégation ou sans index.
En conséquence, la conception du globale projet et les exigences en matière d’organisation de données seront déterminant avant même le choix du SGBD. Une base de données SQL bien conçue sera certainement supérieure à celle d’un équivalent NoSQL mal conçu et vice versa !

9- SQL vs NoSQL Scalabilité

Il est souvent constaté que les problématiques liées à la répartition de charge posent de réels challenges pour les DSI des entreprises (Théorème de CAP Consistency Availability Partition tolerance) . Le « load balancing » sur un serveur SQL est complexe car dû à la nature même dont les données sont stockées, organisées et reliées entre elles. Pour régler les problèmes de montées en charge, on admettra le plus souvent le principe d’un puissant serveur adossé à une infra de type failover (exemple « Allways On » Ms Sql Server) plutôt que de « clusterer » les instances SQL. Cela a un impact direct sur les licences et donc le coût de ce type d’infrastructure.
Les modèles de données NoSQL peuvent rendre le processus plus facile et beaucoup d’entre eux ont été conçus nativement avec des fonctionnalités de « scalabilité élastique ». L’organisation des données en documents et la « denormalization » des collections permettent le partitionnement et autorise une montée en charge de la base de données sur le matériel courant déployé sur site ou dans le Cloud. Cela permet une croissance pratiquement illimitée.
Pour synthétiser, le but recherché est de simplifier l’architecture tout en décuplant les capacités de stockage. Cela implique le principe de base de données distribuée taillée pour la répartition de charge préférant la gestion d’une table gigantesque (cf. Bigtable de Google) à celle de nombreuses tables interdépendantes (modèle relationnel). A ce titre, les base de données noSQL sont résolument orientée “Big Data”.

En résumé

Le paysage technologique évolue très vite et les entreprises doivent dans le même temps continuer à évaluer et à choisir les bases de données qui répondront à leurs besoins futurs et accompagneront leur croissance. L’objectif de cet article était donc de présenter les principales différences qui existent au moment, pour de nombreux décideurs, de prendre des décisions forgeant le futur de leur système d’information.
Nous avons vu que les bases de données SQL et NoSQL font finalement à peu près la même chose (stocker des données) mais de différentes façons. Le choix d’un système de gestion de base de données (SGBD) est donc un instant important et structurant pour un projet. Bien sûr, il est toujours possible de choisir une option puis de passer à une autre plus tard. Mais un peu de d’analyse et de réflexion conceptuelle au début d’un projet feront gagner du temps et de l’argent.
Les bases de données NoSQL, plus jeunes sur le marché, sont susceptibles parfois de générer plus de problèmes que les solutions SQL réputées plus matures. Il est vrai également que le niveau d’expertise est en cours d’acquisition par la communauté IT et que des problématiques surviennent souvent à la suite d’une méconnaissance technique. Les développeurs et les Dba ont tout simplement moins d’expérience avec ces nouveaux systèmes de base de données noSQL qu’ils souhaitent pourtant mettre œuvre dans la perspective, par xemple, d’un SI orienté Big Data et potentiellement « up-to-date » !
A ce stade il est difficile de déterminer quelles technologies ou quels projets. On peut tout de même émettre quelques pistes :
Pour les projets dont :
  • La structure de données relatives aux logiques métier peuvent être identifiées à l’avance,
  • L’intégrité des données (native dans le SGBD) est essentielle,
  • Le caractère transactionnel est fortement présent (eCommerce),
SQL semble plus adapté.
Pour les projets dont :
  • L’organisation de données est indépendante, indéterminée et évolutive,
  • L’organisation demande un forte agilité et gérant beaucoup de données structurées, semi-structurées, non structurées et polymorphes,
Les besoins de performance et d’évolutivité (load balancing) sont impératives,
noSQL semble être une solution.
Ceci dit, vous pouvez utiliser un DB SQL pour imiter un DB NoSQL (comme stocker des documents JSON dans un seul champ par exemple). L’option inverse n’est pas nécessairement possible…
Dans tous cas, une bonne analyse préalable du projet et une équipe expérimentée et bien formée seront un préalable à l’utilisation de ces nouvelles bases de données noSQL. Et même si elles remettent en cause beaucoup de principes ancrés depuis des décennies dans les équipes de développement, elles apportent surtout beaucoup de solutions en termes de temps de développements, coûts et performances. Restent à les utiliser le discernement de la rigueur et du bon sens.
Bruno Raffet – CEO Sourceamax
Sources :
VoltDb.com – NoSQL vs. NewSQL: What’s the difference? – https://www.voltdb.com/blog/2016/09/22/nosql-vs-newsql-whats-difference/
Octo.com – NewSQL – http://blog.octo.com/newsql/
Le Monde Informatique – NewSQL pour combiner le meilleur de SQL et noSQL – http://www.lemondeinformatique.fr/actualites/lire-newsql-pour-combiner-le-meilleur-de-sql-et-nosql-34475.html
mongoDb – libre blanc – « Les 5principaux éléments à prendre en compte lors de l’évaluation d’une base de données NoSQL »
OnTrack.fr – Dossier Big Data – Pourquoi NoSQL ? – https://www.ontrack.fr/blog/big-data-pourquoi-nosql/