Télécharger

TP MongoDB
MongoDB est l’une des base de données composant le mouvement NoSQL (Not Only SQL).
L’intérêt de ce genre de bases de données se ressent dans la manipulation de très grosses
bases de données où le temps de réponse compte plus que l’intégrité des données.
MongoDB est une base documentaire dans laquelle les documents sont regroupés sous
forme de collections, les collections étant l’équivalent des tables du SQL. Chaque document
dispose d’une clé unique permettant de l’identifier dans la collection.
Importation de données dans une base
Installation de Mongodb :
Importation de données dans une base avec un fichier "csv" :
-d : définit le nom de la base où l'on souhaite importer les données
-c : définit le nom de la collection que l'on souhaite remplir
--type : définit le type de fichier importé
--file : définit le chemin où se situe le fichier de données
--headerline : pour utiliser la première ligne comme un nom de champs et non comme un
document distinct (concerne les fichiers de type "csv" et "tsv")
WILLM Geoffrey & EMERY Olivier
LP aGSRi
Page 1
Ouverture du shell Mongodb :
La base de données "test" a bien été crée et n'est pas vide.
Connexion à la base de données "test" :
La collection "weather" a également bien été crée.
Vérifions que notre collection "weather" s'est remplie correctement :
Réplication de données
Afin d’assurer la redondance et la haute disponibilité, MongoDB possède une fonctionnalité
appelée "replica set" qui assure le basculement automatique et invisible des applications
clientes en cas de panne matérielle ou logicielle.
Le concept est de créer un groupe de serveur (set) qui possédera un nœud principal (master)
et n serveurs de backup (slaves). Si le nœud principal tombe, un autre nœud prendra le relai
automatiquement.
Le changement de master se fait via un système d'élection, ou chaque nœud actif du set
vote pour élire un nouveau master. Un nœud "arbitre", qui appartient au set mais ne reçoit
ou n'envoie aucune données peut être ajouté.
WILLM Geoffrey & EMERY Olivier
LP aGSRi
Page 2
L'ajout de cet arbitre est obligatoire dans le cas où le set ne comporte que 2 nœuds. En
effet, si le master tombe, il ne reste plus qu'un nœud qui votera pour lui même, il aura donc
1 voix sur 2, ce qui est insuffisant pour qu'il soit élu.
Un seul serveur est "master" et peut recevoir des lectures et des écritures, les autres sont
"slaves" et ne peuvent recevoir que des lectures.
Pour que le replica set fonctionne il faut donc au moins trois machines. Les données peuvent
être conservées uniquement sur la machine que nous allons configurer, les autres machines
doivent être vierges.
Dans le fichier de configuration /etc/mongodb.conf des trois machines, il faut ajouter ceci :
replSet = lannion
A chaque fois, on redémarre Mongodb :
/etc/init.d/mongodb restart
Ensuite, on se positionne sur la machine master et on se connecte à Mongodb.
On va configurer le replica set en indiquant le nom défini dans le fichier de configuration
auparavant et pour chaque machine, on renseigne leur adresse IP ainsi que le numéro du
port. L'élection sera automatique (ici le destin est forcé via arbiterOnly).
cfg = {
_id : "lannion",
members : [
{_id: 0, host : "192.168.0.22:27017"},
{_id: 1, host : "192.168.0.23:27018"},
{_id: 2, host : "192.168.0.21:27019", arbiterOnly : true }
]}
Maintenant, on initialise la configuration :
rs.initiate(cfg)
Après quelques secondes, on peut observer que l’invité a changé :
C’est bon la réplication est active, les données en insertions seront automatiquement
répliquées sur les autres instances. Cependant, le failover n’est pas encore en place,
l'application ne peut donc pas basculer seule d’une instance vers une autre.
Nous allons donc utiliser le sharding pour y parvenir de manière transparente.
WILLM Geoffrey & EMERY Olivier
LP aGSRi
Page 3
Partitionnement de données (sharding)
Les mécanismes de réplication sont intéressants dans la mesure où ils permettent de faire
évoluer les performances en lecture sur la base de données. Cependant avec ce système
l’écriture de données repose sur un seul serveur. Pour pallier à ce problème, il est nécessaire
d’utiliser la notion de sharding.
Concrètement, il nous faudra simplement arrêter nos trois instances et leur rajouter le
paramètre suivant permettant d’activer le sharding :
--shardsvr
Ensuite, on lance nos serveurs de configuration :
# mongod --port 27020 --configsvr --dbpath /data/configdb0
# mongod --port 27021 --configsvr --dbpath /data/configdb1
# mongod --port 27022 --configsvr --dbpath /data/configdb2
C’est ce serveur qui va stocker les informations utiles au bon fonctionnement du sharding.
On lance ensuite le routeur :
# mongos --port 27023 --configdb localhost:27020,localhost:27021,localhost:27022
Puis on se connecte sur le routeur :
$ mongo --port 27023
Enfin, on ajoute les nœud au shard :
> use test
> db.runCommand({addshard : "lannion/localhost:27017,localhost:27018,localhost:27019"})
Si l'ajout s'est effectué correctement, on obtient ce message :
{ "shardAdded" : "lannion", "ok" : 1 }
WILLM Geoffrey & EMERY Olivier
LP aGSRi
Page 4
Par défaut, le sharding n’est pas activé. On peut l’activer au niveau d’une base de donnée ou
bien au niveau d’une collection. Ici nous activons le sharding sur toute la base de données.
> db.runCommand({enablesharding: "test"})
Puis nous définissons la clef à utiliser pour le sharding :
> db.runCommand({shardcollection: "test.weather", key:{"_id":1}})
Conclusion
La mise en place du sharding et de la réplication permet de rapidement mettre en place une
infrastructure fiable. Pour augmenter la capacité de montée en charge il suffira d’ajouter
des replica set au shard. MongoDB s’occupera automatiquement de répartir le stockage des
données et l’exécution des différentes requêtes. Pour augmenter la fiabilité, on pourra
également augmenter le nombre de noeud dans chaque replica set.
WILLM Geoffrey & EMERY Olivier
LP aGSRi
Page 5