Introduction MongoDB
=> Base de données NO-SQL orientée Document
=> Schéma flexible
=> Ecrite en c++ et développée en 2007 par la firme MongoDB
=> Les données sont stockées sur le disque sous forme de documents BSON (Binary
JSON) : c’est un format binaire dérivé du JSON
JSON : format texte (lisible par l’être humain)
BSON : format binaire (optimisé pour la machine)
=>Supporte plusieurs types de données (tableaux,tableaux de documents....)
=> La taille maximale d’un document = 16Mo
Si on veut stocker des documents dont la taille dépasse les 16Mo, on utilise GridFS
(Grid FileSystem) : C’est un système de fichier dans MongoDB
Il va découper le fichier en petits morceaux (chunks) de taille fixe (255ko)
Chaque morceau est stocké comme un document séparé dans une collection spéciale
([Link])
MongoDB garde les métadonnées (nom,taille,type...) dans une autre collection
([Link])
Quand on veut lire le fichier, MongoDB recompose automatiquement tous les
morceaux dans le bon ordre.
Terminologie :
BD relationnelle MongoDB
Base de données Base de données
Table Collection
Ligne Document
Colonne Champ
Index index
Jointure Imbrication
Clé étrangtère Référence
Clé primaire Clé primaire (représentée par le champ
_id)
Exp :
On a la collection «users» où on va stocker les documents suivants :
{‘nom’: ‘Alan’, ‘tél’:23456543,’email’:’alan@[Link]’}
{‘nom’ : {‘prenom’:’smith’,’famille’:’Black’},’age’:25} [sous-document]
{‘nom’:’Elen’,’tél’:[21567890,23009008]}
Sharding:
*Principe :
Jusqu’ici, nous avons vu comment MongoDB stocke les données sous forme de
documents BSON dans des collections mais que se passe-t-il si notre collection
devient énorme
Exp : Un réseau social avec des milliards de messages et de posts
Un seul serveur ne suffit pas (Espace disque saturé, temps de réponse plus long,
mémoire insuffisante)
Pour gérer un très grand volume de données, MongoDB va répartir les données sur
plusieurs serveurs
=> C’est ce qu’on appelle le sharding : c’est une méthode de partitionnement
horizontal des données (pour garantir la scalabilité horizontale)
=> On va créer un sharded cluster composé de plusieurs machines (nœuds) sur
lesquelles les données vont être réparties.
Comment se fait la répartition ?
La répartition peut être effectuée d’une façon arbitraire ou bien selon un
sharding_key ou clé de partitionnement : qui est un champ présent dans tous les
documents
*Architecture du cluster :
Un sharded cluster est composé de 3 éléments :
=> Un serveur de configuration
=> Les shards (noeuds)
=> Routeur Application
Routeur
Serveur de
configuration
Shard1 Shard2 Shard3
Shard :
=>contient un sous-ensemble de données
=> S’il est saturé, il suffit d’ajouter d’autres nœuds : scalabilité horizontale
Serveur de configuration :
=>stocke les méta-donné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) [il va garantir une charge
équitable entre les shards]
Routeur :
=> C’est une instance mongos permet de router les requêtes vers le shard approprié
=> Il joue le rôle d’interface entre l’application et le cluster
=> Le routeur va communiquer avec le serveur de configuration pour connaître la
répartition des données et donc choisir le bon shard.
Atouts :
=> Load Balancing (répartition de charge)
=> Temps de réponse plus rapide (requêtes en //)
=> Ajout de serveurs sans interruption du service (scalabilité horizontale)
Inconvénients :
=> Si le serveur de configuration tombe en panne, on ne peut plus accéder à la
topologie du cluster, donc il devient inaccessible => Pas de haute disponibilité [Le
serveur de configuration est un SPOF]
=> Si un shard tombe en panne, les données qu’il contient peuvent être perdues =>
Pas de tolérance aux pannes
Solution ? => Réplica Set : C’est un mécanisme de réplication
=> Un réplica Set est un groupe d’instances mongodb (serveurs) qui contiennent le
même ensemble de données
Il comprend : => Un nœud primaire : reçoit toutes les opération d’écriture et de màj
=> Un ou plusieurs nœuds secondaires : répliquent automatiquement les
données du primaire
primaire
secondaire secondaire
*Election :
Lorsqu’un nœud primaire ne répond pas pendant environ 10 secondes, MongoDB
déclenche une élection automatique pour choisir un nœud primaire parmi les
nœuds secondaires
Ce processus est rapide (moins d’une minute), automatique et transparent aux
utilisateurs.
=> Dès qu’un secondaire est promu en primaire, l’accès en lecture/écriture est rétabli
=> Lorsque l’ancien primaire revient en ligne, il se resynchronise avec le nouveau
primaire (l’ancien primaire devient un nœud secondaire). S’il détecte qu’il possède
des écritures non validées, il effectue un rollback pour revenir à l’état cohérent du
Replica Set.
* Un réplica set peut contenir jusqu’à 50 nœuds mais seuls 7 d’entre eux peuvent
participer au vote lors des élections.
=> Pour qu’un noeud soit élu primaire, il doit obtenir une majorité de votes
Exp : dans un réplica set de 3 nœuds, la majorité est 2 votes
primaire
secondaire secondaire
On a un problème : Si 2 nœuds tombent en panne, le dernier n’a qu’un seul vote
=> il ne peut pas devenir primaire => Le réplica set passe en mode lecture seule
(les données restent accessible mais non modifiables)
Solution :
Pour éviter une situation d’élection impossible, on peut ajouter un arbitre : C’est un
nœud spécial qui :
=> Ne contient pas de données
=> consomme peu de ressources
=> ne peut pas devenir primaire
Son rôle unique : participer au vote pour aider à obtenir une majorité qualifiée lors
des élections.
Pour résumer :
Dans un réplica set, MongoDB gère tout automatiquement : Si le nœud primaire
tombe en panne (à travers les heartbeats), il déclenche une élection interne pour en
choisir un nouveau, ce processus est entièrement automatique, sans script, ni
intervention humaine => il est orchestré via des messages d’élection entre les nœuds
Pour qu’une élection réussie, une majorité de votes est nécessaire => d’où l’ajout d’un
arbitre
La nouvelle architecture :
On aura un réplica set par shard : un noeud primaire et des neouds secondaires
(on peut avoir jusqu’à 50 nœuds y compris l’arbitre + primaire )
Au niveau du serveur de configuration, on aura un réplica set de 3 nœuds : 1
primaire + 2 secondaires (sans arbitre) [3 : valeur par défaut et recommandée]