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

NoSQL remplacera-il SQL

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.

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.

SQL et NoSQL ne sont pas forcément des technos diamétralement opposées. 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. 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), …

Les différences entre SQL et noSQL

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.

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.

 « 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
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.

« 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) .

 « 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.  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.
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.

« 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. 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.

 « 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.

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.

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.

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.

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 bases de données noSQL sont résolument orientée “Big Data”.

Top 12 meilleurs bases de données NOSQL

MONGODB

Il s’agit d’une base de données NoSQL open source orientée document. MongoDB utilise des documents de type JSON pour stocker toutes les données. Il est écrit en C++.

CASSANDRA

Il a été développé sur Facebook pour la recherche dans les boîtes de réception. Cassandra est un système de stockage de données distribué pour le traitement de très grandes quantités de données structurées.

HBASE

Il s’agit d’une base de données distribuée et non relationnelle qui est conçue pour la base de données BigTable par Google.

NEO4J

Neo4j est considéré comme une base de données de graphes native car il implémente efficacement le modèle de graphes de propriétés jusqu’au niveau du stockage.

ORACLE NOSQL

Oracle NoSQL Database implémente une carte allant des clés définies par l’utilisateur aux éléments de données non structurées.

AMAZON DYNAMODB

DynamoDB utilise un modèle de base de données NoSQL, qui n’est pas relationnel, ce qui permet d’avoir des documents, des graphiques et des colonnes parmi ses modèles de données.

COUCHBASE

Couchbase Server est une base de données de documents NoSQL pour les applications Web interactives. Il dispose d’un modèle de données flexible, est facilement évolutif et offre des performances élevées et constantes.

MEMCACHED

Il s’agit d’un système de mise en cache de mémoire distribuée de haute performance, son code source est ouvert, destiné à accélérer les applications Web dynamiques en réduisant la charge de la base de données.

COUCHDB

C’est une base de données NoSQL Open Source qui utilise JSON pour stocker les informations et utilise JavaScript comme langage de requête.

GRAPHQL

GraphQL est un langage de requête pour les APIs et un runtime pour répondre à ces requêtes avec vos données existantes. GraphQL fournit une description complète et compréhensible des données de votre API, donne aux clients le pouvoir de demander exactement ce dont ils ont besoin et rien de plus, facilite l’évolution des API dans le temps, et permet de puissants outils de développement.

TINKERPOP

Apache TinkerPop est un framework open source, agnostique et graphique, distribué sous la licence commerciale Apache2. Lorsqu’un système de données est compatible avec TinkerPop, ses utilisateurs peuvent modéliser leur domaine sous forme de graphique et analyser ce graphique à l’aide du langage de orienté graph qu’est Gremlin.

Enjeux et Solutions

Les avancées technologiques de ces dernières années en Tunisie et ailleurs permettent d’accompagner l’augmentation des volumes de données structurées et non structurées. Les limites techniques auxquelles les systèmes relationnels étaient une réponse ne sont plus d’actualité : volume de données en ligne (Transactional Processing), disponibilité des systèmes, temps réel, démocratisation du cloud, etc. Par ailleurs, la donnée qui était hier une commodité opérationnelle est devenue un enjeu business pour de nouvelles opportunités : exploration de la donnée, data science, etc.

Nous vous proposons de découvrir l’écosystème des nouvelles architectures de la donnée bâties autour des solutions dites NoSQL afin d’en appréhender leurs caractéristiques propres et cas d’usage associés : Couchbase, MongoDB, ElasticSearch, Cassandra, etc. La formation et l’accompagnement offerts par notre cabinet Global Engineering Center, leader de formation en nouvelles technologies en Tunisie vous permet de :

  • Appréhender les notions relatives aux systèmes distribués et à la donnée (cohérence, théorème de CAP, etc.)
  • Découvrir l’écosystème NoSQL
  • Parcourir les caractéristiques des différentes solutions NoSQL (MongoDB, Cassandra, Couchbase, ElasticSearch, etc.)
  • Identifier les différents cas d’usage de la donnée
  • Observer les plateformes de streaming de la donnée (Storm, Spark, etc.) et l’écosystème Hadoop

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

fr_FR
en_GB fr_FR