Introduction NoSQL

Table des matière

1. Introduction
a. Qu’est-ce que le NoSQL?
b. Quel est l’intérêt ?
c. SQL vs NoSQL
d. Théorème de Brewer (“CAP Theorem”)
2. Typologie
a. Clé-Valeur
b. Orientées Document
c. Orientées Colonnes Larges
d. Orientées Graphe
3. Conclusion
Introduction
Introduction: Qu’est-ce que le NoSQL?
NoSQL: “Not only SQL”, une classe de système de gestion de base de données hors de la
lignée des systèmes SQL « relationnels » classiques
● Sans modèle de données relationnel
● Ne reposant pas sur le langage SQL pour effectuer des requêtes
● Comportant une architecture distribuée et résiliente en cas de panne
● Utilisant un schéma de données flexible (basé sur XML ou JSON)
● Sans contraintes référentielles ni contraintes de type
Ces bases de données NoSQL ne remplacent pas les bases de données relationnelles
classiques mais complémentent celles-ci
Introduction: Quel est l’intérêt ?
Les bases de données NoSQL ayant été créés pour répondre au besoin du Big Data, il
est évident que ses défis sont ceux du Big Data.
● Capture des données
Gestion des données semi-structurées fournies par plusieurs types de support.

● Stockage des données

● Recherche rapide
● Partage
● Transfert
● Analyse
● Présentation
Introduction: Quel est l’intérêt ?
Que peut-on faire avec ces données ?
● Le NoSQL a été créé dans le but d’analyser les données.
Ainsi, il est possible de :
○ analyser le comportement d’achat des clients
○ analyser les produits les plus vendus
○ prendre des décisions en fonction de ces analyses
○ produire des factures, etc.
● La différence entre le NoSQL et les bases de données traditionnelles, est que
la difficulté de traitement est laissée au code client. Ce qui permet une plus
grande flexibilité, vitesse de traitement et accessibilité.
Introduction: SQL vs NoSQL - Problème d'Évolutivité
(Scaling)
Problématique SQL: Solution NoSQL:

Limitation à l'Évolutivité Verticale : Les Évolutivité Horizontale Simplifiée : Les

SGBD SQL traditionnels sont conçus pour bases NoSQL sont nativement conçues
fonctionner principalement sur un seul pour la distribution des données
serveur. Pour gérer plus de trafic, il faut (sharding ou partitionnement) sur des
rendre ce serveur plus puissant (plus de clusters de serveurs bon marché. Elles
RAM, meilleur CPU), ce qui atteint peuvent gérer des volumes de données et
rapidement des limites physiques et est de requêtes pratiquement illimités en
très coûteux. ajoutant simplement de nouveaux nœuds
(serveurs).
Introduction: SQL vs NoSQL - Problème de Rigidité du
Schéma
Problématique SQL: Solution NoSQL:

Schéma Rigide (Schéma-on-Write) : Schéma Flexible (Schéma-on-Read) :

Exige un schéma de table prédéfini. Les bases NoSQL permettent d'ajouter de
Toute modification de la structure nouveaux champs aux données sans
(ajout/suppression de colonnes) modifier la structure globale de la base.
nécessite une opération coûteuse Cela facilite le stockage de données
(ALTER TABLE) sur la base de données hétérogènes et permet aux applications
entière, ce qui devient problématique d'évoluer rapidement.
avec des jeux de données massifs et
ralentit le développement agile.
Introduction: SQL vs NoSQL - Problème de Gestion
des Données Complexes
Problématique SQL: Solution NoSQL:

Difficulté à Gérer la Dénormalisation : Modèles Spécialisés (Dénormalisation) :

Le modèle SQL excelle dans la Les bases NoSQL permettent de
normalisation, mais pour récupérer des dénormaliser les données, stockant les
données connexes (qui sont réparties sur informations connexes ensemble (ex: un
plusieurs tables), il faut effectuer des document incluant les commandes et les
jointures (JOIN) coûteuses en temps de détails du client). Cela élimine le besoin
calcul. de jointures, rendant les requêtes plus
rapides, notamment pour l'accès aux
données.
Introduction: SQL vs NoSQL - Problème de Gestion
des Données Complexes
Problématique SQL: Solution NoSQL:

Mauvaise Prise en Charge des Données Les bases NoSQL sont idéales pour ces
Non Structurées/Semi-structurées : formats. Les bases Orientées Document
Les données complexes (documents gèrent nativement les structures JSON
JSON imbriqués, données géospatiales, complexes. Les bases Orientées Graphe
logs) doivent être "aplaties" pour rentrer excellent dans la gestion des relations
dans des tables. complexes.
Introduction: SQL vs NoSQL - Problème de Coût
Problématique SQL: Solution NoSQL:

Coût du Matériel Haut de Gamme : Utilisation de Commodités :

L'évolutivité verticale repose sur l'achat L'évolutivité horizontale permet d'utiliser
de matériel de serveur de plus en plus de nombreux serveurs standards et bon
performant et cher. marché (matériel courant), réduisant
considérablement le coût total de
possession (TCO) pour des applications à
grande échelle.
Introduction: SQL vs NoSQL
Une grande application reposant sur une
base de donnée relationnel peut devenir
très coûteuse à cause d’un manque d’
évolutivité.
La base de données relationnelles est à la
merci d’une seule machine coûteuse et
complexe.
La panne de cet machine peut entraîner
la panne du service complet.
Introduction: SQL vs NoSQL
Une base de données NoSQL fonctionne
de manière distribuée sur plusieurs
machines simples
En cas de montée en charge, il suffit
d’ajouter plus de serveurs NoSQL au «
cluster » (= évolutivité horizontale)
La panne d’un serveur NoSQL n’entraine
pas la panne de toute la base de données.
Introduction: SQL vs NoSQL
Pourquoi les systèmes de gestion de bases de données relationnelles (SGBDR)
souffrent-ils de mauvaises performances à grande échelle ?
Chaque transaction sur les BDR doit respecter les contraintes ACID (Atomicité, Consistance,
Isolation, Durabilité)
● Atomicité: toute transaction est soit appliquée entièrement à la base de données, soit
annulée
● Consistance: deux utilisateurs différents interrogeant la base de données obtiennent
les mêmes informations, à moins que cette information n’a été modifiée entretemps
● Isolation: deux transactions s’opérant en parallèle résultent en un état tel que si ces
transactions s’étaient réalisée l’une après l’autre
● Durabilité: une transaction qui s’est exécutée correctement (« committed ») ne se verra
pas annulée si la base de données s’arrête abrubtement (ex: suite à une coupure de
courant)
Introduction: SQL vs NoSQL
Il est difficile de respecter ces contraintes ACID dans un système distribué, tout en
offrant de bonnes performances.
Les systèmes NoSQL ne respectent donc pas toutes ces contraintes, afin de proposer
plus de performances dans un système distribué.
Le relâchement de ces contraintes de la part de la base de données NoSQL a un impact
sur le fonctionnement de l’application, qui doit faire avec !
Introduction: Théorème de Brewer (“CAP Theorem”)
Un système distribué (SD) est un système composé d’un ensemble de machines
(nœuds) interconnectés par un réseau informatique, où chaque machine stocke un
sous-ensemble des données du système (les données peuvent être dupliquées).
Tout SD peut posséder (ou non) les propriétés suivantes:
● Availability (Disponibilité): tout client a accès à l’entièreté des informations
● Consistency (Consistance): les informations observées par deux clients sont
identiques
● Partition Tolerance (Tolérance au partitionnement): le SD continue d’accepter des
requêtes malgré qu’il soit déconnecté en plusieurs sous-SD ne pouvant plus
communiquer entre eux
Tout SD ne peut satisfaire qu’au plus deux des trois propriétés en même temps.
Introduction: Théorème de Brewer (“CAP Theorem”)
Systèmes AC:
Consistency + Availability (Théorique)
Ces systèmes garantissent une
cohérence et une disponibilité parfaites.
Ils ne peuvent pas tolérer de
partitionnement. En réalité, ils
représentent des bases de données non
distribuées (un seul serveur).

Exemple: SGBDR (Système de Gestion de

Base de Données Relationnelle) sur un
seul serveur.
Introduction: Théorème de Brewer (“CAP Theorem”)
Systèmes CP:
Consistency + Partition Tolerance
En cas de partitionnement, le système
sacrifie la Disponibilité pour garantir la
Consistance. Il peut bloquer les requêtes
tant que la cohérence n'est pas
restaurée.

Exemple: NoSQL (ex: MongoDB, Redis en

cluster, Neo4j, Neptune…)
Introduction: Théorème de Brewer (“CAP Theorem”)
Systèmes AP:
Availability + Partition Tolerance
En cas de partitionnement, le système
sacrifie la Consistance pour garantir la
Disponibilité. Il répondra toujours, mais
les clients pourraient lire des données
incohérentes pendant une courte
période.

Exemple: NoSQL (ex: Cassandra,

Couchbase)
Typologie
Typologie: clé-valeur ~ Introduction
Les bases clé-valeur (Key-Value) sont le modèle NoSQL le plus simple et le plus
performant.
Elles stockent l’information sous la forme d’un couple :
clé → valeur

La clé est unique, et la valeur peut contenir n’importe quelle donnée : texte, nombre,
JSON, binaire, liste, etc.

On peut les comparer à un dictionnaire, une map, ou un objet JavaScript en mémoire.

Typologie: clé-valeur ~ Caractéristiques principales
Performances exceptionnelles:La lecture et l’écriture sont extrêmement rapides, car le moteur
fait un accès direct à la clé.
Utile pour:
● caches
● sessions utilisateur
● données temporaires
● compteurs et statistiques en temps réel
Typologie: clé-valeur ~ Exemples
Exemple de donnée:
"user:42" → "{ name: 'Alice', age: 30 }"
"cart:150" → "[102, 203, 904]"
"session:abc123" → "{ expires: 2025-01-10, token: '...' }"

Exemple de requêtes:
● SET user:42 "{'name':'Alice','age':30}"
● GET user:42
● DEL user:42
● …
Typologie: clé-valeur ~ SGBD
et bien d’autres…
Typologie: documents ~ Introduction
Les bases de données orientées documents (Document Stores) sont l'une des familles
les plus populaires du NoSQL.
Elles stockent l’information sous forme de documents — souvent au format JSON,
BSON ou XML — de manière flexible et évolutive.

Chaque document est autonome, structuré et peut contenir des champs imbriqués.
Ces documents sont regroupés par collection.
Typologie: documents ~ Caractéristiques principales
Modèle flexible (schema-less ou schema-light): Pas besoin de définir un schéma à
l’avance. Les documents peuvent évoluer selon les besoins.
Idéal pour :
● les projets en croissance
● les modèles qui changent souvent
Requêtes riches: Contrairement aux bases clé-valeur, on peut effectuer :
● recherches filtrées,pagination
● indexation
● agrégations (pipelines)
● géolocalisation
● recherche textuelle
Typologie: documents ~ Exemples
Insertion: Exemple de donnée:
[Link]({
{
id: 42, _id: ObjectId('67ffa4dec879be32a1bc163a'),
name: "Alice", address: {
building: '1007',
roles: ["admin", "user"],
coord: [
address: { city: "Paris", zip: "75000" } -73.856077,
}); 40.848447

Recherche:
],
street: 'Morris Park Ave',
zipcode: '10462'
Tout les users vivant à Paris },
borough: 'Bronx',
[Link]({ "[Link]": "Paris" }); cuisine: 'Bakery',
grades: [

Tous les noms des restaurants par quartier

{
date: '2014-03-03T00:00:00.000Z',
grade: 'A',
[Link]([
score: 2
{ },
$group: { // …

_id: "$borough", ],
name: 'Morris Park Bake Shop',
restaurants: { $addToSet: "$name" },
restaurant_id: '30075445'
}, }
},
]);
Typologie: documents ~ SGBD
et bien d’autres…
Typologie: colonnes ~ Introduction
Les bases orientées colonnes (Wide Column Stores), sont une famille de bases NoSQL conçues
pour gérer d’énormes volumes de données distribuées sur plusieurs serveurs, tout en offrant des
performances élevées en lecture et écriture.

Elles dérivent du modèle de Google Bigtable, et sont particulièrement utilisées dans les systèmes
Big Data.

Elles stockent les données dans une structure flexible composée de :

● lignes (rows)
● colonnes (columns)
● familles de colonnes (column families)
● tables
Typologie: colonnes ~ Caractéristiques principales
Modèle flexible: Une table peut contenir des milliards de lignes et chaque ligne peut
avoir des colonnes différentes.
Scalabilité horizontale extrême: Ces systèmes sont conçus pour fonctionner sur des
clusters pouvant contenir des centaines de nœuds.
Rangements optimisés par familles de colonnes: Les données d’une même famille
sont stockées ensemble sur disque, ce qui optimise :
● les lectures analytiques
● les filtrages par colonnes
● les opérations massives
Typologie: colonnes ~ Exemples
Les requêtes dans des bases de données orientés colonnes utilise les standard “MySQL”
pour la plupart des commandes (create table, select, insert)
Typologie: colonnes ~ SGBD
et bien d’autres…
Typologie: graphes ~ Introduction
Les bases orientées graphes (Graph Databases) sont une famille de bases NoSQL
conçues pour stocker et interroger des données fortement liées.
Elles reposent sur la théorie des graphes et sont composées de trois éléments :
● Nœuds (nodes) → les entités
● Arêtes (edges / relationships) → les relations entre les entités
● Propriétés (properties) → informations attachées aux nœuds ou aux relations

Leur force principale est de pouvoir naviguer très rapidement dans des réseaux
complexes de relations.
Typologie: graphes ~ Caractéristiques principales
Les relations sont des « citoyens de première classe »: Contrairement aux bases SQL
où les relations sont représentées indirectement (JOIN, tables d’association), ici les
liens existent explicitement. Cela rend les traversées de graphe extrêmement rapides.
Modèle flexible et naturel

Le modèle se rapproche directement de la manière dont on conceptualise :

● réseaux sociaux
● relations de parenté
● systèmes de recommandation
● liens géographiques
● dépendances
Typologie: graphes ~ Exemples
Récupération:
g.V().has("name","San Goku")
.out("PARENT DE")
.out("N_AIME_PAS")
Insertion
[Link]("Person")
.property("name","Freezer")
.property("age",1000)
.as("freezer")
Insertion d’un lien entre 2 entités
g.V().has("name","San Goku")
.addE("N_AIME_PAS").to("freezer")
Typologie: graphes ~ SGBD
et bien d’autres…
Merci pour votre attention.