Introduction aux Bases de Données NoSQL
Introduction
NoSQL signifie "Not Only SQL" et désigne des bases de données non
relationnelles adaptées aux besoins modernes de gestion de données.
• Origine : Popularisé en 2009 lors d’un séminaire sur les bases innovantes
n'utilisant pas exclusivement SQL.
• Objectifs : Répondre aux limites des bases relationnelles face aux données
massives, non structurées, et distribuées.
• Limites des Bases de Données Relationnelles (BDR)
• Scalabilité :
o Difficulté à évoluer horizontalement dans un environnement distribué.
o Nécessite une scalabilité verticale coûteuse.
• Point unique de défaillance : Centralisation des données sur un serveur
unique, augmentant les risques.
• Performance limitée :
o Moins efficace pour gérer des volumes massifs de données.
o Dépendance aux jointures et indices.
• Rigidité : Modèle de données fixe et contraint par un schéma prédéfini.
• Contrainte ACID : Les propriétés ACID sont difficiles à maintenir dans des
environnements distribués.
• Propriétés ACID des Bases Relationnelles
• Les Bases de Données NoSQL
• Définition : Conçues pour des applications nécessitant des volumes massifs,
une grande disponibilité et une gestion flexible des données.
• Caractéristiques :
o Architecture distribuée.
o Modèle sans schéma, flexible pour des données variées.
o Haute disponibilité grâce aux propriétés BASE (Basically Available, Soft-
state, Eventual consistency).
• Avantages :
o Tolérance aux pannes.
o Scalabilité horizontale facile.
o Adaptées aux données non structurées et aux besoins analytiques.
• Inconvénients :
o Manque de standardisation (pas de langage universel comme SQL).
o Plus de travail au niveau du code.
o Technologie encore jeune, avec des outils parfois limités.
• Théorème CAP et Propriétés BASE
• Théorème CAP : Dans un système distribué, il est impossible de garantir
simultanément :
o Cohérence (Consistency) : Tous les nœuds du système montrent les
mêmes données.
o Disponibilité (Availability) : Chaque requête reçoit une réponse, même
en cas de panne.
o Tolérance aux partitions (Partition Tolerance) : Le système continue à
fonctionner même si des partitions réseau se produisent.
• Propriétés BASE :
o Basically Available : Garantie de disponibilité même en cas de panne.
o Soft-state : L’état du système peut changer avec le temps.
o Eventual Consistency : La cohérence est atteinte après un certain
délai.
• Typologies des Bases NoSQL
1. Clé/Valeur :
o Stockage simple de paires clé-valeur.
o Avantages : Rapidité et simplicité.
o Exemples : DynamoDB, Redis.
2. Orientées Documents :
o Les documents contiennent des structures typées (JSON, XML).
o Avantages : Récupération facile de données semi-structurées.
o Exemples : MongoDB, CouchDB.
3. Orientées Colonnes :
o Ressemblent aux bases relationnelles mais avec colonnes
dynamiques.
o Avantages : Adaptées aux analyses massives et CMS.
o Exemples : Cassandra, HBase.
4. Orientées Graphes :
o Basées sur des relations entre les données sous forme de graphes.
o Avantages : Idéal pour les réseaux sociaux et moteurs de
recommandation.
o Exemples : Neo4J, OrientDB.
Comparaison NoSQL vs BDR
Conclusion
• Les bases relationnelles et NoSQL ne s'excluent pas mutuellement, mais se
complètent.
• Les BDR restent dominantes pour les transactions nécessitant une forte
cohérence (ACID).
• Les bases NoSQL sont idéales pour le Big Data, les données non structurées
et les systèmes distribués nécessitant une haute disponibilité.
• Le choix dépend des besoins spécifiques : type de données, volumes,
performances et scalabilité.
Chapitre 2 : Introduction à la Base de Données Orientée Documents MongoDB
Structure de données – document
Données avec un schéma flexible
▪ Stockées sur le disque sous forme de documents BSON
✔ Documents BSON (Binary JSON) : représentation binaire sérialisées d’un
document JSON
✔ Supporte plus de types de données que JSON (documents, tableaux, tableaux de
documents,…)
▪ Taille max d’un document : 16 Mo
Pour les documents plus volumineux, l’API GridFS divise les données en fragments
(chunks) de taille uniforme, stockés comme des documents distincts.
▪ Les documents sont organisés en collections
Exemples de documents :
Terminologie :
Modélisation - quelques règles simples
Modélisation - quelques règles simples
Ne pas oubliez d’en tenir compte
▪ Besoin de l’ensemble des données à chaque requête
Une seule collection
▪ Besoin d’avoir seulement une partie de données
Plusieurs collections et des références
▪ Exemple : les posts d’un blog et leurs commentaires
✔ 2 besoins : affichage liste des posts + affichage post avec commentaires
✔ Modélisation avec 2 collections (posts, comments)
Sharding – principe
Pour gérer de grandes quantités de données et améliorer les performances,
MongoDB utilise le sharding, une méthode de scalabilité horizontale. Le sharding
consiste à diviser les données et à les répartir sur plusieurs machines, appelées
nœuds, qui forment un cluster.
Les données peuvent être distribuées :
• Arbitrairement, ou
• En fonction d’une clé de partitionnement (sharding_key), qui est un champ
commun à tous les documents.
Cela permet d’équilibrer la charge et de gérer efficacement des bases de données
volumineuses.
Sharding – Architecture d’un cluster
▪ Un sharded cluster est composé de 3 principaux éléments :
▪ Serveur de configuration
▪ Shards (ou nœuds)
▪ Routeur
❖ Serveur de configuration :
▪ Stocke les métadonnées et les paramètres de configuration du cluster
▪ Est en charge de la localisation des données, il sait quelles données se trouvent sur
quels shards
▪ Agit comme un équilibreur de charge (load balancer)
❖ Shard (ou nœud) :
▪ Contient un sous ensemble de données
▪ S’il est saturé, il suffit d’ajouter d’autres shards => scalabilité horizontale
❖ Routeur : mongos
▪ Une instance mongos permet de router les requêtes vers le shard approprié
▪ Elle agit comme routeur
▪ Elle joue le rôle d’interface entre l’application cliente et le sharded cluster : le
routeur communique avec le serveur de configuration pour connaître la répartition
des données et donc choisir le bon shard.
Sharding – Atouts d’un cluster
Le sharding dans MongoDB présente plusieurs avantages :
• Répartition de charge (load balancing) : Les données sont distribuées sur
plusieurs machines, évitant qu’un seul serveur ne soit surchargé.
• Temps de réponse plus rapides : Les requêtes sont traitées en parallèle sur
des ensembles de données plus petits.
• Ajout de serveurs sans interruption : La capacité du cluster peut être
augmentée sans perturber le service.
Cependant, un cluster basé uniquement sur le sharding n’est pas suffisamment disponibl
Si un serveur tombe en panne, le cluster entier peut être impacté.
Pour garantir la haute disponibilité et la tolérance aux pannes, il est nécessaire d’utilis
des mécanismes supplémentaires comme la réplication (Replica Set), où chaque shard e
sauvegardé sur plusieurs nœuds. Cela assure que les données restent accessibles même e
cas de défaillance d’un serveur.
Replica set – Principe
Un Replica Set dans MongoDB est un mécanisme de réplication utilisé pour garantir
la haute disponibilité et éviter la perte de données. Voici les principes expliqués
simplement :
1. Fonctionnement d’un Replica Set :
o C’est un groupe de serveurs (instances) qui contiennent les mêmes
données.
o Il comprend un nœud primaire (pour gérer les opérations de
lecture/écriture) et plusieurs nœuds secondaires (copies de secours qui
répliquent les données du primaire).
2. Élection en cas de panne :
• Si le nœud primaire devient inactif (après 10 secondes sans réponse),
• l’un des nœuds secondaires est automatiquement élu comme nouveau nœud
primaire.
• Ce processus est rapide, automatique et transparent pour l’utilisateur (environ 1
minute).
• Si l’ancien nœud primaire revient, il synchronise ses données avec le nouveau
primaire. S’il a des données supplémentaires, il effectue un rollback pour se
mettre à jour.
3. Votes et Arbitre :
o Un Replica Set peut contenir jusqu’à 50 nœuds, mais seulement 7
peuvent voter.
o Pour élire un nouveau primaire, une majorité qualifiée de votes est
nécessaire.
o Exemple : Dans un ensemble de 3 nœuds, au moins 2 votes sont
nécessaires pour élire un primaire.
o Si la majorité n’est pas atteinte (ex. 2 nœuds tombent), les données
deviennent inaccessibles.
o Pour éviter cela, on peut ajouter un arbitre :
o Un arbitre ne contient pas de données, utilise peu de ressources et
participe uniquement aux votes pour garantir une majorité.
Le Replica Set garantit la disponibilité des données et la continuité du service en
cas de panne, grâce à un système de redondance, d’élections automatiques et
de votes sécurisés.
Architecture hautement disponible
On modifie l’architecture précédente (page 13) pour la rendre hautement disponible.
▪ Le serveur de configuration est transformé en un réplica set composé de 3
instances. Chaque shard est un réplica set formé de 2 instances et d’un arbitre.
❖ Exemple
Prenons un document Personne qui contient le nom, le prénom et l’âge d’une
personne. On choisit l’âge comme clé de sharding. MongoDB va définir
automatiquement des intervalles d’âges. Le premier shard contiendra toutes les
personnes de moins de 20 ans, le shard 2 toutes celles qui ont entre 20 et 40 ans, et
le dernier shard les personnes de plus de 40 ans. Quand un nouveau document sera
ajouté dans la base, il sera directement dirigé vers le shard qui lui correspond, ici la
personne a 32 ans, elle sera donc stockée sur le shard 2. C’est le routeur (mongos)
qui est chargé d’orienté le document.