L’un des choix les plus fondamentaux à faire lors du développement d’une application est de savoir s’il faut utiliser une base de données SQL ou NoSQL pour stocker les données. Les databases conventionnelles, c’est-à-dire relationnelles qui utilisent le langage SQL (Structured Query Language) pour les requêtes, sont le fruit de décennies d’évolution technologique, de bonnes pratiques et de tests de résistance au monde réel. Elles sont conçues pour des transactions fiables et des requêtes ad hoc qui sont la base des applications métier. Mais elles sont également soumises à des restrictions, telles que des schémas rigides, qui les rendent moins adaptées à d’autres types d’applications. 

Les bases de données NoSQL sont apparues en réponse à ces limitations. Les systèmes NoSQL stockent et gèrent les données d’une manière qui permet une vitesse opérationnelle élevée et une grande flexibilité pour les développeurs. Nombre d’entre eux ont été développés par des entreprises telles que Google, Amazon, Yahoo et Facebook, qui cherchaient de meilleurs moyens de stocker du contenu ou de traiter des données pour des sites web massifs. Contrairement aux bases de données SQL, de nombreuses bases de données NoSQL peuvent être mises à l'échelle horizontalement sur des centaines ou des milliers de serveurs. 

Les avantages du NoSQL ont cependant un coût. Ces bases de données favorisent la vitesse et l’évolutivité au détriment des propriétés ACID qui sous-tendent les transactions fiables promises par les bases de données SQL. Les capacités ACID garantissent que si plusieurs utilisateurs font de manière simultanée des modifications des données, toutes les modifications soient prises en compte, dans un ordre précis et maîtrisé de manière à avoir un résultat cohérent (intégrité des données) avec l’historique des modifications faites par chacun. De plus, les métaphores utilisées pour travailler avec les données dans les systèmes NoSQL sont relativement nouvelles, comparées aux décennies de connaissances institutionnelles accumulées autour des requêtes SQL.

Les bases de données SQL et NoSQL offrent des compromis différents. Bien qu’elles puissent être en concurrence dans le contexte d’un projet spécifique - par exemple, laquelle choisir pour telle ou telle application - elles sont complémentaires dans un contexte plus large. Chacune est adaptée à des cas d’utilisation différents. Il ne s’agit pas tant de choisir entre les unes et les autres que de savoir quel outil convient le mieux à la tâche.

NoSQL et SQL 

La différence fondamentale entre SQL et NoSQL n’est pas si compliquée. Chaque technologie a une philosophie différente sur la façon dont les données doivent être stockées et récupérées. 

Avec les SGBDR SQL, toutes les données ont une structure inhérente. Une base de données classique - comme Microsoft SQL Server, MySQL, PostgreSQL ou Oracle - utilise un schéma, c’est-à-dire une définition formelle de la manière dont les données insérées dans la database seront composées. Par exemple, une certaine colonne dans une table peut être limitée aux seuls nombres entiers. Par conséquent, les données enregistrées dans la colonne auront un degré élevé de normalisation. Le schéma rigide d’une base de données SQL permet également d’effectuer relativement facilement des agrégations sur les données, par exemple en combinant les données de deux tables à l’aide de la commande SQL JOIN. 

Avec NoSQL, les données peuvent être stockées sans schéma ou de manière libre. Toutes les données peuvent être stockées dans n’importe quel enregistrement. Parmi les bases de données NoSQL, vous trouverez quatre modèles communs de stockage des données, qui conduisent à quatre types communs de systèmes NoSQL :

1 - Les bases de données orientées documents (par exemple, MongoDB). Les données insérées sont stockées sous la forme de structures JSON sans schéma, ou "documents", où les données peuvent être n’importe quoi, des entiers aux chaînes de caractères en passant par le texte libre. Il n’est pas nécessaire de préciser quels champs, le cas échéant, un document JSON doit contenir. 

2 - Les bases à clé-valeur (par exemple, Redis). Les valeurs libres, qu’il s’agisse de simples entiers ou chaînes de caractères ou de documents JSON complexes, sont accessibles dans la base de données au moyen de clés, telles que des chaînes de caractères. 

3 - Les bases orientées colonnes larges [wide-column] (par exemple, Cassandra). Les données sont stockées en colonnes et non en lignes comme dans un système SQL classique. La différence avec les bases orientées colonnes habituelles (columnar database vs. wide-column database), c'est qu'un nombre illimité de colonnes (et donc de types de données différents) peuvent être regroupées ou agrégées selon les besoins pour les requêtes ou les vues de données.

4 - Les bases de données orientées graphe (par exemple, Neo4j). Les données sont représentées sous la forme d’un réseau ou d’un graphe d’entités et de leurs relations, où chaque nœud du graphe est un fragment de données de forme libre. 

Le stockage de données sans schéma est utile dans les scénarios suivants : 

- Vous voulez un accès rapide aux données, et vous êtes plus préoccupé par la vitesse et la simplicité d’accès que par la fiabilité des transactions ou la cohérence. 

- Vous stockez un grand volume de données et vous ne voulez pas vous enfermer dans un schéma, car modifier le schéma ultérieurement pourrait être lent et pénible. 

- Vous recevez des données non structurées d’une ou plusieurs sources et vous souhaitez conserver les données dans leur forme originale pour une flexibilité maximale. 

- Vous voulez stocker des données dans une structure hiérarchique, mais vous voulez que ces hiérarchies soient décrites par les données elles-mêmes, et non par un schéma externe. NoSQL permet aux données d’être autoréférentielles de manière occasionnelle, ce qui est plus complexe à émuler pour les bases de données SQL. 

Interrogation des bases de données NoSQL 

Le langage de requête structuré (SQL) utilisé par les bases de données relationnelles fournit un moyen uniforme de communiquer avec le serveur lors du stockage et de la récupération de données. La syntaxe SQL est hautement standardisée. Ainsi, même si les bases de données individuelles peuvent traiter certaines opérations différemment (par exemple, les fonctions analytiques), les principes de base restent les mêmes. 

En revanche, chaque base de données NoSQL a tendance à avoir sa propre syntaxe pour l’interrogation et la gestion des données. CouchDB, par exemple, utilise des requêtes au format JSON, envoyées via HTTP, pour créer ou récupérer des documents dans sa base de données. MongoDB envoie des objets JSON via un protocole binaire, au moyen d’une interface de ligne de commande ou d’une bibliothèque de langage. 

Certains produits NoSQL peuvent utiliser une syntaxe de type SQL pour travailler avec les données, mais seulement de façon limitée. Par exemple, Apache Cassandra, une base orientée wide-column, possède son propre langage de type SQL, le Cassandra Query Language ou CQL. Une partie de la syntaxe CQL est directement issue du lexique SQL, comme les mots-clés SELECT ou INSERT. Mais il n’y a pas de moyen natif d’effectuer un JOIN ou une sous-requête dans Cassandra, et les mots-clés correspondants n’existent donc pas dans CQL. 

Architecture sans partage 

Un choix de conception commun aux systèmes NoSQL est l’architecture "sans partage" [shared-nothing]. Dans ce type d'architecture, chaque nœud de serveur du cluster fonctionne indépendamment des autres nœuds. Le système n’a pas besoin d’obtenir le consensus des autres nœuds pour renvoyer des données à un client. Les requêtes sont rapides car elles peuvent être renvoyées à partir du nœud le plus proche ou le plus pratique. 

Un autre avantage de cette architecture est la résilience et l’expansion horizontale [id scale-out]. L’extension du cluster se fait simplement en créant de nouveaux nœuds et en attendant qu’ils se synchronisent avec les autres. Si un nœud NoSQL tombe en panne, les autres serveurs du cluster continueront à fonctionner. Toutes les données restent disponibles, même si moins de nœuds sont en service pour répondre aux demandes. 

Notez qu’une conception sans partage n’est pas exclusive aux bases de données NoSQL. De nombreux systèmes SQL classiques peuvent être configurés de manière à ne pas être partagés, comme MySQL, bien que cela implique généralement de sacrifier la cohérence du cluster au profit des performances. 

Limites de NoSQL

Si NoSQL offre tant de liberté et de flexibilité, pourquoi ne pas abandonner complètement SQL ? La réponse est simple : de nombreuses applications requièrent toujours les types de contraintes, de cohérence et de protections que les bases de données SQL fournissent. Dans ces cas, certains "avantages" de NoSQL peuvent se transformer en inconvénients. D’autres limitations proviennent du fait que les systèmes NoSQL ne disposent pas de certaines fonctionnalités que l’on considère comme acquises dans l’espace SQL. 

Pas de schéma

Même si vous recevez des données de forme libre, vous devez presque toujours imposer des contraintes aux données pour les rendre utiles. Avec NoSQL, imposer des contraintes implique de déplacer la responsabilité de la base de données vers le développeur d’applications. Par exemple, le codeur peut imposer une structure par le biais d’un système de mappage objet-relationnel, ou ORM. Mais si vous souhaitez que le schéma vive avec les données elles-mêmes, NoSQL ne le permet généralement pas.

Certaines solutions NoSQL fournissent des mécanismes optionnels de typage et de validation des données. Apache Cassandra, par exemple, dispose d’un grand nombre de types de données natives qui rappellent ceux que l’on trouve dans le langage SQL conventionnel.

Cohérence éventuelle 

Les systèmes NoSQL offrent la possibilité d’échanger une cohérence forte ou immédiate contre une meilleure disponibilité et de meilleures performances. Les bases de données conventionnelles garantissent que les opérations sont autonomes (toutes les parties d’une transaction réussissent, ou aucune ne réussit), cohérentes (tous les utilisateurs ont la même vue des données), isolées (les transactions ne se font pas concurrence) et pérennes (une fois terminées, elles survivront à une panne de serveur). 

Ces quatre propriétés, collectivement appelées ACID, peuvent être traitées différemment dans les systèmes NoSQL. Au lieu d’exiger une cohérence forte à travers le cluster, ce qui retarderait nécessairement les réponses aux requêtes, vous pouvez opter pour une cohérence éventuelle, qui permet aux requêtes d’être servies sans attendre que les dernières écritures soient copiées sur les autres nœuds du cluster. Les données insérées dans le cluster sont finalement disponibles partout, mais vous ne pouvez pas garantir quand. 

Pour certains systèmes NoSQL, vous pouvez choisir l’un des nombreux compromis entre la cohérence et la vitesse, bien que ce qui est disponible varie selon les produits. Azure Cosmos DB de Microsoft, par exemple, vous permet de sélectionner un niveau de cohérence par requête, de sorte que vous pouvez choisir le comportement qui convient à votre cas d’utilisation. La sémantique des transactions, qui, dans un système SQL, garantit que toutes les étapes d’une transaction (par exemple, l’exécution d’une vente et la réduction des stocks) sont achevées ou annulées, est disponible dans certains systèmes NoSQL, tels que MongoDB

Le verrouillage des systèmes NoSQL

La plupart des systèmes NoSQL sont conceptuellement similaires, mais mis en œuvre différemment. Chacun a tendance à avoir ses propres métaphores et mécanismes d’interrogation et de gestion des données. L’un des effets secondaires de cette situation est un degré de couplage potentiellement élevé entre la logique applicative et la base de données. Ce couplage n’est pas si grave si vous choisissez un système NoSQL et que vous vous y tenez, mais il peut devenir une pierre d’achoppement si vous changez de système par la suite. 

Si vous migrez, par exemple, de MongoDB à CouchDB (ou vice versa), vous devrez faire plus que migrer les données. Vous devrez également vous adapter aux différences d’accès aux données et aux métaphores programmatiques. En d’autres termes, vous devrez réécrire les parties de votre application qui accèdent à la base de données. 

Talents NoSQL 

Un autre inconvénient de NoSQL est le manque relatif de compétences. Alors que le marché des talents SQL classiques est assez important, le marché des compétences NoSQL est naissant. 

À titre de référence, Indeed.com indique qu’en 2022, le volume des offres d’emploi pour les bases de données SQL classiques (MySQL, Microsoft SQL Server, Oracle Database, etc.) restera supérieur au volume des offres d’emploi pour MongoDB, Couchbase et Cassandra. La demande d’expertise NoSQL reste une fraction du marché des compétences SQL. 

Fusionner SQL et NoSQL 

Nous pouvons nous attendre à ce que certaines des différences entre les systèmes SQL et NoSQL disparaissent avec le temps. Déjà, de nombreuses bases de données SQL acceptent désormais les documents JSON comme type de données natif et peuvent effectuer des requêtes sur ces données. Certaines disposent même de moyens natifs pour imposer des contraintes aux données JSON, de sorte qu’elles sont traitées avec la même rigueur que les données conventionnelles en lignes et en colonnes.

D’un autre côté, les bases de données NoSQL ajoutent non seulement des langages de requête de type SQL, mais aussi d’autres caractéristiques des bases de données SQL traditionnelles, telles que les propriétés ACID de MongoDB. 

Il est probable que les futures générations de bases de données, ainsi que les futures versions des systèmes de bases de données actuels, seront à cheval sur les paradigmes et offriront à la fois des fonctionnalités SQL et NoSQL, contribuant ainsi à rendre le monde des bases de données moins fragmenté. Par exemple, Azure Cosmos DB de Microsoft utilise un ensemble de primitives sous le capot pour reproduire de manière interchangeable les comportements des deux types de systèmes. Google Cloud Spanner combine le SQL et la cohérence forte avec l’évolutivité horizontale des systèmes NoSQL.

Néanmoins, les systèmes purement SQL et purement NoSQL auront leur place pendant de nombreuses années encore. Il faut se tourner vers les systèmes NoSQL dans les scénarios où la flexibilité de la conception, l’évolutivité horizontale et la haute disponibilité sont des considérations plus importantes que la cohérence de lecture forte et les autres protections communes aux bases de données SQL. Pour de nombreuses applications, ces garanties pourraient bien valoir la peine d’être échangées contre ce qu’offre NoSQL.