Université Abdelmalek Essâadi

Faculté poly disciplinaire – Larache

Les Bases de données NoSQL

Master DevOps et Cloud Computing

Présenté par : Pr ELKHADIR Zyad

Email : [Link]@[Link]

Zyad ELKHADIR Base de données NoSQL 1

Plan
1. Rappels

2. BD NoSQL (contexte de création, ACID VS CAP theorem)

3. BD orienté clé-valeur (Exemple de Redis)

4. BD orienté colonnes (Cassandra)

5. BD orienté documents (MongoDB)

6. Moteur de recherche distribué (ElasticSearch)

7. BD orienté graphes (Neo4j)

8. Exposés / Projets
2

Zyad ELKHADIR Base de données NoSQL 2

Rappels / Définition & Historique

Fichiers VS BD
• Base de données (BD) :

 Une base de données est un

ensemble d'informations qui est
organisé de manière à être
facilement accessible, géré et mis
à jour.

 Elle est utilisée par les

organisations comme méthode de
stockage, de gestion et de
récupération de l’informations.

• La multiplication des fichiers entraînait la redondance des données, ce qui rendait

difficile les mises à jour.

 D'où l'idée d'intégration et de partage des données

3

Zyad ELKHADIR Base de données NoSQL 3

Rappels / SGBD

• Les Systèmes de Gestion de Bases de • Les fonctions des SGBD :

Données (SGBD) sont des logiciels qui
permettent de stocker, d'organiser et  Décrire les données (DDL, Create, Drop, Alter)
de manipuler des données de manière
structurée.  Manipuler les données (DML, CRUD)

• La plupart des SGBD modernes  Contrôler les données (DCL, GRANT, REVOKE)
suivent des normes et des standards
pour assurer l'interopérabilité et la  Partage
cohérence dans le domaine des bases
de données.  Sécurité

 Indépendance physique

 Indépendance logique

Zyad ELKHADIR Base de données NoSQL 4

Rappels / SQL

SQL (Structured Query Language) est le langage standardisé utilisé pour interagir avec les
bases de données relationnelles. La standardisation de SQL est gérée par plusieurs
organismes, notamment l'ISO (Organisation internationale de normalisation) et l'ANSI
(Institut national américain de normalisation).

• L'ANSI a défini plusieurs normes SQL, dont SQL-86, SQL-89, SQL-92, SQL:1999,
SQL:2003, SQL:2008, et SQL:2011. Ces normes SQL définissent la syntaxe du langage
SQL ainsi que les fonctionnalités qu'un SGBD doit prendre en charge pour être
conforme à la norme.

• La norme SQL définit des opérations fondamentales pour interagir avec une base de
données, telles que les opérations CRUD (Create, Read, Update, Delete) et les
opérations de gestion des schémas de base de données (CREATE TABLE, ALTER TABLE,
etc.).

Zyad ELKHADIR Base de données NoSQL 5

Rappels / SGBDR

• Plusieurs SGBD relationnels respectent les normes SQL, ce qui signifie qu'ils prennent
en charge un ensemble commun de fonctionnalités et de syntaxe SQL. Quelques
exemples de SGBD relationnels conformes à SQL incluent :

 MySQL : Un SGBD relationnel open-source qui prend en charge SQL et est

largement utilisé dans le monde entier.

 PostgreSQL : Un système de gestion de base de données relationnelle open-source

avec un fort accent sur la conformité aux normes SQL.

 Microsoft SQL Server : Un SGBD développé par Microsoft qui prend en charge SQL
et est souvent utilisé dans les environnements Windows.

 Oracle Database : Un SGBD puissant développé par Oracle Corporation, qui offre
une prise en charge avancée de SQL

Zyad ELKHADIR Base de données NoSQL 6

Rappels / ACID

• Dans les années 1970, le modèle • Le concept de transaction a été formalisé

relationnel a été introduit par Edgar F. dans le cadre du modèle relationnel.
Codd, définissant un ensemble de • Une transaction est une séquence
règles mathématiques pour organiser d'opérations sur la base de données qui doit
les données en tables et établir des être exécutée de manière atomique,
relations entre elles. cohérente, isolée et durable.
• Ces propriétés sont souvent résumées par
l'acronyme ACID (A voir plus loin)

Zyad ELKHADIR Base de données NoSQL 7

Rappels / ACID

Transaction ? Ensemble d'opérations • A : On peut pas la diviser, Si le retrait ne

qui font passer la base de données d'un état marche pas, l’ajout sera ko aussi
A — antérieur à un état B postérieur
 Exemple: Transfert d’argent d’un compte • C : Respect des contraintes d’intégrité
A Vers un compte B (exemple Amount >= 0)

• I: Elle garantit que l'exécution simultanée

des transactions laisse la base de
données dans le même état que celui qui
aurait été obtenu si les transactions
avaient été exécutées séquentiellement

• D : La transaction est sauvegardé dans la

base et les données sont disponibles a
tout moment

Zyad ELKHADIR Base de données NoSQL 8

Rappels / ACID

• Echec d’Atomicité Supposons qu'une transaction tente de soustraire 10 à A

et d'ajouter 10 à B (la transaction contient deux
• Échec de cohérence opérations).

• Échec d'isolation Si, après avoir soustrait 10 à A, la transaction est

interrompue par un problème quelconque sans pouvoir
• Échec de Durabilité ajouter 10 à B, alors la propriété d'atomicité serait violée.

Zyad ELKHADIR Base de données NoSQL 9

 Rappels / ACID

la seule règle est que la somme de A et B doit être 100.

• Echec d’Atomicité
 T1 tente de soustraire 10 de A sans modifier B,
• Échec de cohérence
 Elle retranchera 10 de A et l'atomicité sera respectée.
• Échec d'isolation
 Une validation de cohérence montrera que la somme
• Échec de Durabilité de A et B est égale à 90 et non à 100.

 la cohérence n'est pas respectée

 La transaction sera annulée et la valeur de A sera

augmentée de 10 pour reprendre la valeur qu'elle avait
avant la transaction T1
10

Zyad ELKHADIR Base de données NoSQL 10

Rappels / ACID

• Echec d’Atomicité On suppose que A= 50 et B=50 dans la table

• Échec de cohérence Et on a deux Transactions T1 et T2 qui s’exécutent en

parallèle :
• Échec d'isolation T1:
Le résultat en parallèle

• Part1 : A est réduit de 10 ; Part1 de T1: A est réduit de 10

• Échec de Durabilité Part1 de T2 : B est réduit de 5
• Part2 : B est augmenté de 10 ;
Part2 de T2: A est augmenté de 5
Part2 de T1: B est augmenté de 10
T2:
Si la transaction T1 est interrompue
• Part1 : B est réduit de 5 ; avant sa deuxième partie ?
• Part2: A est augmenté de 5 ; A=40
En cas séquentiel B=45 & A=55 B=45
A=45
11

Zyad ELKHADIR Base de données NoSQL 11

Rappels / ACID

La requête Insert ??
• Echec d’Atomicité
[Link] syntaxique et sémantique
2. Vérification des Verrouillage
• Échec de cohérence 3. Écriture dans la mémoire (RAM)

4. Journalisation : La base de données peut journaliser

• Échec d'isolation
l'opération d'insertion. Cela consiste à enregistrer les
modifications dans un journal (log) pour permettre
une récupération en cas de panne du système.
• Échec de Durabilité 5.Écriture sur le disque dur
6. Validation et déverrouillage
12

Zyad ELKHADIR Base de données NoSQL 12

Base de Données NoSQL / Contexte

• Depuis les années 70, la base

de données relationnelle
était l'incontournable
référence pour gérer les
données d'un système
d'information.

• Le saviez-vous, a partir de
2000 ?

• Les données stockées

augmentent 4 fois plus vite
que l’économie mondiale.

• Environ 2,5 trillions d’octets

de données sont produites
chaque jour.

13

Zyad ELKHADIR Base de données NoSQL 13

Base de Données NoSQL / Contexte

• Schéma flexible

• Évolutivité
• Volume :En constante augmentation horizontale
• Velocity :Données générées rapidement dans
• Modèles de
des temps beaucoup plus courts
données variés
• Variety : géolocalisation, connexion, mesures,
processus, flux, réseaux sociaux, texte, web,
images, vidéos, mails, livres, tweets 14

Zyad ELKHADIR Base de données NoSQL 14

Base de Données NoSQL / Caractéristiques

 La flexibilité du schéma est l'une des caractéristiques clés. Contrairement aux bases de
données relationnelles qui ont un schéma fixe et rigide, les bases de données NoSQL
permettent une plus grande souplesse dans la structure des données. Il existe plusieurs
approches pour implémenter une flexibilité de schéma dans une base de données NoSQL.
Schéma Dynamique : Les bases de données NoSQL, en particulier celles de type documentaire ou orientées
colonnes, permettent souvent un schéma dynamique où chaque document peut avoir des champs différents.
Contrairement aux bases de données relationnelles qui exigent un schéma fixe, les bases de données NoSQL
peuvent évoluer avec les données sans nécessiter de modifications du schéma global.

Ajout de Champs à la Volée : Dans les bases de données NoSQL, il est généralement possible d'ajouter de
nouveaux champs à des documents existants sans avoir à altérer le schéma global. Cela offre une grande
flexibilité pour gérer des données avec des structures variables.

Polyvalence des Types de Données : Les bases de données NoSQL peuvent souvent stocker des données
hétérogènes au sein d'une même collection ou table. Par exemple, un document peut contenir des champs de
différents types (chaînes de caractères, nombres, listes, etc.) sans imposer une structure uniforme.

Facilité d'Évolution : La flexibilité du schéma facilite l'évolution des applications. Les changements dans la
structure des données peuvent souvent être gérés de manière transparente, sans nécessiter des modifications
importantes de la base de données. 15

Zyad ELKHADIR Base de données NoSQL 15

Base de Données NoSQL / Caractéristiques

 L'évolutivité horizontale est l'une des caractéristiques fondamentales des bases de données
NoSQL. Elle se réfère à la capacité d'ajouter de nouveaux nœuds ou serveurs au système
afin d'augmenter la capacité de stockage et de traitement sans avoir besoin de modifier la
structure existante de la base de données.

Distribution des Données : Les bases de données NoSQL sont conçues pour gérer efficacement la distribution
des données sur plusieurs nœuds(machine/serveur). Cela permet à un cluster (ensemble de nœuds) NoSQL de
gérer de grandes quantités de données en les répartissant de manière équilibrée entre les nœuds.

Ajout de Nœuds Facile : Lorsque la charge de travail augmente, il est possible d'ajouter simplement de
nouveaux nœuds au cluster pour augmenter sa capacité. Ce processus est généralement transparent pour les
applications et ne nécessite pas d'arrêt du système.

Évolutivité Linéaire : L'évolutivité horizontale offre souvent une évolutivité linéaire, ce qui signifie que l'ajout de
nœuds supplémentaires au cluster entraîne une augmentation proportionnelle de la capacité et des
performances.

Gestion de la Charge de Travail : Les bases de données NoSQL sont conçues pour gérer efficacement les charges
de travail variables, ce qui permet de faire face à des pics de trafic ou à des besoins soudains de capacité accrue.

16

Zyad ELKHADIR Base de données NoSQL 16

Base de Données NoSQL / Caractéristiques

Résilience et Tolérance aux Pannes : L'évolutivité horizontale contribue également à la résilience du système. En
cas de panne d'un nœud, les autres nœuds peuvent continuer à fournir des services sans interruption
significative.

Sharding : Certains systèmes NoSQL utilisent la technique de sharding, où les données sont divisées en
partitions (shards) qui sont distribuées sur différents nœuds. Cela permet de distribuer la charge et d'améliorer
les performances.

Gestion de la Consistance : Les bases de données NoSQL offrent différentes garanties de consistance, souvent
liées à des modèles de cohérence spécifiques. L'évolutivité horizontale peut influencer les choix de modèles de
cohérence en fonction des besoins de l'application.

 Support d’une variété de modèles de données:

• Modèle de données clé-valeur

• Modèle de données de colonnes
• Modèle de données de documents
• Modèle de données de graphes

17

Zyad ELKHADIR Base de données NoSQL 17

BD NoSQL : ACID VS CAP ?

• ACID ne sont pas applicables dans un contexte distribué tel que le NoSQL. En effet, prenons
l'exemple d'une transaction de cinq opérations (lecture/écriture) : cela implique une
synchronisation entre cinq serveurs pour garantir l'atomicité, la cohérence et l'isolation. Au
final, cela se traduit par des latences dans les transactions (en cours et en concurrence). Ce
qui n'est pas tolérable lorsque justement on veut éviter ces latences en distribuant les
calculs.
• En 2000, Eric A. Brewer a formalisé un théorème très intéressant reposant sur 3 propriétés
fondamentales pour caractériser les bases de données (relationnelles, NoSQL et autres) :

 Consistency (Cohérence) : Une donnée n'a qu'un seul état visible quel que soit le
nombre de réplicas, la dernière version qui doit être lue.

 Availability (Disponibilité) : Tant que le système tourne (distribué ou non), la donnée

doit être disponible, on doit répondre a une requête.

 Partition Tolerance (Distribution) : Quel que soit le nombre de serveurs, toute requête
doit fournir un résultat correct. Le Système devrait marcher mm si une/plusieurs
partition tombent en panne.
18

Zyad ELKHADIR Base de données NoSQL 18

BD NoSQL : Théorème de CAP

• Dans toute base de données, vous ne pouvez respecter au plus que 2 propriétés
parmi la cohérence, la disponibilité et la distribution.

19

Zyad ELKHADIR Base de données NoSQL 19

BD NoSQL : Théorème de CAP : CA

• Le couple CA (Consistency-Availability), il représente le fait que lors d'opérations

concurrentes sur une même donnée, les requêtes L1 et L2 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.

• Modification de donné v1 ===> ca devient v2 (pas de pb de cohérence).

• 2 lecture parallèle , les 2 vont lire v2 (pas de pb de disponibilité).

20

Zyad ELKHADIR Base de données NoSQL 20

BD NoSQL : Théorème de CAP : CP

• CP (Consistency-Partition Tolerance) propose de distribuer les données sur plusieurs serveurs en

garantissant la tolérance aux pannes (réplication). En même temps, il est nécessaire de 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 (L1 et L2 attendent la
synchronisation pour voir v2).

• CP : on a une base répliquée sur 2 serveurs(pas de pb de distribution), lorsque je modifie sur une
donnée v1-->v2 juste sur le premier serveur, après lorsqu'on aura une lecture, on devrait attendre
jusqu'a ce que ca sera modifié sur le deuxième serveur synchronisation (pb de disponibilité)
21

Zyad ELKHADIR Base de données NoSQL 21

BD NoSQL : Théorème de CAP : AP

• Le couple AP (Availability-Partition Tolerance) s'intéresse à fournir un temps de réponse rapide

tout en distribuant les données et les réplicas.
• les mises à jour sont asynchrones sur le réseau, et la donnée est "Eventually Consistent" (L1 voit
la version v2, tandis que L2 voit la version v1). C'est le cas de Cassandra dont 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.
• la cohérence des données est incompatible avec la disponibilité dans un contexte distribué
comme les bases NoSQL.
• AP : pas de pb de disponibilité, si je modifie et j'ai une lecture en parallèle on aura 2 valeurs
différentes (pb de cohérences) , c’est après que la donnée va être changé en v2 sur le deuxième
serveur(asynchrone) 22

Zyad ELKHADIR Base de données NoSQL 22

BD NoSQL : Quiz

1- Que signifie le théorème de CAP ?

a) Cohérence, Accessibilité, Performance
b) Cohérence, Disponibilité, Tolérance au partitionnement
c) Atomicité, Cohérence, Performance

2-Pourquoi est-il impossible d’avoir simultanément les trois propriétés du théorème de CAP ?
a) À cause des limitations du stockage
b) À cause des conflits entre cohérence et disponibilité en cas de partition réseau
c) Parce que les bases de données NoSQL ne respectent pas les contraintes

3-Une base de données qui privilégie Cohérence et Disponibilité (CA) :

a) Peut tolérer des pannes réseau sans impact
b) Ne peut pas être distribuée sur plusieurs nœuds
c) Sacrifie la cohérence pour éviter les délais de réponse

4-Si un système est AP (Disponible et Tolérant aux partitions), alors il :

a) Peut renvoyer des données obsolètes en cas de panne réseau
b) Ne tolère pas les partitions réseau
c) Priorise toujours la dernière version des données

5-Quelle affirmation est correcte concernant une base CP (Cohérence et Tolérance aux partitions) ?
a) Elle garantit toujours des réponses rapides
b) Elle peut être indisponible temporairement en cas de partition réseau
c) Elle sacrifie la tolérance aux pannes réseau pour garantir la cohérence
23

Zyad ELKHADIR Base de données NoSQL 23

BD NoSQL : Quiz

6-Quelle propriété ACID assure que les transactions sont complètement exécutées ou annulées en cas
d’échec ?
a) Atomicité
b) Cohérence
c) Durabilité

7-Un système ACID garantit que :

a) Toutes les transactions sont exécutées immédiatement, même en cas de panne
b) Les transactions sont sûres et exécutées de manière prévisible
c) La base est toujours rapide, quel que soit le volume de données

8-Pourquoi les bases No SQL sacrifient-elles souvent certaines propriétés ACID ?

a) Pour améliorer les performances et la scalabilité
b) Parce qu’elles ne peuvent pas gérer des transactions
c) Parce qu’elles ne respectent pas les principes du théorème de CAP

24

Zyad ELKHADIR Base de données NoSQL 24

 BD Orientées Key/Value

Zyad ELKHADIR Base de données NoSQL 25

BD orienté clé-valeur (Exemple de Redis) : Plan

1. Caractéristiques , Avantages , Inconvénients

2. Les types de données

3. La persistance des données

4. Réplication Vs. Redis Cluster

5. Sécurité

6. Pub/sub

7. Scripting Lua

26

Zyad ELKHADIR Base de données NoSQL 26

Familles Clé / Valeur

27

Zyad ELKHADIR Base de données NoSQL 27

Familles Clé / Valeur

28

Zyad ELKHADIR Base de données NoSQL 28

Familles Clé-Valeur : Caractéristiques

 La valeur contient n'importe quel type de données.

 Le fait d'avoir n'importe quoi implique qu'il n'y ait ni schéma, ni structure pour le stockage.
D'un point de vue de bases de données, il n'y a pas la possibilité d'exploiter ni de contrôler
la structure des données et de fait, pas de langage (SQL = Structured Query Language).

29

Zyad ELKHADIR Base de données NoSQL 29

Familles Clé-Valeur : Avantages

1. Simplicité de modèle:
• Chaque élément est associé à une clé unique, ce qui facilite la modélisation des
données.
2. Accès Rapide:
• L'accès direct par clé permet des opérations rapides de lecture et d'écriture, ce
qui est particulièrement efficace pour les opérations simples et fréquentes.
3. Évolutivité horizontale:
• Les bases de données NoSQL clé-valeur sont souvent conçues pour être
facilement distribuées sur plusieurs serveurs. Si la charge augmente, on peut
simplement ajouter de nouveaux serveurs

4. Flexibilité du schéma:
• Les données ne sont pas liées à un schéma fixe, ce qui permet d'ajouter de
nouveaux champs ou clés sans perturber l'existant.
30

Zyad ELKHADIR Base de données NoSQL 30

Familles Clé-Valeur : Inconvénients

1. Complexité des requêtes :

• Pour des requêtes complexes nécessitant des opérations de jointure ou des
agrégations avancées, une base de données clé-valeur peut être moins
performante qu'une base de données relationnelle.

2. Manque de fonctionnalités transactionnelles :

• Certaines bases de données clé-valeur peuvent ne pas offrir un support
transactionnel robuste, ce qui peut poser problème dans des scénarios
nécessitant des transactions ACID.

3. Limitations dans la recherche :

• Si la recherche nécessite des critères autres que la clé, cela peut être moins
efficace comparé à d'autres modèles de bases de données.
Chercher tous les utilisateurs de Paris peut
nécessiter :
- un scan complet
- un index supplémentaire 31

Zyad ELKHADIR Base de données NoSQL 31

Familles Clé-Valeur : Produits

32

Zyad ELKHADIR Base de données NoSQL 32

 Familles Clé-Valeur / Redis

 Redis est un SGBD NoSQL Open Source orienté stockage clé-valeur.

• La base de données est entièrement gérée en mémoire, le disque n'est utilisé que pour la
persistance
• Redis peut répliquer ses données sur de nombreux serveurs secondaires.

• Il est très rapide avec plusieurs insertions/lectures à la seconde.

• Il supporte plusieurs types de données comme des set, des hash, des listes.

• Les opérations sont atomiques, en cas d'accès concurrents, Redis conservera la valeur mise à
jour.

33

Zyad ELKHADIR Base de données NoSQL 33

 Familles Clé-Valeur / Pourquoi on utilise Redis ?

1- Caching (Mise en cache)

✅ Problème : Une application web subit une forte charge et les requêtes répétées à la base de données ralentissent le
système.
✅ Redis comme solution : Stocker les résultats de requêtes fréquentes en mémoire permet de réduire la latence et diminuer
la charge sur la base de données principale.

🔹 Exemple : Stocker les pages HTML générées d’un site dynamique pour accélérer le rendu.
🔹 Utilisation : SET et GET avec un EXPIRE pour limiter la durée du cache.

• Première requête
→ générée depuis la base → stockée en cache.

• Requêtes suivantes
→ renvoyées directement depuis Redis
→ temps de réponse beaucoup plus rapide.

34

Zyad ELKHADIR Base de données NoSQL 34

Familles Clé-Valeur / Pourquoi on utilise Redis ?
2- Session Management (Gestion de sessions)

✅ Problème : Une application avec des millions d’utilisateurs doit gérer des sessions utilisateur de manière rapide et
scalable.
✅ Redis comme solution : Stocker les sessions en mémoire permet un accès ultra-rapide et évite de surcharger une base
SQL.
🔹 Exemple : Stockage des sessions utilisateurs d'un site e-commerce.
🔹 Utilisation : Stockage des tokens d’authentification (JWT, cookies).

Exemple : Un utilisateur se connecte sur un site e-commerce. Stockage de la session dans Redis
1. L'utilisateur saisit son login et mot de passe
2. Le serveur vérifie dans la base SQL
3. Si l'authentification est correcte → une session est créée dans Redis

4. Lors d'une requête suivante

Quand l'utilisateur navigue sur le site :

5. Le serveur sait donc :

• Quel utilisateur fait la requête
• Quel est son panier
• S'il est connecté
⚡ Tout cela sans interroger la base SQL.
35

Zyad ELKHADIR Base de données NoSQL 35

 Familles Clé-Valeur / Pourquoi on utilise Redis ?
3- Leaderboard et Classements en temps réel

✅ Problème : Un jeu en ligne doit afficher un classement des meilleurs joueurs en temps réel.
✅ Redis comme solution : Avec les structures de données ZSET (Sorted Set), Redis permet d'organiser et de trier les scores
efficacement.

🔹 Exemple : Classement des joueurs dans un jeu mobile comme Clash Royale.
🔹 Utilisation : ZADD pour ajouter un score et ZRANGE pour récupérer les meilleurs scores

36

Zyad ELKHADIR Base de données NoSQL 36

 Familles Clé-Valeur / Pourquoi on utilise Redis ?

3- Leaderboard et Classements en temps réel

37

Zyad ELKHADIR Base de données NoSQL 37

 Familles Clé-Valeur / Pourquoi on utilise Redis ?

4- Recherche en mémoire ultra-rapide (Redis Search)

✅ Problème : Une application doit effectuer des recherches textuelles rapides sur un grand volume de données.
✅ Redis comme solution : Redis Search permet d’indexer du texte en mémoire et de faire des recherches avec une latence
très faible.

🔹 Exemple : Recherche de produits sur un site e-commerce en moins de 50 ms.

🔹 Utilisation : Module RediSearch avec des commandes comme [Link], [Link].

38

Zyad ELKHADIR Base de données NoSQL 38

Familles Clé-Valeur / Pourquoi on utilise Redis ?

4- Recherche en mémoire ultra-rapide (Exemple Redis Search)

39

Zyad ELKHADIR Base de données NoSQL 39

 Familles Clé-Valeur / Pourquoi on utilise Redis ?
5- Protection contre les attaques Brute Force

✅ Problème : Un site web veut limiter les tentatives de connexion excessives pour éviter des attaques
par force brute.
✅ Redis comme solution : Utiliser un compteur temporaire pour bloquer un utilisateur après plusieurs
échecs de connexion.

🔹 Exemple : Bloquer une adresse IP après 5 tentatives de connexion en 10 minutes.

🔹 Utilisation : INCR avec EXPIRE pour limiter les requêtes.

40

Zyad ELKHADIR Base de données NoSQL 40

Familles Clé-Valeur / Pourquoi on utilise Redis ?

5- Protection contre les attaques Brute Force (exemple)

41

Zyad ELKHADIR Base de données NoSQL 41

Familles Clé-Valeur / Présentation de Redis / Triangle CAP

42

Zyad ELKHADIR Base de données NoSQL 42

Familles Clé-Valeur / Redis : Types de Données

 Redis nous propose différents types de données que l'on peut stocker :

• Des chaînes de caractères,

• Des listes,
• Des sets,
• Des sorted sets,
• Des hashs,
• Des tableaux de bits.

 Nous nous intéresserons a quelques commandes sur les chaînes, les listes,
et les hashs.

 L'ensemble des commandes sur [Link]

43

Zyad ELKHADIR Base de données NoSQL 43

Familles Clé-Valeur / Redis : Exemples de commandes

44

Zyad ELKHADIR Base de données NoSQL 44

Familles Clé-Valeur / Redis : Exemples de commandes

45

Zyad ELKHADIR Base de données NoSQL 45

Familles Clé-Valeur / Redis : Exemples de commandes

46

Zyad ELKHADIR Base de données NoSQL 46

Redis / Persistance des Données

• Redis stocke les données en RAM, mais il propose des mécanismes de

persistance pour éviter la perte de données en cas de redémarrage ou de
crash. Il existe deux principales méthodes :

- RDB (Redis Database Backup) : sauvegarde ponctuelle sous forme de

snapshot.
- AOF (Append-Only File) : journalisation continue des modifications.

47

Zyad ELKHADIR Base de données NoSQL 47

 Redis / Persistance des Données
 RDB (Redis Database Backup) :
• Fonctionnement
- La sauvegarde est déclenchée automatiquement ou manuellement.
- Redis fork, un processus enfant écrit les données sur le disque (binary file
[Link]), ce qui minimise l'impact sur les performances.
- Les sauvegardes peuvent être configurées dans [Link] avec la directive :
save <secondes> <nombre d'écritures> :

• Avantages
- Fichier compact et rapide à charger.
- Idéal pour des sauvegardes périodiques.

• Inconvénients
- Risque de perte de données en cas de crash entre deux snapshots.
- Processus de fork peut consommer des ressources. 48

Zyad ELKHADIR Base de données NoSQL 48

Redis / Persistance des Données / RDB Exemple

49

Zyad ELKHADIR Base de données NoSQL 49

 Redis / Persistance des Données / AOF
 AOF (Append-Only File) :
• Fonctionnement
- Redis journalise toutes les commandes de modification (SET, DEL, HSET, etc.) dans
un fichier texte [Link]
- Lors de redémarrage de Redis , toutes les commandes stockées dans
[Link] seront rejouées pour restaurer l'état exact de la base.
- Pour activer AOF dans [Link]

- Redis offre trois stratégies de persistance AOF configurables avec appendfsync :

50

Zyad ELKHADIR Base de données NoSQL 50

Redis / Persistance des Données / AOF Exemple

51

Zyad ELKHADIR Base de données NoSQL 51

Redis / Persistance des Données / RDB Vs AOF

Critère RDB (Redis Database Backup) AOF (Append-Only File)

Méthode de sauvegarde Snapshot périodique de toutes Journalisation des commandes

les données
Format Fichier binaire ([Link]) Fichier texte ([Link])

Fréquence d’écriture À intervalles définis (save dans À chaque commande modifiant

[Link]) les données
Performance Moins d’impact sur la Plus d’écritures → plus d’impact
performance
Durabilité des données Risque de perte entre 2 Plus fiable, perte max de 1
snapshots seconde (appendfsync everysec)

Taille sur disque Plus compact Peut devenir très volumineux

Vitesse de récupération Chargement rapide Relecture plus lente (commande
par commande)
Réécriture optimisée Pas nécessaire, car snapshot BGREWRITEAOF pour compacter
complet le fichier
Cas d’usage recommandé Sauvegarde périodique, faible Haute disponibilité,
charge minimisation des pertes 52

Zyad ELKHADIR Base de données NoSQL 52

BD orienté clé-valeur (Exemple de Redis) : Plan

1. Caractéristiques , Avantages , Inconvénients

2. Les types de données

3. La persistance des données

4. Réplication Vs. Redis Cluster

5. Sécurité

6. Pub/sub

7. Lua Scripting

53

Zyad ELKHADIR Base de données NoSQL 53

Redis / QUIZ

54

Zyad ELKHADIR Base de données NoSQL 54

Redis / Réplication vs. Cluster Redis

55

Zyad ELKHADIR Base de données NoSQL 55

Redis / Principe de la réplication

- Redis prend en charge un modèle Maître-Esclave où un serveur maître

gère les écritures et plusieurs esclaves répliquent ses données.
- Cette approche permet de distribuer la charge des lectures et de fournir
une redondance des données en cas de panne du maître

56

Zyad ELKHADIR Base de données NoSQL 56

Redis / Principe de la replication / Mise en place

- Lancer un serveur Redis (Maître)

- Lancer un serveur Redis (Esclave) qui réplique les données du maître :

- Configurer l’esclave pour suivre le maître :

- Vérifier la réplication , Dans le maître (6379), exécutez

57

Zyad ELKHADIR Base de données NoSQL 57

Redis / Principe de la replication / Use Case

58

Zyad ELKHADIR Base de données NoSQL 58

Redis / Redis Cluster

- Redis Cluster permet de partitionner les données sur plusieurs nœuds (sharding) tout
en assurant la haute disponibilité.

- Contrairement à la réplication classique, il distribue automatiquement les données sur

plusieurs instances.

- Il utilise un hash slot system (16 384 slots répartis sur les nœuds du cluster).

59

Zyad ELKHADIR Base de données NoSQL 59

Redis / Redis Cluster

Quand on fait SET key "value", Redis :

• Utilise un algorithme de hashing pour déterminer où stocker la clé.
• Envoie la commande au nœud maître responsable de ce slot.
• Enregistre la donnée dans la mémoire du nœud maître, et si une réplique existe
celle-ci sera mise à jour également.

60

Zyad ELKHADIR Base de données NoSQL 60

Redis / Redis Cluster / Etapes pour Mise en Place

1) Plusieurs instances Redis doivent être configurées pour permettre une communication
entre elles. Voici la commande à utiliser pour démarrer chaque instance :

- redis-server --port <PORT> --cluster-enabled yes --cluster-config-file nodes-

<PORT>.conf --cluster-node-timeout 5000 --daemonize yes

- L'exécution de cette commande sur six ports différents (par exemple, 7000 à 7005)
permet de créer les différentes instances du cluster. Les options suivantes sont
importantes :

`--port <PORT>` : Le port sur lequel l'instance Redis écoute.

`--cluster-enabled yes` : Active le mode cluster pour cette instance.
`--cluster-config-file` : Fichier de configuration utilisé par Redis pour mémoriser
`--daemonize yes` : Permet à Redis de s'exécuter en arrière-plan.

61

Zyad ELKHADIR Base de données NoSQL 61

Redis / Redis Cluster / Etapes pour Mise en Place

2) `redis-cli --cluster create` permet de connecter toutes les instances entre elles et de
définir leur rôle dans le cluster.

- La commande à utiliser pour créer le cluster avec 6 nœuds (sur les ports 7000 à 7005) :

- redis-cli --cluster create [Link]:7000 [Link]:7001 [Link]:7002 [Link]:7003

[Link]:7004 [Link]:7005 --cluster-replicas 1

- `--cluster create` : Crée un cluster Redis avec les nœuds spécifiés.

- `--cluster-replicas 1` : Assure qu'il y aura un nœud esclave pour chaque maître dans le
cluster, offrant ainsi une redondance.

3) Pour vérifier l'état du cluster : redis-cli -p 7000 cluster info

4) Pour ajouter une donnée, utilisez la commande suivante sur un nœud :

redis-cli -p 7000 SET user:1 "Alice"
62

Zyad ELKHADIR Base de données NoSQL 62

Redis / Redis Cluster / Tester la tolérance aux pannes

1) Pour tester cette fonctionnalité, vous pouvez éteindre un nœud maître, par
exemple `7000`, en exécutant la commande :

redis-cli -p 7000 shutdown

2) Ensuite, exécutez la commande suivante pour vérifier le statut du cluster et

voir si le nœud esclave a été promu maître :

redis-cli -p 7001 cluster nodes

63

Zyad ELKHADIR Base de données NoSQL 63

 Redis / Redis Cluster Vs. Simple Réplication

Cas : Système de gestion de sessions utilisateur (Web, Mobile) 🔹 Cas : Gestion des transactions en temps réel (ex: Fintech,
🎯 Problème : Un site web à fort trafic (ex: e-commerce) gère Gaming)
des millions de sessions utilisateurs. 🎯 Problème : Une plateforme de paiement ou un jeu en ligne
🔹 Solution avec Redis Replication : gère des milliers de transactions par seconde.
Le Master gère les écritures (création, mise à jour des sessions). 🔹 Solution avec Redis Cluster :
Les Slaves répondent aux requêtes de lecture pour répartir la •Les données sont réparties entre plusieurs nœuds (sharding).
charge. •Les écritures sont distribuées entre plusieurs Masters.
Équilibrage des requêtes de lecture entre plusieurs Slaves via un •Les Slaves assurent la tolérance aux pannes en cas de
load balancer. défaillance d'un Master.
Gain : Meilleures performances sans surcharger le Master. •Gain : Scalabilité horizontale et résilience en cas de panne.
64

Zyad ELKHADIR Base de données NoSQL 64

Redis / Redis Cluster Vs. Simple Réplication

65

Zyad ELKHADIR Base de données NoSQL 65

Redis / QUIZ

66

Zyad ELKHADIR Base de données NoSQL 66

Redis / Sécurité

67

Zyad ELKHADIR Base de données NoSQL 67

Redis / Sécurité et Authentification / Activation de l’authentification

• Redis propose une authentification par mot de passe via la directive

`requirepass`.

• Cette fonctionnalité permet de définir un mot de passe que les clients

doivent fournir avant d'exécuter des commandes

• Dans le fichier de configuration `[Link]`, ajoutez ou modifiez la ligne

suivante :

requirepass votremotdepasse

• Avec Docker, vous pouvez démarrer le conteneur avec l’option suivante :

docker run --name redis-secure -d redis --requirepass votremotdepasse

68

Zyad ELKHADIR Base de données NoSQL 68

Redis / Sécurité / Limiter l'accès aux adresses IP spécifiques

• Par défaut, Redis écoute sur `[Link]`, ce qui le rend accessible

uniquement en local.
• Pour restreindre l’accès à certaines IPs, modifiez `[Link]` :

bind [Link] [Link]

• Cela autorise l’accès uniquement depuis `localhost` et `[Link]`.

69

Zyad ELKHADIR Base de données NoSQL 69

Redis / Sécurité / Contrôle d'accès (ACL)

• Depuis Redis 6.0, un mécanisme de liste de contrôle d’accès (ACL) a été

introduit pour gérer les permissions des utilisateurs.

• Redis propose plusieurs commandes ACL pour gérer les utilisateurs :

• Créer un utilisateur

ACL SETUSER monuser on > motdepasse allcommands allkeys

• Cela crée un utilisateur monuser qui :

 Est activé (on)
 Utilise motdepasse comme mot de passe
 Peut exécuter toutes les commandes (allcommands)
 Peut accéder à toutes les clés (allkeys)

70

Zyad ELKHADIR Base de données NoSQL 70

Redis / Sécurité / Contrôle d'accès (ACL)

• Limiter les commandes accessibles

ACL SETUSER limiteduser on >motdepasse +get +set -del allkeys

Cet utilisateur peut lire et écrire (+get et +set), mais ne peut pas supprimer (-del)

• Limiter l’accès aux clés

.
ACL SETUSER readuser on > motdepasse +get ~read:*

Cet utilisateur peut lire (+get) uniquement les clés commençant par read

• Tester les permissions

 Se connecter en tant qu’utilisateur : AUTH monuser motdepasse

 Vérifier les permissions d’un utilisateur : ACL LIST

 Voir les détails d’un utilisateur spécifique : ACL GETUSER monuser

 Supprimer un utilisateur : ACL DELUSER monuser 71

Zyad ELKHADIR Base de données NoSQL 71

Redis / Sécurité et Authentification / Rappel TLS

72

Zyad ELKHADIR Base de données NoSQL 72

Redis / Sécurité et Authentification / Rappel TLS / Chiffrement symétrique

73

Zyad ELKHADIR Base de données NoSQL 73

Redis / Sécurité et Authentification / Rappel TLS / Chiffrement symétrique

74

Zyad ELKHADIR Base de données NoSQL 74

Redis / Sécurité et Authentification / Rappel TLS / Chiffrement Asymétrique

75

Zyad ELKHADIR Base de données NoSQL 75

Redis / Sécurité et Authentification / Rappel TLS / Chiffrement Asymétrique

1- Alice veut envoyer un msg a bob , elle va crypter le msg avec la clef public de Monsieur M (car elle croit qu’elle
appartient a bob)
2- Monsieur M va l’intercepter et la décrypter avec sa clef privée (il sait maintenant le contenu)
3- Il va la recrypter avec la clef public de bob et il va lui envoyer
4- Pour répondre, Bob va crypter avec la clef publique de Monsieur M (car il croit qu’elle appartient a Alice)
5- De même , Monsieur M va décrypter la réponse de Bob avec sa cléf privée.

Solution :

76

Zyad ELKHADIR Base de données NoSQL 76

Redis / Sécurité et Authentification / Fonctionnement TLS

77

Zyad ELKHADIR Base de données NoSQL 77

Redis / Sécurité et Authentification / Fonctionnement TLS

78

Zyad ELKHADIR Base de données NoSQL 78

 Redis / Pub, Sub

• Le pub/sub (publish/subscribe) de Redis est utile pour mettre en place une communication en
temps réel entre différentes applications ou composants d'un système distribué.
• Il permet à des clients de s'abonner à des canaux spécifiques et de recevoir instantanément les
messages publiés sur ces canaux. Voici quelques cas d'utilisation :

• Cas d'utilisation du Pub/Sub Redis

- Notifications en temps réel 📢

Envoi de notifications instantanées aux utilisateurs (exemple : chat, alertes systèmes).

- Mise à jour de cache distribuée 🔄

Synchronisation entre plusieurs instances d'un service pour garantir que les données en cache sont toujours à jour.

- Système de messagerie instantanée 💬

Utilisé dans des applications de chat ou de collaboration pour transmettre des messages en temps réel.

- Déclenchement d'événements asynchrones ⏳

Exécution de tâches en arrière-plan lorsqu'un événement spécifique survient (exemple : traitement d'un paiement).

- Monitoring et logging 📊
Surveillance d'événements dans un système distribué en envoyant les logs en temps réel à un service de monitoring.
79

Zyad ELKHADIR Base de données NoSQL 79

 Redis / Pub, Sub

• Le Publish/Subscribe (Pub/Sub) de Redis repose sur un modèle de communication asynchrone où

des émetteurs (publishers) envoient des messages à des canaux (channels), et des récepteurs
(subscribers) reçoivent uniquement les messages des canaux auxquels ils sont abonnés.

• Mécanisme interne du Pub/Sub Redis

1) Un client s'abonne à un ou plusieurs canaux (SUBSCRIBE channel1 channel2)

2) Il écoute passivement les messages envoyés sur ces canaux.
3) Un autre client publie un message sur un canal (PUBLISH channel1 "Hello!")
4) Redis transmet immédiatement le message à tous les abonnés du canal.
5) Les abonnés reçoivent instantanément le message

Aucun stockage n'est effectué : si un client est déconnecté, il ne récupère pas les messages
manqués

💡 Alternatives :
Si vous avez besoin de persistance ou de replay des messages, il vaut mieux utiliser Redis Streams,
Kafka ou RabbitMQ.

80

Zyad ELKHADIR Base de données NoSQL 80

Redis / Pub, Sub (Exemple)

81

Zyad ELKHADIR Base de données NoSQL 81

 Redis / Pourquoi utiliser Lua avec Redis ?

• Lua (lune en portugais) est un langage de programmation léger, embarquable et performant, créé au
Brésil en 1993.

82

Zyad ELKHADIR Base de données NoSQL 82

 Redis / Lua Scripting

• Redis prend en charge l'exécution de scripts Lua via la commande EVAL, permettant d'exécuter
plusieurs opérations de manière atomique et optimisée. Lua est utilisé pour :

- Réduire les allers retours entre Redis et l'application.

- Assurer la cohérence des opérations en exécutant tout dans une seule transaction.
- Améliorer les performances en minimisant le trafic réseau.

• La commande EVAL est utilisée dans Redis pour exécuter des scripts Lua.

- <script> : le script Lua que vous voulez exécuter, <num_keys> : le nombre de clés Redis utilisé dans votre
script
- Les <key1>, <key2>, ..., <keyN> : ce sont les clés Redis que vous passez au script
- Les <arg1>, <arg2>, ..., <argM> : ce sont les arguments supplémentaires que vous passez au script Lua

• Exécution de quelques scripts :

- EVAL "return 'Hello from Lua!'" 0
- EVAL "[Link]('INCR', 'counter')" 0
- (Utilisation des Arguments) EVAL "return [Link]('SET', KEYS[1], ARGV[1])" 1 mykey "Hello Lua"

83

Zyad ELKHADIR Base de données NoSQL 83

Redis / Scripting Lua (Exemples)

• Ce script limite le nombre de requêtes qu'un utilisateur peut envoyer en un temps donné.
Par exemple, un utilisateur ne peut envoyer que 5 requêtes en 10 secondes.

84

Zyad ELKHADIR Base de données NoSQL 84

Redis / Sécurité , ACL, Scripting Lua / Quiz

85

Zyad ELKHADIR Base de données NoSQL 85

Redis / Sécurité , pub/sub , Scripting Lua : Quiz

86

Zyad ELKHADIR Base de données NoSQL 86