Qu’est-ce que NoSQL ? Modèles, différences avec SQL et cas d’usage

Les bases de données NoSQL sont une famille de bases de données qui utilisent des modèles tels que les documents, les paires clé-valeur, les colonnes larges et les graphes, plutôt que de s'appuyer sur le modèle de table relationnelle. Choisissez-en une en fonction de la structure de vos données et des opérations dont votre application a besoin ; le simple label NoSQL ne garantit pas des requêtes plus rapides ni une conception plus simple.

SQL (Structured Query Language) est un langage pour interroger et manipuler des données, tandis que NoSQL est une catégorie couvrant plusieurs modèles. « Not Only SQL » est une façon d'expliquer le nom ; cela ne signifie pas que chaque produit interdit SQL. L'aperçu NoSQL de AWS décrit les différents modèles et objectifs.

Les quatre principaux modèles de données NoSQL

Ces catégories décrivent comment les données sont représentées. Un produit peut prendre en charge plusieurs modèles, et les produits dans la même catégorie peuvent différer en capacités de requête et en opérations.

Bases de données clé-valeur

Un modèle clé-valeur recherche une valeur à l'aide d'une clé comme session:abc123. Considérez-le lorsque l'accès est prévisible, comme la récupération d'une session par son ID. La recherche de conditions arbitraires à l'intérieur des valeurs nécessite de vérifier les fonctionnalités d'indexation et de requête du produit particulier.

Les valeurs n'ont pas besoin d'être de simples chaînes. Redis prend en charge les hachages, listes, ensembles et ensembles triés en plus des chaînes, comme documenté dans sa référence sur les types de données. Pour un cache, décidez également où résident les données faisant autorité, quand les entrées expirent et ce qui se passe lorsqu'une entrée en cache est manquante.

Bases de données de documents

Un document regroupe les champs, tableaux et objets imbriqués d'un élément. JSON (JavaScript Object Notation) est un format texte pour exprimer de telles structures ; MongoDB stocke les documents en utilisant BSON (Binary JSON). Considérez les documents pour les éléments avec différents attributs ou pour des données couramment lues ensemble sur un même écran.

Choisissez entre intégrer des informations liées dans un document et référencer l'identifiant d'un autre document en fonction de la fréquence d'accès, de la taille et des mises à jour. Copier une adresse dans chaque commande peut simplifier les lectures, mais vous devez décider ce que signifie la copie et comment elle est maintenue. Le guide de modélisation MongoDB recommande de concevoir en fonction des schémas d'accès.

Bases de données à colonnes larges

Les modèles à colonnes larges organisent les données autour des clés de ligne ou de partition et des colonnes. Bigtable utilise une carte triée par clé de ligne et regroupe les colonnes liées en familles de colonnes. Sa documentation sur le modèle de stockage explique les lignes, les colonnes et les familles.

Un magasin de colonnes larges ne doit pas être considéré comme identique à un magasin de colonnes analytique qui regroupe les valeurs d'une colonne. Cassandra nécessite une conception de table et de partition orientée vers les requêtes et ne prend pas en charge les jointures relationnelles. Son introduction à la modélisation des données explique pourquoi vous devez d'abord identifier des questions telles que « lire les enregistrements de cet appareil pour cette période ». Vérifiez que le candidat prend en charge les requêtes sur des plages et les agrégations dont vous avez besoin.

Bases de données orientées graphes

Un graphe représente des entités, telles que des personnes, des produits ou des serveurs, comme des nœuds et leurs connexions comme des arêtes. Envisagez-le pour des questions qui suivent les relations, comme identifier les services affectés par une panne de serveur.

Les graphes peuvent également stocker des attributs. Le modèle de graphe à propriétés de Neo4j permet des propriétés à la fois sur les nœuds et les relations, comme expliqué dans son guide sur les concepts des graphes. Un modèle de graphe ne rend pas chaque requête rapide ; définissez la profondeur de parcours, les types de relations et les conditions de chemin.

Comment le NoSQL diffère-t-il d'une base de données relationnelle ?

Un système de gestion de base de données relationnelle (SGBDR) organise les données à l'aide de tables, de clés et de contraintes. Il fournit une base utile pour joindre des enregistrements liés et appliquer des règles communes. Un produit NoSQL offre des opérations appropriées à son modèle, il faut donc comparer comment chaque candidat répond aux questions de votre application plutôt que de copier un schéma existant tel quel.

Stocker des JSON ne nécessite pas automatiquement NoSQL. PostgreSQL, par exemple, propose des types JSON et l'indexation pour jsonb ; voir sa documentation sur les types JSON. Conserver les règles relationnelles et les transactions tout en utilisant des attributs flexibles pour une partie des données est également une possibilité de conception.

Un schéma flexible nécessite encore une conception

Un schéma définit la structure et les règles, telles que les noms de champs, les types et les valeurs obligatoires. Même si les documents peuvent avoir des champs différents, une application a besoin de données prévisibles. Ce catalogue JSON fictif illustre deux produits avec des attributs différents :

[
  {
    "product_id": "book-101",
    "name": "Database Basics",
    "price_krw": 24000,
    "attributes": {
      "author": "Mina Kim",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "Wireless Headphones",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

Les deux produits partagent product_id, name et price_krw, mais leurs attributes imbriqués diffèrent. Une structure de document exprime cette variation de manière naturelle. Mélanger des nombres et des chaînes dans le même champ de prix peut toutefois compliquer le tri et le calcul, donc définissez les types autorisés et la gestion des valeurs manquantes.

MongoDB prend en charge des règles de validation pour les types et les plages de valeurs ; sa documentation sur la validation des schémas explique comment appliquer les règles là où c’est nécessaire. Le CQL (Cassandra Query Language) de Cassandra, en revanche, définit les colonnes et les types lors de la création d’une table, comme montré dans sa référence de définition de table. « Chaque base de données NoSQL est sans schéma » est donc inexact.

JSON décrit une structure ; ce n’est pas intrinsèquement des données non structurées. Décidez séparément si les images et les vidéos doivent être stockées dans une base de données ou dans un stockage d’objets, avec leurs emplacements et métadonnées dans une base de données. La taille des fichiers, les exigences de livraison et les besoins de gestion influencent ce choix.

Vérifiez les garanties de transaction et de cohérence pour chaque produit

Support et portée des transactions

Une transaction considère les modifications comme une unité de travail. ACID signifie Atomicité, Cohérence, Isolation et Durabilité. Pour les modifications qui doivent réussir ou échouer ensemble, comme la création d'une commande et la réduction des stocks, établissez d'abord les garanties nécessaires.

NoSQL n'implique pas l'absence de transactions. MongoDB prend en charge les transactions multi-documents sur des ensembles de réplicas et des clusters partitionnés (sharded clusters), avec des garanties affectées par le déploiement et les paramètres de lecture/écriture ; voir sa documentation sur les transactions. DynamoDB fournit également des API transactionnelles (Interfaces de Programmation d'Applications), mais comporte des restrictions incluant les cibles prises en charge et la portée régionale. Sa référence sur les transactions explique ces limites.

Que peut renvoyer une lecture juste après une écriture ?

Le comportement de réplication est également important. Avec des lectures à cohérence à terme, une écriture récemment terminée peut ne pas encore apparaître dans le résultat d'une lecture. Définissez les exigences selon l'action de l'utilisateur : une commande peut-elle être temporairement absente immédiatement après que l'utilisateur l'a enregistrée ?

Les tables DynamoDB et les index secondaires locaux peuvent utiliser des lectures fortement cohérentes, tandis que les lectures à partir des index secondaires globaux et des flux offrent une cohérence à terme. Consultez sa documentation sur la cohérence des lectures pour les différences selon la cible de la requête. La cohérence ACID au sein d'une transaction et la cohérence des lectures entre les réplicas sont des préoccupations différentes.

La montée en charge horizontale ne garantit pas la performance

La mise à l'échelle horizontale ajoute des serveurs plutôt que de remplacer un serveur par une machine plus grande. Le sharding répartit les données sur plusieurs serveurs ; la réplication maintient des copies. Plusieurs serveurs seuls ne garantissent pas des données équilibrées ni des requêtes plus rapides. L’aperçu du sharding de MongoDB décrit les configurations distribuées séparément.

Une clé mal distribuée peut concentrer les requêtes sur une partition chaude. Par exemple, regrouper chaque événement sous une clé fixe peut nuire à la répartition de la charge. Il faut considérer ensemble les schémas d'accès et la distribution des clés, comme expliqué dans les recommandations sur les clés de partition de DynamoDB.

Les performances dépendent de la taille des données, des index, de la plage de requêtes, du mélange lecture/écriture, des paramètres de cohérence et de la charge de travail. Comparez la latence des requêtes lentes, les échecs et le comportement de récupération ainsi que le temps de réponse moyen. Incluez les répliques, les sauvegardes, le réseau et le travail opérationnel dans l'évaluation des coûts ; la seule catégorie NoSQL n'établit pas un coût inférieur.

Quand devriez-vous envisager NoSQL ?

• Cache à clé connue ou accès aux sessions : envisagez un magasin clé-valeur tout en définissant la durée de vie, la persistance et la synchronisation avec les données faisant autorité.
• Articles de catalogue avec des attributs variables : envisagez des documents tout en concevant la validation des champs partagés et les index de recherche.
• Événements interrogés par une clé et une période connues : envisagez un stockage en colonnes larges tout en vérifiant la taille des partitions et les requêtes sur la plage.
• Parcours de relations en plusieurs étapes : envisagez un graphe lors de la définition des types de connexion et de la profondeur du parcours.

Lorsque différents rapports joignent plusieurs tables ou que des contraintes inter-enregistrements nécessitent une application centralisée, une base de données relationnelle mérite une comparaison précoce. Ne décidez pas uniquement en fonction d'un secteur d’activité ou du volume de données : examinez comment fonctionneraient les lectures et mises à jour les plus importantes pour chaque candidat.

Vous pouvez attribuer différents rôles à différents magasins, tels que l'utilisation d'une base de données relationnelle comme source de référence et d'un magasin clé-valeur comme cache. Des magasins supplémentaires rendent également les mises à jour de copie, la propagation des suppressions et la récupération plus complexes, alors ajoutez-les pour un besoin démontré.

Une séquence d'évaluation pratique

1. Notez les requêtes importantes. Spécifiez les filtres et l'ordre pour des tâches telles que la recherche de produit par ID, les commandes récentes des utilisateurs ou les enregistrements journaliers d'un appareil.
2. Définissez les exigences de validité des données. Enregistrez les modifications qui doivent réussir ensemble, la gestion des demandes en double, les lectures immédiates et les valeurs obsolètes acceptables.
3. Concevez de véritables modèles candidats. Examinez la taille du document, l'intégration ou les références, les index, les clés de partition et les chemins de requête à mesure que les données augmentent.
4. Comparez de petites implémentations. Utilisez les mêmes données et opérations pour reproduire une charge normale, une charge concentrée et des pannes ; enregistrez les versions et les paramètres du produit.
5. Planifiez l'exploitation et la migration. Vérifiez les permissions, la sauvegarde et la restauration, la surveillance, la migration, le coût prévu et une voie de retour vers le magasin existant si nécessaire.

Commencez par les requêtes et les exigences de validité des données, puis choisissez un modèle et un produit qui les satisfont. Si la base de données que vous utilisez déjà répond à ces exigences, établissez la raison pour laquelle il serait nécessaire d'ajouter un autre type de stockage avant de l'introduire.