§ Limites

§ Taille max d’un document : 16Mo

§ Utilisation de l’API GridFS pour stocker des documents plus larges
que la taille autorisée
§ Champs _id
§ Création d’un index unique à la création d’une collection
§ ObjectId (12 octets) : 4 octets temps, 5 octets valeur aléatoire et 3
octets compteur commence par un valeur aléatoire, uniques et
rapides à générer

§ Spécification pour stocker les fichiers plus grands

Les fichiers sont splittés en chunks et stockés dans des différents
que 16Mo documents

§ Les fichiers sont splittés en chunks et stockés dans 255 ko

des différents documents
Document
(pdf, vidéo,
image, audio
§ Deux collections sont utilisées pour stocker : les …)
255 ko
chunks et les méta-données ([Link] et [Link]) chunk
 {
"_id" : <ObjectId>,
"length" : <num>,
"chunkSize" : <num>,
[Link] "uploadDate" :
<timestamp>, § MongoDB utilise la notion de Sharding (ou
Collection
"md5" : <hash>, horizontal scaling ou scale out) pour stocker ses
Méta- "filename" : <string>,
données "contentType" : <string>, données dans le cluster
"aliases" : <string array>,
§ Division des données et leur distribution entre plusieurs
Document "metadata" : <any>,
(pdf, vidéo, } serveurs ou shards
image, audio
…) § Chaque shard est une base indépendante, et mis
[Link] {
"_id" : <ObjectId>, ensemble, forment une seule base de données logique
Données "files_id" : <ObjectId>,
en chnuks Collection "n" : <num>,
"data" : <binary>
}

§ Query Routers
§ Instances mongos
§ Interfaçage avec les applications
§ Shards clientes
§ Stockent les données
§ Redirige les opérations vers le shard
§ Les données sont distribuées et
§ approprié et retourne le résultat au
répliquées sur les shards client
§ Plusieurs QR pour la répartition des
tâches
 § Réduction du nombre
d’opérations que chaque machine
§ Config Servers gère
§ Stockent les méta-données § Chaque machine gère les données qui
du cluster y sont stockées
§ Définissent le mapping entre
les données et les shards § Réduction de la quantité de
données que le serveur a besoin
de stocker
§ Plus le cluster grandit, moins un
serveur contient de données

§ Partitionnement des données au niveau des collections, via la shard key § Définition d’intervalles qui ne se chevauchent pas, dans lesquelles les valeurs de
§ Champ simple ou composé indexé qui existe dans chaque document de la collection
la shard key peuvent se trouver
§ Permet aux documents avec des clés proches de se trouver dans le même shard
§ MongoDB divise les valeurs de la clé en morceaux (chunks) et les
distribuent de manière équitable entre les shards § Plus facile de retrouver le shard pour une donnée
§ Risque de distribution non équitable des données
§ La répartition des clés suit l’une de ces deux méthodes de partitionnement:
§ si la clé est le temps à les requêtes dans un même intervalle de temps sont sur le même
§ Basée sur le rang serveur
§ Basée sur le Hash
§ Basée sur les tags
§ Calcul de la valeur du hash d’un champ, puis utilise ce hash pour créer des partitions § Les administrateurs peuvent définir des tags, qu’ils
§ Deux documents ayant des clés proches ont peu de chance de se trouver dans le même associent à des intervalles de clé
shard
§ Distribution aléatoire d’une collection dans le cluster, d’où une distribution plus équitable
§ Ils associent ces tags aux différents shards en essayant de
respecter la distribution équitable des données
§ Moins efficace, car le temps de recherche de la donnée est plus grand

§ Dans le cas d’une requête portant sur des données se trouvant dans un intervalle défini, le § Un balancer migre les données taggées vers les shards
système doit parcourir plusieurs shards adéquats
§ Le meilleur moyen pour assurer une bonne répartition des
donnée

§ Balancer : processus en arrière plan, gérant les migrations de § Étapes

chunks § Le shard destination reçoit tous les documents du chunk à migrer
§ Peut être lancé à partir de n’importe quel query router § Le shard destination applique tous les changements faits aux
§ Quand la distribution des données est dés-équilibrée, le balancer
données durant le processus de migration
fait migrer des chunks du shard ayant le plus de chunks vers celui § Finalement, les méta-données concernant l’emplacement du chunk
qui en a le moins, jusqu’à ce que la collection devienne sur le config server sont modifiées
équitablement répartie
 § Dans le cas d’un ajout de shard
§ Redondance
§ Un dés-équilibre est créé entre les shards du cluster, car le nouveau shard n’a
pas de chunks
§ MongoDB peut commencer le processus de migration immédiatement, mais cela § Simplification de tâches (backups, ... )
risque de prendre du temps avant que le cluster ne soit équilibré

§ Dans le cas d’une suppression de shard § Augmentation de la capacité de lecture

§ Le balancer migre tous les chunks de ce shard vers les autres shards
§ Une fois toutes les données migrées et les méta-données mises à jour, la § Un replicaSet est un cluster d'instances MongoDB.
suppression peut avoir lieu.
§ Stratégie maître / esclaves

§ Primaire
§ La réplication du maître vers les
§ Seul membre qui reçoit les opérations d’écriture
esclaves est asynchrone.
§ MongoDB applique les opérations d’écriture sur
§ Synchrone : Bloquant / Coûteux / Forte
cohérence le primaire, puis les enregistre dans son

§ Asynchrone : Non bloquant / log(oplog)

Rafraîchissement des données obligatoires. § Les membres secondaires dupliquent ce log et

appliquent les opérations sur leurs données

§ Un ReplicaSet est tolérant aux pannes.
§ Si le nœud primaire tombe, les nœuds § Tous les membres d’un ReplicatSet et peuvent

secondaires peuvent élire un nouveau nœud accepter une opération de lecture

primaire.
§ Secondaires § Élections
§ Ont lieu à la création d’un ReplicaSet, ou bien quand un primaire devient
§ Maintiennent une copie des données du primaire indisponible
§ Processus qui prend du temps, et qui rend le ReplicatSet en readonly
§ Pour répliquer les données, un secondaire applique les opérations du oplog du § Chaque membre a une priorité déterminant son éligibilité à devenir
primaire sur ses propres données, de manière asynchrone primaire

§ Un ReplicatSet peut avoir un ou plusieurs secondaires § L’élection choisit le membre ayant la plus haute priorité
comme primaire
§ Même si les clients ne peuvent pas écrire des données sur les secondaires, ils
§ Par défaut, tous les membres ont la même priorité (1)
peuvent en lire
§ Il est possible de modifier la priorité d’un membre ou groupe,
§ Un secondaire peut devenir un primaire, suite à une élection § selon leur position géographique par exemple
§ Chaque membre a la possibilité de voter pour un seul autre membre
§ Le membre recevant le plus grand nombre de votes devient primaire

§ -replSet : indique à qule ReplicaSet appartient l’instance

§ -shardsvr : active le partitionnement horizontal
§ [Link]("host:port") : Ajouter un nœud au ReplicaSet sur le serveur maître
§ [Link]("host:port") : Sortir un nœud au ReplicaSet sur le serveur maître
§ [Link](config) : initialise
§ [Link]() : vérifier qui est le Master
§ [Link]() : afficher l’etat de de ReplicaSeé
§ [Link]() : activer la lecture à partir des esclave
§ …..