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