Examens

Exercice 1 : 4 points

1. Donnez des explications bien brefs et claires sur les cas d'utilisations qui permettent de faire la
différenciation entre:

• La réplication

• La sauvegarde/restauration

• L'importation/exportation

Réplication : Utilisée pour assurer la haute disponibilité des données. Elle implique la création de
copies identiques des données sur plusieurs serveurs. En cas de panne d'un serveur, les autres
serveurs peuvent continuer à servir les données sans interruption. Utile pour la tolérance aux pannes
et la répartition de la charge.

Sauvegarde/Restauration : La sauvegarde est le processus de copie des données pour les préserver
en cas de corruption ou de perte. La restauration est l'acte de récupérer les données à partir de ces
sauvegardes. Utilisé pour la récupération après sinistre et la préservation à long terme des données.

Importation/Exportation : L'importation est l'ajout de données à partir d'autres sources dans

MongoDB, tandis que l'exportation consiste à extraire des données de MongoDB pour les utiliser
dans d'autres applications ou à des fins d'analyse. Utilisé pour le transfert de données entre
différents systèmes ou formats.

1. Quand est ce que les indexes des collections deviennent inutiles ? et pourquoi il faut les
supprimés dans ce cas ?

Les index deviennent inutiles dans les cas suivants :

Changement de Modèle de Données : Si le modèle de données change et que les requêtes ne

s'appuient plus sur les champs indexés.

Coût de Maintenance Élevé : Les index nécessitent de la mémoire et du temps de CPU pour leur
maintenance lors des opérations d'insertion, de mise à jour ou de suppression. Si les coûts associés
dépassent les avantages de performance, ils deviennent contre-productifs.

Peu ou Pas Utilisés : Si les index ne sont pas utilisés fréquemment par les requêtes, leur coût de
maintenance peut l'emporter sur leur utilité.

Dans ces cas, il est conseillé de supprimer les index inutiles pour économiser les ressources système
et améliorer les performances globales.

2. Donnez les étapes pour activer l'authentification sur d'une base de données en MongoDB.

Démarrez MongoDB sans contrôle d'accès :

  Lancez mongod et mongo sans options spéciales.

Créez un administrateur :

 Dans le shell MongoDB, exécutez :

use admin

db.createUser({

user: "dbAdmin",

pwd: passwordPrompt(),

roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]

})

Redémarrez MongoDB avec contrôle d'accès :

 Arrêtez mongod avec db.adminCommand({ shutdown: 1 }), puis redémarrez-le avec

mongod --auth ou en configurant security.authorization: enabled dans le fichier de
configuration.

Connectez-vous en tant qu'administrateur :

 Utilisez mongo --authenticationDatabase "admin" -u "dbAdmin" -p pour vous connecter

avec authentification.

Exercice 1: 8 points

Soit la collection restaurants qui représente cette fois tous les restaurants de l'USA et pas seulement
la ville de New York) dont les documents ont cette forme:

"address": {

"_id" : Object Id ("5£903de24682a51adb431b19"),

"building": "284",

"coord": [-73.9829239, 40.6580753],

"street": "Prospect Park West",

"zipcode": "10003"

"borough": "Brooklyn",

"cuisine": "American",

"grades": [

"score": 2 ),
( "date": ISODate ("2015-01-06700:00:002", "grade"; "A",

"score": 9 ),

( "date": ISODate ("2012-09-21T00:00:002"), "grade"; "A",

1 "date":

"score": 14 )

1,

ISODate (*2012-01-17700:00:002"), "grade": "B",

"name"; "The Movable Feast",

"restaurant d": " 40361606 "

Ensuite, soit la collection des zip code dont les documents ont cette forme :

" _id" : "10003", 4

"city" : "NEW YORK",

"loc" : / -73.989223, 40.731253 ),

"pop" : 51224,

"state" : "NY"

Suposant que notre base contient les deux collections: restaurants et zip_ code. Nous désirons
effectuer certaines commandes qui mettent le lien entre ces deux collections par jointure :

1. Ecrivez une requéte MongoDB qui permet de joindre et mettre en correspondance les documents
des deux collections à travers les champs du zipcode qui sont présents dans les deux collections.

db.restaurants.aggregate([

$lookup: {

from: "zip_code",

localField: "address.zipcode",

foreignField: "_id",

as: "zip_info"

}
 }

]);

2. Ecrivez une requête MongoDB qui permet à partir de la jointure précédentes en ajoutant des
étapes d'agrégation) pour afficher le nom du restaurant le nom de la ville à laquelle il appartient,
et le nombre des habitants de la zone zip code au quelle le restaurant appartient

db.restaurants.aggregate([

$lookup: {

from: "zip_code",

localField: "address.zipcode",

foreignField: "_id",

as: "zip_info"

},

$unwind: "$zip_info"

},

$project: {

_id: 0,

"Nom du Restaurant": "$name",

"Ville": "$zip_info.city",

"Population": "$zip_info.pop"

]);

3. Donnez la commande qui permet de calculer nombre de restaurant pour chaque ville (indication
:vous pouvez inversez la jointure pour obtenir le résultat).

db.zip_code.aggregate([

$lookup: {

from: "restaurants",
 localField: "_id",

foreignField: "address.zipcode",

as: "restaurants"

},

$unwind: "$restaurants"

},

$group: {

_id: "$city",

"Nombre de Restaurants": { $sum: 1 }

]);

4. Si vous constatez que ses requêtes prennent du temps considérable. Que faut-il faire pour
accélérer ces requétes (donnez des explications puis les commandes nécessaires)

Explication : Les requêtes lentes peuvent souvent être améliorées par l'ajout d'indexes. Les indexes
réduisent le temps de recherche des documents correspondants.

Commandes :

 Pour restaurants, indexez address.zipcode :

db.restaurants.createIndex({ "address.zipcode": 1 });

 Pour zip_code, indexez _id :

db.zip_code.createIndex({ "_id": 1 });

Ces indexes permettront d'accélérer les opérations de jointure et de recherche dans les collections.

Exercice 3 : 7 points

Nous désirons créer et configurer un replica Set: nommé RSnet composé de 7 serveurs, dont 1
primaire, 4 secondaires et 2 arbitres, Cette fois le déploiement ne se fera pas en mode simulation
LOCALES, mais sur une structure REELLE (composée de serveurs distants avec des adresses IP
différentes) suivant la schématisation suivante:

1. Les serveurs de réplicas dans ce schéma ont des numéros de ports logiques identiques. Est-ce que
cela pose un problème ? donner des explications. (1 points)

Non, cela ne pose pas de problème tant que les serveurs de réplicas sont sur des machines
distinctes avec des adresses IP différentes. Les numéros de port doivent être uniques au sein d'une
seule machine, mais peuvent être identiques sur des machines différentes. Chaque serveur dans un
ensemble de réplicas peut écouter le même port tant qu'il est hébergé sur une machine (ou
adresse IP) distincte.

2. Donner les commandes par étapes et qui permettent de configurer ce Replica Set. (3 points)

Supposons que les adresses IP des serveurs sont 192.168.1.1 (primaire), 192.168.1.2 à 192.168.1.5
(secondaires) et 192.168.1.6, 192.168.1.7 (arbitres).

Sur chaque Serveur (Primaire et Secondaires) :

mongod --replSet RSnet --port <port_number> --dbpath <data_directory> --bind_ip <server_ip>

Remplacez <port_number> par le numéro de port, <data_directory> par le répertoire de données et

<server_ip> par l'adresse IP du serveur.

Sur le Serveur Primaire :

rs.initiate({

_id: "RSnet",

members: [

{ _id: 0, host: "192.168.1.1:<port>", priority: 1 },

{ _id: 1, host: "192.168.1.2:<port>", priority: 0.6 },

{ _id: 2, host: "192.168.1.3:<port>", priority: 0.5 },

{ _id: 3, host: "192.168.1.4:<port>", priority: 0.7 },

{ _id: 4, host: "192.168.1.5:<port>", priority: 0.8 },

{ _id: 5, host: "192.168.1.6:<port>", arbiterOnly: true },

{ _id: 6, host: "192.168.1.7:<port>", arbiterOnly: true }

});

3. Que se passe-t-il lorsqu'un serveur de ce RSnet reprend son fonctionnement normal après un
crash momentanée ? (1 points)

Lorsqu'un serveur dans RSnet reprend son fonctionnement après un crash, il tente de rattraper son
retard en synchronisant les données manquantes depuis le dernier checkpoint. Si c'est un serveur
secondaire, il reprend la réplication depuis le serveur primaire ou un autre secondaire. Si le
primaire redémarre, une élection sera déclenchée pour choisir un nouveau primaire parmi les
secondaires.

4. On désir en cas de panne du serveur Primaire, que le choix du serveur secondaire qui vas prendre
la relève, dans l'ordre suivant: secondaire 4, secondaire 2, secondaire 3, secondaire1.

Configurez cet ordre de priorité dans ce replicas set. (1.5 points)

Pour configurer l'ordre de priorité, ajustez les valeurs de priority lors de l'initialisation du Replica Set :

Sur le Serveur Primaire :

Primaire> rs.reconfig({

_id: "RSnet",

members: [

{ _id: 0, host: "192.168.1.1:<port>", priority: 1 },

{ _id: 1, host: "192.168.1.2:<port>", priority: 0.6 },

{ _id: 2, host: "192.168.1.3:<port>", priority: 0.5 },

{ _id: 3, host: "192.168.1.4:<port>", priority: 0.7 },

{ _id: 4, host: "192.168.1.5:<port>", priority: 0.8 },

{ _id: 5, host: "192.168.1.6:<port>", arbiterOnly: true },

{ _id: 6, host: "192.168.1.7:<port>", arbiterOnly: true }

}, { force: true });

Les priorités sont ajustées pour que le secondaire 4 ait la plus haute priorité après le primaire, suivi
par le secondaire 2, le secondaire 3, puis le secondaire 1.

NB: Vous ne travaillez plus en simulation sur une seul machine. Dans cet exercice vous êtes supposés
travailler réellement sur plusieurs machines (identifiées par leur IP = host), pour cela faites attention
à bien indiquer le nom du serveur où chaque commande doit être exécuté.

Par exemple si la commande rs.config() est exécuté sur le serveur SECONDAIRE 2, alors indiqué le
comme ceci :

SECONDAIRE 2> rs.config();

Autre exam:

1. Dans le serveur MongoDB en retrouve toujours les deux bases de données « admin » et «local »,
qui sont instaurées par défaut et qui sont utilisées par le serveur lui-même.
Quelle est la nature des informations stockées dans chacune de ces bases ?

 "admin" : Contient des informations d'administration globale, y compris les utilisateurs et

leurs rôles.

 "local" : Stocke des données spécifiques à l'instance locale, comme l'oplog pour la
réplication.

2. Quand est ce que l'indexation d'un champ est utile, et quand est ce qu'elle n'est pas utile ? donnez
des explications.

Utile quand :

 Le champ est fréquemment utilisé dans les requêtes ou le tri.

 La collection est grande et les requêtes doivent être rapides.

Pas utile quand :

 Le champ est rarement utilisé pour les recherches.

 La collection est principalement soumise à des écritures.

 Le champ a peu de valeurs uniques (faible cardinalité).