Bases de données non relationnelles

Les chapitres Bases de données relationnelles et Modélisation de données ont présenté les points forts du modèle relationnel : un schéma clair, des transactions ACID fiables et des requêtes SQL simples pour filtrer, joindre et agréger les données.

Ses limites apparaissent surtout avec des données très variées, un schéma qui change souvent ou une distribution sur de nombreux serveurs.

Les bases NoSQL répondent à ces besoins avec des modèles plus flexibles, des accès rapides et une montée en charge horizontale. Elles complètent les bases relationnelles.

NoSQL : quatre modèles courants

NoSQL convient aux données variées, aux schémas changeants et aux accès rapides à grande échelle. Ces bases peuvent contenir des données structurées, semi-structurées ou non structurées, par exemple des documents, des e-mails, des images ou des événements.

Les quatre familles NoSQL : document, graphe, clé-valeur et colonnes larges.
Figure 27. Les quatre familles de bases NoSQL. Source : GeeksforGeeks.
Type Principe Exemple Utilisation typique
Clé-valeur Paires clé / valeur Redis Cache, sessions, recherche rapide
Document Documents JSON ou BSON MongoDB Données web et API
Colonnes larges Données rangées par familles de colonnes Cassandra Big Data et temps réel
Graphe Nœuds et arêtes Neo4j Réseaux sociaux et recommandations

Le terme « sans schéma fixe » doit être nuancé : beaucoup de bases NoSQL autorisent un schéma plus souple, mais une application a toujours besoin de règles pour conserver des données de qualité.

Avantages et limites

Atouts Points de vigilance
Schéma flexible pour des données variées ou qui évoluent souvent Les requêtes complexes et les jointures sont parfois moins naturelles qu’en SQL
Bonnes performances pour des accès ciblés et de gros volumes Chaque produit offre ses propres garanties de transaction et de cohérence
Répartition de la charge facilitée dans de nombreux systèmes Les opérations critiques, comme un paiement, exigent des garanties explicites

Le modèle BASE

Le vocabulaire BASE (Basically Available, Soft State, Eventual Consistency) est souvent associé aux systèmes distribués qui privilégient la disponibilité et la montée en charge. Il accepte que certaines copies d’une donnée soient temporairement différentes avant de converger.

Lettre Idée simple
B : Basically Available Le système répond, même si une donnée peut être temporairement ancienne ou incomplète.
S : Soft State L’état peut évoluer pendant la synchronisation entre les copies.
E : Eventual Consistency Si les échanges reprennent et qu’il n’y a plus de modifications concurrentes, les copies finissent par converger.

BASE n’est pas l’opposé automatique d’ACID, ni une règle imposée à toutes les bases NoSQL. C’est une manière simple de décrire un compromis courant dans les systèmes distribués.

Le théorème CAP

Le théorème CAP sert à raisonner sur les bases distribuées. Lorsqu’une panne réseau sépare des nœuds, un système ne peut pas garantir simultanément une cohérence stricte et une disponibilité totale. Il faut alors choisir le comportement le plus adapté au besoin.

Théorème CAP : en présence d’une partition réseau, cohérence linéarisable et disponibilité totale ne peuvent pas être garanties simultanément. Théorème CAP : en présence d’une partition réseau, cohérence linéarisable et disponibilité totale ne peuvent pas être garanties simultanément. En présence d’une partition : C et A ne sont pas garantissables ensemble. C · Cohérence Toute lecture voit la dernière écriture (linéarisabilité). A · Disponibilité Toute requête adressée à un nœud non défaillant reçoit une réponse. P · Tolérance au partitionnement Le système tolère des messages perdus ou retardés entre les nœuds. CA Cohérent et disponible : seulement hors partition. CP Sacrifier certaines réponses pour préserver la cohérence. AP Préserver les réponses, quitte à retourner une version ancienne.
Figure 28. Théorème CAP : propriétés des bases distribuées.
  • Un fil d’actualité peut accepter un résultat légèrement ancien afin de rester disponible.
  • Un paiement doit éviter un double débit ou un solde incohérent : on privilégie alors des garanties de cohérence et de transaction fortes.
NoteÀ retenir
  • Utiliser une base relationnelle lorsque les relations, les contraintes et les transactions sont prioritaires.
  • Utiliser une base NoSQL lorsque les accès, la flexibilité du schéma ou la distribution sont prioritaires.
  • BASE décrit un compromis courant entre disponibilité et convergence des données.
  • CAP rappelle qu’en cas de panne réseau, il faut choisir entre cohérence stricte et disponibilité totale.
  • Les bases NoSQL complètent les bases relationnelles ; elles ne les remplacent pas dans tous les usages.