Le document présente les bases de données NoSQL, leurs historiques, défis et types, en contrastant avec les bases de données relationnelles. Il décrit le théorème CAP, qui stipule qu'un système ne peut assurer simultanément cohérence, disponibilité et tolérance aux partitions. Différents modèles de stockage NoSQL, tels que les systèmes orientés clé-valeur, colonne, document et graphe, sont également analysés pour souligner leurs avantages et inconvénients par rapport à un schéma rigide des bases relationnelles.

1. BASES DE DONNÉES
NOSQL
Licence : SIR/SD
Année
Module
:
: 2024-2025
Big Data
Prof. : Y.RACHIDI - y.rachidi@uiz.ac.ma

2. I
.
Introduction aux
systèmes NoSQL
1. Historique des générations des bases de
données
2. Nouveaux défis pour les bases de données
3. Définition bases de données NoSQL

3. Historique: Prenons un peu de
recul !
On distingue 3 révolutions des bases de données:
1. Génération dite Pré-Relationnelle: a été déclenchée
par l'émergence de l'ordinateur électronique.
2. Génération dite Relationnelle: a été déclenchée par
l'émergence de la base de données relationnelle.
3. Génération dite NoSQL (Not only SQL): a entraîné une explosion
d'alternatives aux bases de données relationnelles, motivées par
les exigences des applications modernes qui nécessitent une
portée mondiale et une disponibilité continue.

4. Historique : Chronologie
Chronologie des principales versions et
innovations dans les bases de données
6

5. De nouveaux besoins
apparaissent …

6. De nouveaux besoins
apparaissent …
Big Data: c’est un terme en constante évolutivité !
Caractérisation par :
• Volume – high volume : la quantité de données générées par
des entreprises ou des personnes.
• Vitesse (rapidité) – high Velocity : la fréquence à laquelle
les données sont générées, capturées ,visualisées et
partagées.
• Variété- high variety : La prolifération de types de données
provenant de sources comme les réseaux sociaux, les interactions
Machine-to-
Machine et les terminaux mobiles, crée une très grande diversité au-

7. Big Data : Gartner's
definition, 2001
Vélocit
é
Volume
Variété

8. De nouveaux besoins
apparaissent …
D’autres Vs se rajoutent aux dimensions des Big Data :
• Véracité - veracity : Avoir beaucoup de données dans des
volumes différents à grande vitesse est sans valeur, si ces
données sont incorrectes.
• Variabilité - variability : On définit la variabilité dans le contexte
de la sémantique, comme la "variance de sens dans le lexique".
Déchiffrer la signification exacte d'un mot dans ce contexte.
• Valeur - value : Il faut pouvoir tirer profit des Big Data.
• …

9. Limites des bases de données
relationnelles
Les dimensions des Big Data ont montré les limites des bases
de données relationnelles traditionnelles.
• Le stockage des données est défini dans l'ordre des
pétaoctets, exaoctets, etc. en volume par rapport aux limites
de stockage actuelles (gigaoctets et téraoctets).
• Il peut y avoir plusieurs types de données (structurées,
semi- structurées et non-structurées) pour le Big Data.
...

10. Limites des bases de données
relationnelles
...
• Le Big Data comprend plusieurs types de sources de
données (capteurs, machines, mobiles, sites sociaux, fichiers
journaux, données opérationnelles, etc.).
• Les données sont sensibles au facteur temps (quasiment en
temps réel, et en temps réel).
Donc, nous avons besoins de systèmes de gestion de
données : Plus rapide, plus efficace et flexible !!!

11. Définition d’un système NoSQL
D'après Wikipédia :
« NoSQL (interprété comme « pas seulement SQL ») est une
large classe de systèmes de gestion de bases de données
identifiés par sa non-adhésion au modèle de système de gestion
de bases de données relationnelles. »
Le terme NoSQL est utilisé pour désigner la classe de bases de
données qui ne suivent pas les principes du système de gestion de
bases de données relationnelles (SGBDR), et qui sont spécifiquement
conçues pour tenter de résoudre les problèmes d'évolutivité et de
disponibilité
.

12. II.
Théorème de CAP
1. Propriétés BASE
2. Théorème CAP
3. Types de stockage NoSQL
4. Comparaison des contextes : Relationnel et
NoSQL

13. Rappel: Les propriétés ACID
Dans le contexte relationnel, les transactions (séquences
d'opérations / requêtes) respectent « les propriétés ACID » :
✔
✔
✔
✔
Atomicité : Une transaction s’effectue entièrement ou pas du tout
Cohérence : Le contenu d’une base doit être cohérent au début et à
la fin d’une transaction
Isolation : Les modifications d’une transaction ne sont
visibles/modifiables que quand celle-ci a été validée
Durabilité : Une fois la transaction validée, l’état de la base est
permanent (non affecté par les pannes ou autre)
Attention ! Ces propriétés ne sont pas applicables dans un
contexte
distribué tel que le NoSQL.

14. Les propriétés BASE
Les propriétés BASE caractérisent les systèmes NoSQL :
→ Basically Available : quelle que soit la charge de la base de
données (données/requêtes), le système garantie un taux de
disponibilité de la donnée.
→ Soft-state : La base de données peut changer lors des mises à
jour ou lors d'ajout/suppression de serveurs. => Les systèmes
NoSQL n'ont pas à être cohérents à tout instant.
→ Eventually consistent : À terme, la base de données atteindra un
état cohérent.
• Le contexte NoSQL, nous oblige à relâcher certaines contraintes,
telles que la synchronisation des réplicas, pour favoriser l'efficacité.

15. Théorème de Brewer (CAP-
Theorem)
Théorème CAP (Eric A. Brewer,2000):
« Il est impossible pour un système informatique distribué de
fournir simultanément la cohérence, la disponibilité et la
tolérance de partition (distribution), au maximum deux des
trois peuvent être fournis à un moment donné. »
→ Consistency (Cohérence) : Une donnée n'a qu'un seul état visible
quel que soit le nombre de réplicas
→ Availability (Disponibilité) : Tant que le système tourne, la donnée
doit être disponible.
→ Partition Tolerance (Distribution) : Quel que soit le nombre de
serveurs,

16. V1 → V2
Stratégies des systèmes de
gestion des bases de données : 1-
CA
C A = Consistency + Availability
• Lors d'opérations concurrentes sur
une
même donnée, les requêtes R1 et R2
retournent la nouvelle version (v2) et
sans délai d'attente.
• Cette combinaison n'est possible que
dans le cadre de bases de données
transactionnelles telles que les SGBDR.
Opération d’écriture R1 R2

17. R1 R2
V1 → V2 V1 → V2
synchrone
Stratégies des systèmes de
gestion des bases de données : 2-
CP
CP = Consistency + Partition Tolerance
• Distribuer les données sur plusieurs
serveurs en garantissant la tolérance
aux
pannes (réplication).
• Vérifier la cohérence des données en
garantissant la valeur retournée
malgré des mises à jour
concurrentielles.
• La gestion de cette cohérence nécessite
un protocole de synchronisation des
réplicas, introduisant des délais de
latence dans les temps de réponse.
Opération d’écriture
attent
e

18. V1 → V2 V1
asynchrone
Stratégies des systèmes de
gestion des bases de données : 3-
AP
AP = Availability + Partition Tolerance
• Fournir un temps de réponse rapide tout
en distribuant les données et les
réplicas. R1 R2
• Les mises à jour sont asynchrones sur
le réseau, et la donnée est
"Eventually Consistent".
• Les temps de réponses sont
appréciables, mais le résultat n'est
pas garanti à 100% lorsque le
nombre de mises à jour
simultanées devient
important.
Opération d’écriture

19. Récap. Triangle du théorème de
CAP
A
Availabilit
y
Légende:
BDs orientées Clé-
Valeur BDs orientées
Colonne BDs orientées
Document BDs
orientées Graphe BDs
Relationnelles
P
Partition
Tolerance
CAP
MongoDB BigTable
CosmosDB HBase
C
Consistency

20. Types de stockage NoSQL
1) Stockage orienté Clé-
Valeur
2) Stockage orienté Colonne
3) Stockage orienté
Document
4) Stockage orienté Graphe

21. Stockage orienté Clé/Valeur
• Stockage des données sous forme de pairs de clés avec leurs valeurs.
• Les bases de données orientée clé/valeur représentent le modèle le
plus simple des systèmes de stockage NoSQL.
➢
➢
La clé identifie la donnée de manière unique et permet de la
gérer. La valeur contient n'importe quel type de données.
• Seules les opérations de type CRUD peuvent être
utilisées :
●
●
●
●
Create (key,value)
Read (key)
Update
(key,value) Delete
(key)

22. ID N O M PRENOM AGE FONCTION
AA01 Omari Yassine 23 Développeur
EC13 Benani Asmae 34
BB10 Mansouri Ahmed Professeur
AA01
NOM: Omari
PRENOM: Yassine
AGE: 23
FONCTION:
Développeur
Stockage orienté Clé/Valeur
Stockage orienté ligne Stockage orienté Clé/Valeur
BB10
EC13
NOM: Mansouri
PRENOM: Ahmed
FONCTION: Professeur
NOM: Benani
PRENOM: Asmae
AGE: 34

23. Clés Valeurs

24. Stockage orienté Clé/Valeur
Exemples de systèmes de stockage orientés Clé/Valeur :
−Redis (VMWare)
−Memcached (Danga)
−Azure CosmosDB (Microsoft)
−SimpleDB (Amazon)
−Voldemort (développement LinkedIn puis open source)

25. Stockage orienté Colonne
• Stockage des données en colonnes plutôt qu’en lignes.
• Les systèmes de stockage orientés colonnes sont optimisées
pour les requêtes sur de grands ensembles de données.
• Les requêtes se concentrent sur une ou plusieurs colonnes,
sans avoir à traiter les informations inutiles que comportent
les autres colonnes.

26. ID N O M P RENOM AGE FONCTION
AA01 Omari Yassine 23 Développeur
EC13 Benani Asmae 34
BB10 Mansouri Ahmed Professeur
ID N O M
AA01 Omari
EC13 Benani
BB10 Mansouri
ID P RENOM
AA01 Yassine
EC13 Asmae
BB10 Ahmed
Stockage orienté Colonne
Stockage orienté ligne Stockage orienté Colonne
ID AGE
AA01 23
EC13 34
ID FONCTION
AA01 Développeur
BB10 Professeur

27. Stockage orienté Colonne
Exemples de systèmes de stockage orienté orientées
Colonne:
• Cassandra (Apache)
• BigTable (Google)
• HBase (Apache pour Hadoop)
• Spark SQL (Apache pour Spark)
• Elasticsearch (elastic)
• Vertica (Vertica)

28. Stockage orienté Document
• Stockage des données sous forme de pairs de clés associées à
des structures de données complexes, appelées
"documents".
• Les documents peuvent contenir de nombreuses paires
clé/valeur ou clé/tableau différentes, voire des documents
imbriqués.
• Il existe des langages d'interrogation riches permettent de
manipuler chaque attribut du document (et sous-documents)
tout en passant à l'échelle.
• La plupart des bases de données disponibles dans cette catégorie
utilisent XML, JSON, BSON ou YAML, avec un accès aux données
généralement via

29. Stockage orienté
Document
Stockage orienté ligne Stockage orienté Document
Clés
ID N O M P REN O M AGE FONCTION
AA01 Omari Yassine 23 Développeur
EC13 Benani Asmae 34
BB10 Mansouri Ahmed Professeur
{ {
’’_id’’: ‘’EC13’’,
‘’NOM’’: ‘’Benani’’,
‘’PRENOM’’:
‘’Asmae’’,
‘’AGE’’: ‘’34’’
}
{
’’_id’’: ‘’BB10’’,
‘’NOM’’: ‘’Mansouri’’,
‘’PRENOM’’:
‘’Ahmed’’,
‘’FONCTION’’:
‘’Professeur’’
}
Documents
’’_id’’: ‘’AA01’’,
‘’NOM’’: ‘’Omari’’,
‘’PRENOM’’: ‘’Yassine’’,
‘’AGE’’: ‘’23’’,
‘’FONCTION’’:
‘’Développeur
’’
}
EC13
AA01 BB10

30. Stockage orienté
Document
{
• Un document peut
contenir : des tableaux, des
tableaux de tableaux, des
documents, …
• On dit que «
l’imbrication est sans
limite » !
• Voici un exemple de
contenu de document (en
JSON) :
"EmployeeID":
"MM2",
"FirstName" :
"Anand", "Age" : 34,
"Salary" : 5000000,
"Address" : {
"Line1" : "123, 4th
Street", "City" :
"Bangalore", "State" :
"Karnataka"
},
"Projects" : [
"nosql-
migration", "top-
secret-007"
}

31. Stockage orienté Document
Exemples de systèmes de stockage orientés
Document:
− MongoDB (MongoDB)
− CouchDB (Apache pour Hadoop)
− DynamoDB (Amazon)

32. Stockage orienté Graphe
• Stockage des données et de leurs relations sous forme de graphe,
c,à,d. : les nœuds, les liens et des propriétés sur ces nœuds et ces
liens.
• Les relations représentées peuvent inclure des relations sociales
entre des personnes, des liaisons de transport entre des lieux ou
des topologies de réseau entre des systèmes connectés.
• Les requêtes que l'on peut exprimer sont basées sur la gestion
de chemins, de propagations, d'agrégations, voire de
recommandations.
Remarque:
Les trois premières familles NoSQL n'adressent pas le problème

33. Stockage orienté Graphe
Stockage orienté ligne Stockage orienté Graphe
Agadir
Développeur Professeur
EC13
NOM: Benani
PRENOM:
Asmae
Age:34
BB10
NOM:
Mansouri
PRENOM:
Ahmed
ID N O M PR ENO M AGE FONCTION
AA01 Omari Yassine 23 1
EC13 Benani Asmae 34 2
BB10 Mansouri Ahmed 2, 1
ID INTITULE LIEU
1 Développeur Agadir
2 Professeur Agadir

34. Stockage orienté Graphe
• Les systèmes de stockage orientés Graphe sont
relativement nouveaux sur le marché avec seulement
quelques solutions éprouvées.
• Exemples de systèmes de stockage orientés Graphes:
• Neo4j
• OrientDB (Apache)
• FlockDB (Twitter)

35. Comparaison - 1
(+) (-)
Sys.
Orienté Clé-
Valeur
• Facilement sécable
• Temps d’écriture/lecture très bas
• Disponibilité
• Mise à jour compliqué
•Requêtes primaires :
interrogation sur une clé
Sys.
Orienté
Colonne
• Capacité de stockage accrue
• Accès rapide aux données
• Requêtes limitées
•Limitation du nombre de
types d’objets
Sys.
Orienté
Document
•Modèle de données simple
mais puissant
• Requêtes plus complètes
• Flexibilité
• Evolutif au cours du temps
• Duplication des données
•Cohérence difficile (pas de
modèles interconnectées)
• Modèle limité à des clés
Sys.
Orienté
Graphe
•Adaptées à la gestion des
données relationnelles
• Architecture modulable
• Limitées à certains cas

36. Comparaison -
2 Performance Evolutivité Flexibilité Complexité Fonctionnalité
Sys. Orienté
Clé-Valeur
Elevé Elevé Elevé Aucune --
Sys. Orienté
Colonnes
Elevé Élevé Modéré Faible --
Sys. Orienté
Documents
Elevé Élevé Élevé Faible --
Sys. Orienté
Graphe
Variable Variable Elevé Elevé Théorie
des
graphes
B D
Relationnelle
Variable Variable Faible Modéré Algèbre
relationne
l

37. Différences entre BDs
relationnelles vs. NoSQL : Schéma
●
●
●
Une base de données
relationnelle suit un
schéma rigide.
Les tables de la base de
données doivent avoir
une définition de toutes
les colonnes souhaitées
et de leurs types.
Toute manipulation de
données qui s'écarte du
schéma génère une
erreur.
Contexte Relationnel Contexte NoSQL
●
●
●
Une base de données NoSQL
n'impose pas de schéma
rigide
Elle permet de stocker les
données non structurées
avec des structures
dynamiques.
Cela permet une structure
de base de données
évolutive.

38. Différences entre BDs
relationnelles vs. NoSQL : Modèle
de données
●
●
●
Les données sont
stockées dans des
tableaux.
Chaque enregistrement est
stocké sous forme de ligne
contenant des informations
sur toutes les colonnes.
La modification d'une table
peut affecter les autres
tables et applications.
Contexte Relationnel Contexte NoSQL
●
●
●
Les données sont stockées
dans différents formats selon
le fournisseur.
Les structures de stockage
standard sont des documents,
des graphiques, des valeurs-clés
et des colonnes larges.
Aucune modification n'est
requise car la base de données
s'adapte à la nature dynamique
des données et l'application
fonctionne de manière
transparente.

39. Différences entre BDs
relationnelles vs. NoSQL :
Normalisation
●
La normalisation est le processus utilisé pour supprimer
les données en double et éviter les anomalies de
données.
Contexte Relationnel
●
●
Une base de données
relationnelle évite les
anomalies de données grâce
à la normalisation.
Cela nécessite de stocker les
données dans différentes
tables et de créer des
relations entre elles.
Contexte NoSQL
●
Les bases de données NoSQL
se concentrent davantage
sur la récupération rapide
des données, et les données
peuvent être dénormalisées.

40. Différences entre BDs
relationnelles vs. NoSQL : Mise à
l'échelle
●
La mise à l'échelle est la capacité d'une base de données
à augmenter ou à réduire sa taille, en fonction des
besoins.
●
Les bases de données
relationnelles sont difficiles à
mettre à l'échelle et sont
généralement mises à
l'échelle verticalement, ce qui
signifie augmenter le calcul
et le stockage de la machine.
Contexte Relationnel Contexte NoSQL
●
●
Les bases de données
NoSQL offrent une mise à
l'échelle verticale et
horizontale.
En mise à l'échelle horizontale,
les données peuvent être
réparties sur différentes
machines/clusters.