Bases de données NoSQL

Ce laboratoire présente les bases des bases de données NoSQL, leurs caractéristiques, catégories et différences avec les bases relationnelles classiques. Il permet de comprendre les besoins liés aux données massives et variées, ainsi que les solutions offertes par les SGBD NoSQL. Pour réaliser ce TP, il est nécessaire d’avoir des connaissances de base sur les bases de données relationnelles et une compréhension générale des concepts de données distribuées.

Objectifs

• Comprendre les limites des SGBD relationnels face aux données massives et variées.
• Identifier les caractéristiques principales des bases de données NoSQL.
• Distinguer les différentes catégories de SGBD NoSQL et leurs usages.
• Appréhender les concepts fondamentaux comme le théorème CAP et les modèles ACID vs BASE.
• Connaître les exemples de SGBD NoSQL les plus courants selon leur catégorie.

Prérequis et installation

• Connaissances élémentaires en bases de données relationnelles (modèle relationnel, transactions).
• Notions sur les données structurées, semi-structurées et non structurées.
• Environnement informatique permettant d’exécuter des exemples de bases NoSQL (non fourni dans ce TP).
• Pas de logiciel spécifique requis pour ce TP théorique, mais une documentation sur les SGBD NoSQL peut être utile.

Comprendre les nouveaux besoins liés aux données

Les données actuelles sont très variées : textes (emails, réseaux sociaux), graphiques (cartes, plans), images (photographies, médicales), audio (discours, musique) et vidéo (films, animations). Ces données massives, appelées Big Data, se caractérisent par un volume très important, une grande variété et une vitesse élevée de génération. La problématique est de savoir comment exploiter ces données pour en extraire de la valeur.

Un exemple donné est le volume estimé à 50 zettaoctets créés par an sur le web, avec des données structurées, semi-structurées et non structurées.

Limites des SGBD relationnels

Les SGBD relationnels reposent sur un schéma rigide (schema on write) qui nécessite une modélisation préalable des relations. Les données non conformes sont rejetées, ce qui complique l’évolution du schéma. De plus, la gestion des relations est coûteuse en termes de stockage et de traitement, notamment pour les données volumineuses. Les données non structurées sont mal supportées, le type BLOB étant peu exploitable. Enfin, les transactions distribuées sont difficiles à gérer dans un contexte de données massives et variées.

Caractéristiques des SGBD NoSQL

Les SGBD NoSQL, signifiant Not Only SQL, ne suivent pas le modèle relationnel classique. Ils ne proposent pas de jointures et privilégient le stockage d’agrégats de données ensemble. Les données sont distribuées sur plusieurs serveurs, avec deux types de sharding :

• Sharding vertical : distribution par table (exemple : table Clients sur un serveur, Contrats sur un autre).
• Sharding horizontal : distribution par ligne (exemple : clients de A à M sur un serveur, de N à Z sur un autre).

La plupart des SGBD NoSQL sont open-source et permettent une évolutivité horizontale, c’est-à-dire qu’on peut augmenter la puissance en ajoutant des serveurs.

Ils fonctionnent sans schéma strict, ce qui facilite l’ajout de données sans contraintes structurelles. Ils offrent aussi des mécanismes de réplication pour améliorer la disponibilité :

• Master/Slave : un maître écrit et réplique vers des esclaves qui servent à la lecture.
• Peer to peer : chaque nœud est à la fois producteur et réplicateur des données.

Les SGBD NoSQL proposent des APIs accessibles pour manipuler les données facilement.

Le théorème CAP

Dans un système distribué, trois propriétés sont recherchées :

• Consistency (consistance) : une donnée écrite sur un nœud est immédiatement identique sur les autres.
• Availability (disponibilité) : le système répond toujours aux requêtes, même si certains nœuds sont défaillants.
• Partition tolerance (tolérance au partitionnement) : le système continue de fonctionner malgré des défauts de communication entre nœuds.

Le théorème CAP affirme qu’il est impossible d’avoir simultanément ces trois propriétés. On peut seulement en garantir deux :

• AP : disponibilité et tolérance au partitionnement, mais pas consistance immédiate.
• CP : consistance et tolérance au partitionnement, mais pas disponibilité en cas de partition.
• CA : consistance et disponibilité tant qu’il n’y a pas de partition (rare en pratique).

Modèles ACID vs BASE

Les bases relationnelles respectent le modèle ACID :

• Atomicité : une transaction est intégralement réalisée ou pas du tout.
• Cohérence : le système reste cohérent entre transactions.
• Isolation : les transactions sont indépendantes et sérialisables.
• Durabilité : une fois validée, la transaction survit aux pannes.

Les bases NoSQL suivent plutôt le modèle BASE :

• Basically Available : le système est généralement disponible même si certains nœuds échouent.
• Soft-state : le système peut être temporairement incohérent.
• Eventually consistent : la consistance est obtenue après un délai, via la réplication.

La disponibilité est privilégiée au détriment de la cohérence immédiate.

Catégories des SGBD NoSQL

Wide Column Stores (bases colonnes)

Les données sont organisées en colonnes compactées par ligne, avec une identification unique par ligne. Chaque colonne peut contenir plusieurs familles de colonnes, chacune avec des qualificateurs. Par exemple :

Clé	Estampille	Famille de colonnes Articles	Famille de colonnes Stock
A001	t1 à t6	Groupe, Désignation, Description, Prix	Quantité, localisation

Cette structure permet de gérer des schémas complexes et d’ordonner chronologiquement les valeurs.

Document Store

Une collection regroupe des documents liés à un même domaine (Employés, Articles, Cours). Un document est un ensemble ordonné de paires clé/valeur. Les formats courants sont JSON, BSON et XML. Un document peut être imbriqué dans un autre, ce qui améliore les performances. Ces bases sont sans schéma, la structure est vérifiée par les applications.

{
  'réf' : 'C122',
  'intitulé' : 'Bases de données NOSQL',
  'crédits' : 7,
  'Enseignant' : 'Adel'
}
{
  'réf' : 'C123',
  'intitulé' : 'Programmation Objet',
  'crédits' : 5,
  'Enseignant' : 'Salah'
}

Key-Value Store (Clés-Valeurs)

Chaque donnée est stockée sous forme d’une paire clé/valeur. La clé est une chaîne unique, la valeur peut être simple ou complexe (JSON, BLOB, image, audio, etc.). Les opérations sont basées sur la clé : insertion, suppression, modification, recherche. Un espace de nommage organise ces paires.

Key: C001
Value: {
  'Nom' : 'Ali',
  'Tel' : '22456321',
  'Privilège' : 'Normal'
}

Key: A1
Value: {
  'Catégorie' : 'TV',
  'Marque' : 'Sharp',
  'Prix' : 999
}

Graph Databases (Bases orientées graphe)

Les données sont représentées sous forme de graphes, où les sommets sont des entités et les arcs des relations. Chaque sommet et arc peut stocker des attributs et leurs valeurs. Par exemple :

• Pays : ‘France’, Ville : ‘Paris’, GMT : +2
• Durée : 1h20 entre deux villes

Object Databases (Bases objets)

Ces bases combinent la programmation orientée objet avec les bases de données. Les données sont décrites par un diagramme de classes, avec des méthodes associées aux objets (exemple : ReadData, WriteData, DeleteData).

XML Databases

Basées sur le formalisme XML, ces bases utilisent une DTD comme schéma. Par exemple :

<?xml version="1.0" encoding="UTF-8"?>
<LesCours>
  <Cours c_no="C001">
    <titre>Internet des Objets</titre>
    <credits>5</credits>
    <enseignant>Salah</enseignant>
  </Cours>
  <Cours c_no="C002">
    <titre>Deep Learning</titre>
    <credits>4</credits>
    <enseignant>Alia</enseignant>
  </Cours>
</LesCours>

Multidimensional Databases

Les données sont stockées dans des tableaux multidimensionnels. Par exemple, on peut analyser les ventes selon les dimensions Article, Ville et Type de client. Cela permet d’obtenir des totaux précis, comme le total des ventes de bistouris aux cliniques dans la ville de Gabes.

Multivalue Databases

Un attribut peut être composé (exemple : Patronyme = Nom + Prénom) ou multivalué (exemple : Club avec plusieurs valeurs comme Musique, Dessin, Poésie).

Event Sourcing

Adapté au stockage de l’historique d’événements, ce modèle suit l’état d’un événement donné. Par exemple, pour le suivi des inscriptions aux cours, chaque événement est défini par la date et la personne, et un numéro d’inscription permet de suivre le nombre d’inscrits.

Time Series Databases (Bases de séries chronologiques)

Ces bases gèrent des données associées à des estampilles temporelles périodiques. Exemple : suivi de la qualité de l’air avec des mesures horaires de l’indice de qualité et de la densité des particules fines PM2.5.

Grid and Cloud Databases

Les données sont stockées sur le cloud. Le grid computing accélère l’accès aux données. Le cache as service est un service web qui permet de retrouver rapidement les données fréquemment accédées.

Scientific & Specialized Databases

Ces bases sont adaptées à la gestion des données issues de domaines scientifiques spécifiques.

Exemples de SGBD NoSQL par catégorie

Catégorie	SGBDs
Wide Column	Hadoop, MapR, Cassandra, HBase
Document	MongoDB, Oracle NoSQL Encryption, Azure DocumentDB
Key-Value	DynamoDB, Redis, Azure Table Storage
Graph	Neo4J, FlockDB, Azure Cosmos
Object	Db4o, Versant, ObjectStore
XML	Oracle BerkeleyDB, BaseX, MarkLogic
Multidimensional	Intersystems Cache, GT.M, MiniM DB
Multivalue	jBase, Adabas, Unidata, U2, OpenInsight
Event Sourcing	Event Store, IBM DB2 Event Store, es4j
Time Series	InfluxDB, Kdb+, Prometheus
Grid and Cloud	GridGain, GigaSpaces, Oracle Coherence
Scientific & Specialized	BayesDB, GPUdb

Résultats attendus

Après ce TP, l’étudiant doit être capable de :

• Expliquer pourquoi les bases relationnelles classiques ne suffisent plus pour les données massives et variées.
• Décrire les caractéristiques principales des bases NoSQL, notamment leur distribution, absence de schéma strict et réplications.
• Différencier les catégories de bases NoSQL et leurs cas d’usage.
• Comprendre le théorème CAP et les compromis entre consistance, disponibilité et tolérance au partitionnement.
• Connaître les modèles ACID et BASE et leurs implications.
• Identifier des exemples concrets de SGBD NoSQL selon leur catégorie.

Pièges courants

• Confondre schéma rigide et schéma flexible : les bases NoSQL ne garantissent pas un schéma fixe, ce qui peut poser problème si la structure des données n’est pas contrôlée par l’application.
• Attendre une consistance immédiate dans un système AP (disponible et tolérant au partitionnement) : la cohérence est éventuellement obtenue, pas instantanément.
• Penser que tous les SGBD NoSQL sont identiques : chaque catégorie a ses spécificités et cas d’usage.
• Oublier que les transactions ACID ne sont pas garanties dans la plupart des bases NoSQL.
• Ne pas prendre en compte la complexité de la réplication et du sharding dans la conception des applications.