Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. MongoDB
  3. Introduction
Extrait - MongoDB Comprendre et optimiser l'exploitation de vos données (avec exercices et corrigés)
Extraits du livre
MongoDB Comprendre et optimiser l'exploitation de vos données (avec exercices et corrigés) Revenir à la page d'achat du livre

Introduction

Le Big Data et NoSQL

Voilà quelques années que le terme Big Data a fait son apparition dans le vocabulaire courant tant les données se sont imposées au cœur de nos vies ; qu’elles concernent notre dossier médical, notre compte en banque, nos achats en ligne ou bien notre activité quotidienne sur les différents réseaux sociaux, il en transite quotidiennement des volumes gigantesques à travers la planète.

Le Big Data doit répondre au défi de l’analyse et de la valorisation de ces gros volumes de données afin de les rendre utiles et, soyons honnêtes, souvent monétisables : votre parcours client sur un site marchand, les publicités ciblées pouvant déclencher un achat de votre part, les dernières vidéos que vous avez regardées afin de vous en proposer de nouvelles susceptibles de vous plaire, les mots-clés et les sujets tendance (trending topics) sur votre réseau social préféré...

Pour donner un sens à toute cette information, il faut des bases de données capables de stocker et de traiter de manière très rapide la matière première que constituent ces données brutes dont la nature est pour le moins hétéroclite (flux vidéo ou audio, texte brut, données de géolocalisation, images, etc.). À...

MongoDB

Lancée sur le marché voilà maintenant dix ans, MongoDB est une base de données dite « orientée document ». Cela signifie que l’unité n’est plus le tuple (ou la ligne) comme c’est le cas dans le modèle relationnel, mais le document. Contrairement à l’enregistrement contenu dans une table d’une base de données relationnelle, le document n’a pas une structure figée et prédictible. Deux documents peuvent très bien contenir les mêmes champs, mais dans un ordre totalement différent, ce qui est inconcevable dans le paradigme relationnel où les tables constituent des sortes de moules dans lesquels sont « coulés » les enregistrements. Dans une table contenant des informations relatives à des personnes, tous les champs doivent contenir une valeur d’un type préalablement défini (ou bien le marqueur NULL, qui indique l’absence de toute valeur) et apparaître dans le même ordre. Dans un document, un champ sans valeur peut tout simplement en être absent, là où dans une table il lui sera obligatoirement affecté le marqueur NULL. Voilà comment on oppose souvent la structure matricielle d’une table dans le paradigme relationnel à l’absence même de structure dans une base de données NoSQL....

Les composants de MongoDB

Vous pouvez déployer MongoDB sur une ou plusieurs machines en entreprise, l’installer sur votre ordinateur personnel en version standalone ou bien vous en servir sans rien installer, en utilisant des solutions déployées dans le Cloud, via les datacenters d’Amazon Web Services, de Microsoft Azure ou via Atlas, la solution DBaaS (database as a service) créée par MongoDB.

Les principaux composants de MongoDB sont :

  • mongod, le programme principal. Il gère l’accès aux données et effectue en tâche de fond des opérations de gestion de données.

  • mongos, le routeur qui gère l’acheminement des requêtes en environnement distribué. Lorsque les données sont distribuées sur des shards, c’est ce processus qui gère l’accès à celles-ci.

  • mongo, le programme d’interaction en ligne de commande avec la base de données que nous désignerons dans ces pages sous le nom de shell. L’interaction avec la base de données se fait au moyen du langage JavaScript, dont il vous faut connaître les rudiments.

À ceux-ci s’ajoutent les composants d’importation et d’exportation du BSON, format binaire dont nous parlerons bientôt :

  • mongodump va créer des fichiers contenant le BSON présent dans une base de données.

  • mongorestore...

Architecture générale de MongoDB

1. La mise à l’échelle

Lorsque l’on évoque l’architecture des bases de données, on en vient inévitablement à parler de déploiement, de taux de disponibilité, de réplication, de tolérance aux pannes, de reprise sur incident... et de mise à l’échelle (scaling). Une base de données devant servir de très nombreuses requêtes devra tôt ou tard faire face à la problématique de la mise à l’échelle ; le serveur sur lequel elle réside est très sollicité et nous allons être amenés à devoir augmenter sa capacité de stockage en mémoire RAM, nous allons ajouter des disques durs, des processeurs… Cette augmentation des performances d’un serveur par ajout de composants matériels porte le nom de mise à l’échelle verticale (vertical scaling) ; il faut se la représenter comme une pile sur laquelle on va rajouter des choses (disques, CPU...) pour illustrer cette idée de verticalité. Par opposition à cette verticalité qui atteint vite ses limites (jusqu’où peut-on aller pour gonfler les capacités d’un seul serveur ?), le concept de mise à l’échelle horizontale (horizontal scaling) s’est développé, consistant à distribuer d’énormes volumes de données sur plusieurs instances d’un gestionnaire de bases de données, hébergées chacune sur une machine dédiée. Il n’est plus question d’un serveur monolithique qui enfle jusqu’à atteindre ses limites, mais de plusieurs, dont le nombre devient virtuellement illimité, sur lesquels on répartit les données.

Ce partitionnement des données sur plusieurs instances permettant une mise à l’échelle horizontale porte le nom de sharding dans l’univers MongoDB.

2. Principe du sharding

Le sharding s’effectue au niveau d’une collection. C’est cette collection qui sera distribuée sur plusieurs shards en se basant sur un sous-ensemble des valeurs d’un champ présent dans tous les documents de cette collection et qui servira de clé (shard key). Certaines...

La notation JSON

Cette notation en langage JavaScript permet de représenter de façon simple et facilement lisible par un être humain des structures de données parfois assez complexes. L’interface en ligne de commande de MongoDB fait usage de cette notation ainsi que du langage JavaScript, il vous faut donc en maîtriser les bases.

MongoDB stocke une représentation binaire du format JSON dans un format spécialement créé par ses concepteurs : le BSON (pour binary JSON). Lorsque vous interagissez avec la base de données, MongoDB transforme le code JSON que vous lui fournissez en BSON, comme il transformera le BSON qu’il a stocké en JSON avant de vous le présenter. La taille maximale d’un document au format BSON est fixée à 16 Mo, il est cependant rare que la taille d’un document excède cette limite (à titre de comparaison, la version en texte brut du roman « Guerre et Paix » de Tolstoï pèse un tout petit peu plus de 3 mégaoctets... et le livre fait plus de 1200 pages !).

Voici comment est représenté un objet vide en JSON :

{} 

Les propriétés d’un objet JSON sont matérialisées par une ou plusieurs paires clé : valeur, séparées par une virgule :

{"clé": "valeur", "autre_clé":...

Les types de données

Les types de données pris en charge de façon native par JSON sont au nombre de six :

  • booléen

  • numérique

  • chaîne de caractères

  • tableau

  • objet

  • null (le marqueur d’absence de valeur)

À ces types prédéfinis dans JSON, MongoDB vient ajouter les siens :

  • le type Date : stocké sous la forme d’un entier signé de 8 octets représentant le nombre de secondes écoulées depuis l’époque Unix (01/01/1970 à minuit). Attention, le fuseau horaire (timezone) n’est pas stocké !

  • Le type ObjectId : stocké sur 12 octets, ce type est utilisé en interne pour garantir l’unicité des identifiants générés par la base de données, son importance est donc capitale !

  • Les types entiers NumberLong et NumberInt : par défaut, MongoDB considère tout numérique comme étant un nombre à virgule codé sur 8 octets. Ces types servent à représenter des nombres entiers signés dont la représentation interne se fait respectivement sur 8 et 4 octets.

  • Le type flottant NumberDecimal : codé sur 16 octets, ce type décimal d’une grande précision est en général privilégié pour des applications effectuant des calculs mathématiques requérant...

MongoDB en ligne de commande

1. Démarrer et arrêter MongoDB

Pour démarrer MongoDB depuis un terminal, il suffit d’exécuter mongod (ou mongod.exe si vous utilisez Microsoft Windows). Cet exécutable a de nombreuses options et nous ne verrons que les plus importantes. Sachez toutefois que vous pouvez très bien l’utiliser sans aucune option, il vous suffira d’exécuter cette commande :

mongod 

Quelques avertissements s’affichent à l’écran avec de nombreuses informations qu’il n’est pas utile d’évoquer à ce stade. Voyons quelques-unes des options de cet exécutable :

  • port sert à désigner le numéro du port sur lequel le serveur écoutera. Par défaut, la valeur de ce numéro de port est 27017. La commande que vous avez exécutée plus haut équivaut donc à :

mongod --port 27017 
  • dpath est l’option qui sert à cibler le répertoire contenant les données. De la même manière qu’une instance donnée doit cibler un numéro de port unique (si vous exécutez deux mongod, il vous faudra utiliser deux numéros de ports distincts, par exemple 27017 et 27018), elle doit aussi pointer vers un répertoire de données unique. Sous GNU/Linux, ce répertoire a pour valeur par défaut /data/db. Ce qui signifie que la toute première commande, sans aucune option, équivaut en réalité à :

mongod --port 27017 --dbpath /data/db 
  • logpath est utilisé pour rediriger toute sortie en provenance de mongod vers un fichier journal situé dans un répertoire de votre choix (prenez soin de vérifier que vous possédez les droits d’écriture dans le répertoire que vous mentionnerez). Comme ce fichier journal est écrasé à chaque démarrage de mongod, nous signifierons, en ajoutant l’option logappend, que nous voulons ajouter nos nouveaux logs aux logs existants et non les remplacer.

    Voici la commande qui permet de réaliser ceci :

 mongod --port 27017 --dbpath /data/db --logpath /tmp/mongodb.log 
--logappend 

Pour arrêter MongoDB sous GNU/Linux, plusieurs possibilités s’offrent à vous : la simple combinaison des touches Crtl+C, l’arrêt...

Gestion des collections

1. Les collations

Les collations servent à définir des règles pour la comparaison des chaînes de caractères, notamment en ce qui concerne l’accentuation des caractères ou leur casse dans un langage donné. Les collations peuvent être utilisées avec les collections, les vues ou encore les index.

Voici la forme d’un document contenant les informations liées à une collation :

{ 
  locale: < chaîne de caractères >, 
  caseLevel: < booléen >, 
  caseFirst: < chaîne de caractères >, 
  strength: < entier >, 
  numericOrdering: < booléen >, 
  alternate: < chaîne de caractères >, 
  maxVariable: < chaîne de caractères >, 
  backwards: < booléen > 
} 

Dans ce document, seul le champ locale est obligatoire ; il contient le langage utilisé, noté au format défini par l’ICU (International Components for Unicode). En ce qui concerne la langue de Molière, nous avons à notre disposition deux valeurs pour locale : fr évidemment et fr_CA pour le français utilisé par nos cousins de la belle Province.

Voyons les autres champs du document décrivant les informations de collation :

  • strength représente le niveau de comparaison qui sera effectué entre les chaînes de caractères. Ce niveau est tel que défini par l’ICU : lorsqu’il vaut 1, le niveau de comparaison est dit primaire, c’est-à-dire que la comparaison se fait uniquement en se basant sur les caractères, sans tenir compte de leur accentuation éventuelle ou de la casse (majuscule ou minuscule). Lorsque la valeur du champ strength est 2, le niveau de comparaison est dit secondaire, c’est-à-dire qu’en plus de la comparaison primaire, les accents sont désormais pris en compte. Le niveau de comparaison tertiaire est celui par défaut et, en plus des critères du niveau secondaire, il prendra en compte la casse. Il existe deux autres niveaux, mais les trois premiers restent les plus utilisés.

  • caseLevel sert lorsque le niveau de comparaison exigé dans strength est primaire ou secondaire. En effet...

Gestion des documents

1. Insérer un document

Nous avons déjà eu un aperçu de l’insertion d’un document lors de la création d’une base de données. Nous n’avions inséré qu’un seul document, mais il est évidemment possible d’en insérer plusieurs simultanément, en les plaçant dans un tableau. La syntaxe simplifiée d’insert est la suivante :

db.collection.insert(< document OU tableau de documents >) 

Reprenons le tableau de documents que nous avions constitué, lorsque nous avions abordé la structure d’un document JSON :

[ 
 {"nom": "Durand", "prenom": "Robert"}, 
 {"nom": "Dupont", "prenom": "France"} 
] 

Il s’agit bien d’un tableau d’objets, car les documents sont avant tout des objets ! Dès lors, nous pouvons nous connecter sur test et y exécuter la commande suivante :

use test; 
 
db.personnes.insert([ 
 {"nom": "Durand", "prenom": "Robert"}, 
 {"nom": "Dupont", "prenom": "France"} 
]) 
 
BulkWriteResult({ 
       "writeErrors" : [ ], 
       "writeConcernErrors" : [ ], 
       "nInserted" : 2, 
       "nUpserted" : 0, 
       "nMatched" : 0, 
       "nModified" : 0, 
       "nRemoved" : 0, 
       "upserted" : [ ] 
}) 

Que se passe-t-il exactement ici ? Nous insérons deux documents dans une collection nommée personnes qui n’existe pas ; comme l’insertion de nos documents a lieu sans erreur, personnes est créée à l’issue de l’exécution de la commande d’insertion. Nous avons réalisé ce que l’on appelle une insertion en masse (bulk insert) et nous voyons s’afficher un objet de type BulkWriteResult qui résume les actions qui viennent de s’effectuer, en l’occurrence deux insertions...

Les capped collections

Les capped collections, qu’on pourrait traduire en français par « collections plafonnées », constituent un type particulier de collection en ce qu’elles sont de taille fixe. Leur comportement est celui d’un tampon circulaire : une fois que la capacité maximale de la collection est atteinte, chaque document inséré entraînera automatiquement la suppression du plus ancien document résidant dans celle-ci.

Les capped collections préservent l’ordre d’insertion ; les requêtes ciblant des documents dans ce type particulier de collection n’ont donc pas à s’appuyer sur un index pour tenir compte de cet ordre, ce qui aura pour effet de les rendre plus rapides.

On les utilise notamment pour la gestion des logs ou bien du cache. MongoDB lui-même fait usage de ce type de collection pour son fonctionnement ; l’oplog - ou journal des opérations (operation log) - est une capped collection qui sert à assurer le bon déroulement des opérations de réplication d’une machine primaire vers des machines secondaires. Depuis la version 4 de MongoDB, l’oplog a la possibilité de croître au-delà de sa capacité maximale, ce qui en fait un cas très particulier de capped collection.

1. Création d’une collection plafonnée

La commande pour créer une capped collection est celle d’une collection normale à ceci près qu’il faudra préciser dans les options de création qu’elle est plafonnée et lui attribuer une taille en octets. Si la taille passée en paramètre est inférieure ou égale à 4 Ko, alors elle est automatiquement plafonnée à cette valeur. Par ailleurs, toute taille qui ne serait pas un multiple de 256 est arrondie à un multiple de ce nombre. Créons à...