Qu'est-ce que NoSQL? Bases de données pour un avenir à l'échelle du cloud

L'un des choix les plus fondamentaux à faire lors du développement d'une application est d'utiliser une base de données SQL ou NoSQL pour stocker les données. Les bases de données SQL classiques (c'est-à-dire relationnelles) sont le produit de décennies d'évolution technologique, de bonnes pratiques et de tests de résistance dans le monde réel. Ils sont conçus pour des transactions fiables et des requêtes ad hoc, les bases des applications métier. Mais ils sont également soumis à des restrictions, telles qu'un schéma rigide, qui les rendent moins adaptés à 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 de manière à permettre une vitesse opérationnelle élevée et une grande flexibilité de la part des développeurs. Beaucoup ont été développés par des sociétés comme 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 de NoSQL ne sont cependant pas sans coût. Les systèmes NoSQL ne fournissent généralement pas le même niveau de cohérence des données que les bases de données SQL. En fait, alors que les bases de données SQL ont traditionnellement sacrifié les performances et l'évolutivité des propriétés ACID derrière des transactions fiables, les bases de données NoSQL ont largement abandonné ces garanties ACID pour la vitesse et l'évolutivité.

En bref, les bases de données SQL et NoSQL offrent différents compromis. Bien qu'ils puissent être en concurrence dans le contexte d'un projet spécifique - comme dans lequel choisir pour cette application ou cette application - ils sont complémentaires dans une vue d'ensemble. Chacun est adapté à différents cas d'utilisation. La décision n'est pas tant une question de l'un ou de l'autre que la question de savoir quel outil convient le mieux au travail.

NoSQL contre SQL

La différence fondamentale entre SQL et NoSQL n'est pas si compliquée. Chacun a une philosophie différente sur la manière dont les données doivent être stockées et récupérées.

Avec les bases de données SQL, toutes les données ont une structure inhérente. Une base de données conventionnelle comme Microsoft SQL Server, MySQL ou Oracle Database utilise un schéma, une définition formelle de la manière dont les données insérées dans la base de données seront composées. Par exemple, une colonne donnée dans une table peut être limitée aux entiers uniquement. En conséquence, 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 rend également relativement facile d'effectuer des agrégations sur les données, par exemple au moyen de JOIN.

Avec NoSQL, les données peuvent être stockées sans schéma ou sous forme 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 courants de stockage de données, qui conduisent à quatre types courants de systèmes NoSQL:

  1. Bases de données de documents (par exemple CouchDB, MongoDB). Les données insérées sont stockées sous la forme de structures JSON de forme libre ou de «documents», où les données peuvent être n'importe quoi, des entiers aux chaînes en passant par le texte de forme libre. Il n'est pas nécessaire de spécifier les champs, le cas échéant, qu'un document contiendra.
  2. Magasins de valeurs-clés (par exemple Redis, Riak). Les valeurs de forme libre, des simples entiers ou chaînes aux documents JSON complexes, sont accessibles dans la base de données au moyen de clés.
  3. Magasins de colonnes larges (par exemple HBase, Cassandra). Les données sont stockées dans des colonnes au lieu de lignes comme dans un système SQL classique. N'importe quel nombre de colonnes (et donc de nombreux types de données différents) peuvent être regroupés ou agrégés selon les besoins pour les requêtes ou les vues de données.
  4. Bases de données de graphes (par exemple Neo4j). Les données sont représentées sous la forme d'un réseau ou d'un graphique d'entités et de leurs relations, chaque nœud du graphique étant un bloc de données de forme libre.

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

  1. Vous voulez un accès rapide aux données, et vous êtes plus préoccupé par la rapidité et la simplicité d'accès que par des transactions fiables ou par la cohérence.
  2. Vous stockez un grand volume de données et vous ne voulez pas vous enfermer dans un schéma, car changer le schéma plus tard pourrait être lent et douloureux.
  3. Vous récupérez des données non structurées provenant d'une ou plusieurs sources qui les produisent et vous souhaitez conserver les données dans leur forme d'origine pour une flexibilité maximale.
  4. Vous souhaitez stocker des données dans une structure hiérarchique, mais vous souhaitez 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 auto-référentielles de manière informelle de manière plus complexe à émuler pour les bases de données SQL.

Interroger les bases de données NoSQL

Le langage de requête structuré utilisé par les bases de données traditionnelles offre un moyen uniforme de communiquer avec le serveur lors du stockage et de la récupération des données. La syntaxe SQL est hautement standardisée, donc si les bases de données individuelles peuvent gérer certaines opérations différemment (par exemple, les fonctions de fenêtre), les bases restent les mêmes.

En revanche, chaque base de données NoSQL a tendance à avoir sa propre syntaxe pour interroger et gérer les données. CouchDB, par exemple, utilise des requêtes sous forme de JSON, envoyées via HTTP, pour créer ou récupérer des documents à partir de sa base de données. MongoDB envoie des objets JSON via un protocole binaire, via une interface de ligne de commande ou une bibliothèque de langues.

Certains produits NoSQL peuvent utiliser une syntaxe de type SQL pour travailler avec des données, mais seulement dans une mesure limitée. Par exemple, Apache Cassandra, une base de données de magasin de colonnes, possède son propre langage de type SQL, le langage de requête Cassandra ou CQL. Une partie de la syntaxe CQL est directement issue du playbook SQL, comme les mots-clés SELECT ou INSERT. Mais il n'y a aucun moyen d'effectuer une jointure ou une sous-requête dans Cassandra, et donc les mots-clés associés n'existent pas dans CQL.

Architecture sans partage

Un choix de conception commun aux systèmes NoSQL est une architecture «sans partage». Dans une conception sans partage, chaque nœud de serveur du cluster fonctionne indépendamment de tous les autres nœuds. Le système n'a pas besoin d'obtenir le consensus de chaque nœud pour renvoyer un élément de 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 du partage de rien est la résilience et la montée en charge. La mise à l'échelle du cluster est aussi simple que de créer de nouveaux nœuds dans le cluster et d'attendre qu'ils se synchronisent avec les autres. Si un nœud NoSQL tombe en panne, les autres serveurs du cluster continueront de fonctionner. Toutes les données restent disponibles, même si moins de nœuds sont disponibles 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 conventionnels peuvent être configurés sans partage, bien que cela implique généralement de sacrifier la cohérence à travers le cluster pour les performances.

Limitations de NoSQL

Si NoSQL offre autant de liberté et de flexibilité, pourquoi ne pas abandonner complètement SQL? La réponse simple: de nombreuses applications nécessitent encore les types de contraintes, de cohérence et de garanties fournis par les bases de données SQL. Dans ces cas, certains «avantages» de NoSQL peuvent devenir des inconvénients. D'autres limitations proviennent du fait que les systèmes NoSQL sont relativement nouveaux. 

Pas de schéma

Même si vous prenez des données de forme libre, vous devez presque toujours leur imposer des contraintes pour les rendre utiles. Avec NoSQL, imposer des contraintes implique de transférer la responsabilité de la base de données vers le développeur de l'application. Par exemple, le développeur pourrait imposer une structure via un système de cartographie relationnelle d'objets, ou ORM. Mais si vous voulez que le schéma vive avec les données elles-mêmes , NoSQL ne le fait généralement pas.

Certaines solutions NoSQL fournissent des mécanismes facultatifs de typage et de validation des données. Apache Cassandra, par exemple, possède une multitude de types de données natifs qui rappellent ceux trouvés dans le SQL conventionnel.

Cohérence éventuelle

Les systèmes NoSQL offrent une cohérence forte ou immédiate pour une meilleure disponibilité et de meilleures performances. Les bases de données conventionnelles garantissent que les opérations sont atomiques (toutes les parties d'une transaction réussissent, ou aucune ne le fait), cohérentes (tous les utilisateurs ont la même vue des données), isolées (les transactions ne sont pas en concurrence) et durables (une fois terminées, elles survivront. une panne de serveur).

Ces quatre propriétés, collectivement appelées ACID, sont gérées différemment dans la plupart des systèmes NoSQL. Au lieu d'une cohérence immédiate à travers le cluster, vous avez une cohérence éventuelle , en raison du temps nécessaire pour copier les mises à jour sur d'autres nœuds du cluster. Les données insérées dans le cluster sont éventuellement disponibles partout, mais vous ne pouvez pas garantir quand.

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 soit terminées, soit annulées, ne sont généralement pas disponibles dans NoSQL. Pour tout système où il doit y avoir une «source unique de vérité», comme une banque, l'approche NoSQL ne fonctionnera pas bien. Vous ne voulez pas que votre solde bancaire soit différent selon le guichet automatique auquel vous vous rendez; vous voulez qu'il soit signalé comme la même chose partout.

Certaines bases de données NoSQL ont des mécanismes partiels pour contourner ce problème. Par exemple, MongoDB a des garanties de cohérence pour les opérations individuelles, mais pas pour la base de données dans son ensemble. Microsoft Azure CosmosDB vous permet de sélectionner un niveau de cohérence par demande, afin que vous puissiez choisir le comportement qui correspond à votre cas d'utilisation. Mais avec NoSQL, attendez-vous à une cohérence éventuelle comme comportement par défaut.

Verrouillage NoSQL

La plupart des systèmes NoSQL sont conceptuellement similaires, mais sont implémentés très différemment. Chacun a tendance à avoir ses propres métaphores et mécanismes sur la manière dont les données sont interrogées et gérées.

Un effet secondaire de cela est un degré potentiellement élevé de couplage entre la logique d'application et la base de données. Ce n'est pas si grave si vous choisissez un système NoSQL et que vous vous en tenez à lui, mais cela peut devenir une pierre d'achoppement si vous changez de système plus tard.

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

Compétences NoSQL

Un autre inconvénient de NoSQL est le manque relatif d'expertise. Là où le marché des talents SQL conventionnels est encore assez vaste, le marché des compétences NoSQL est naissant.

Pour référence, Indeed.com signale qu'à la fin de 2017, le volume des offres d'emploi pour les bases de données SQL classiques - MySQL, Microsoft SQL Server, Oracle Database, etc. - reste plus élevé au cours des trois dernières années que le volume d'emplois pour MongoDB, Couchbase et Cassandra. La demande d'expertise NoSQL augmente, mais cela ne représente toujours qu'une fraction du marché du SQL conventionnel.

Fusion de 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 en tant que type de données natif et peuvent effectuer des requêtes sur ces données. Certains ont même des moyens natifs d'imposer des contraintes sur les données JSON, de sorte qu'elles soient gérées avec les mêmes rigueurs que les données classiques de lignes et de colonnes.

D'un autre côté, les bases de données NoSQL ajoutent non seulement des langages de requête de type SQL, mais d'autres fonctionnalités des bases de données SQL traditionnelles. Par exemple, au moins deux bases de données de documents - MarkLogic et RavenDB - promettent d'être conformes à l'ACID.

Ici et il y a des signes que les futures générations de bases de données chevaucheront les paradigmes et offriront à la fois des fonctionnalités NoSQL et SQL. Azure Cosmos DB de Microsoft, par exemple, 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 est une base de données SQL qui combine une forte cohérence avec l'évolutivité horizontale des systèmes NoSQL.

Pourtant, les systèmes SQL purs et NoSQL purs auront leur place pendant de nombreuses années. Faites appel à NoSQL pour un accès rapide et hautement évolutif aux données de forme libre. Cela entraîne quelques coûts, comme la cohérence des lectures et d'autres mesures de protection communes aux bases de données SQL. Mais pour de nombreuses applications, ces sauvegardes peuvent valoir la peine d'être échangées contre ce que propose NoSQL.