Introduction

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 restrictions s’appliquent à cette clé qui servira de pivot : il ne peut exister qu’une seule shard key par collection et sa taille ne doit pas excéder 512 octets.

Elle ne pourra pas être changée une fois la collection déployée sur les shards, il faudra en extraire les documents pour les sauvegarder, supprimer la collection puis la recréer pour y réinjecter les documents sauvegardés précédemment.

Lorsqu’une collection doit être « shardée » alors qu’elle contient déjà des documents, la clé choisie doit faire l’objet d’un index simple ou bien figurer au tout début d’un index composé.

La clé de sharding idéale permet de distribuer de manière uniforme les documents, sous forme de paquets appelés chunks, sur l’ensemble des shards. Cette distribution peut se faire suivant deux stratégies : la première consiste à hacher les valeurs des clés de sharding et la seconde à diviser les données par intervalles de valeur. C’est cette dernière que nous évoquerons.

Imaginons une collection nommée eleves dans une base de données nommée personnes ; nous allons prendre le champ age contenu dans chaque document de notre collection eleves et nous en servir comme shard key, de sorte que les élèves de moins de 10 ans seront stockés sur le shard S₁, ceux dont l’âge est compris entre 10 et 13 ans sur le shard S₂ et les autres sur le shard S₃.

Pour diriger les requêtes faites sur l’âge des élèves vers le bon shard, MongoDB s’appuie sur le routeur mongos : c’est lui qui sait sur quel shard se trouvent les élèves dont l’âge est demandé par la requête.

MongoDB répartit les tâches d’écriture et de lecture parmi les différents shards constituant une grappe (cluster). Une grappe peut également faire l’objet d’une mise à l’échelle horizontale : l’ajout de nouveaux shards permettra de diminuer la charge de travail en lecture et en écriture de chacun des shards constitutifs de la grappe et d’étendre de manière significative les capacités de stockage de celle-ci.

Lorsqu’un des shards constituant une grappe est indisponible, il ne remet pas en cause la disponibilité des autres membres du cluster : si les données demandées sont disponibles sur un autre shard, elles seront servies !

Si une requête contient la clé de sharding ou bien le début d’une clé de sharding composée, elle sera routée vers le bon shard par mongos. Dans le cas contraire, elle sera émise en direction de l’ensemble des shards, ce qui pénalisera le temps de réponse.

Une base de données peut comporter des collections shardées et non shardées, les deux ne sont pas mutuellement exclusives ! Tandis que les premières seront distribuées sur plusieurs shards, les autres ne résideront que sur un seul.

3. Les replica sets

Les replica sets constituent une composante fondamentale de l’architecture de MongoDB et garantissent la haute disponibilité des données ainsi que leur redondance (c’est-à-dire le fait qu’il existe plusieurs copies des mêmes données réparties sur différents serveurs). Bien que cet ouvrage n’ait pas pour but de faire de vous des administrateurs de bases de données MongoDB, il est important que vous connaissiez le fonctionnement général de cette architecture de réplication des données, car nous l’évoquerons notamment lorsque nous aborderons les transactions.

Un replica set est constitué d’un nœud maître (dit primaire) auquel sont subordonnés plusieurs nœuds esclaves (dits secondaires) et potentiellement un nœud arbitre. Ces nœuds...

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 :

mongod --port 27017 

mongod --port 27017 --dbpath /data/db 

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 du service avec la commande sudo service mongodb stop, si vous avez installé MongoDB via un gestionnaire de paquetages, ou bien l’exécution de la commande suivante dans une nouvelle fenêtre de terminal :

mongosh --eval "db.getSiblingDB('admin').shutdownServer()" 

Même si toutes se valent, les deux dernières sont les meilleures façons d’arrêter proprement le serveur et doivent être préférées à la première façon de faire, qu’on peut toutefois utiliser lorsqu’on développe sur sa propre machine.

2. Se connecter à la base de données via le shell

MongoDB propose un outil d’interaction en ligne de commande avec la base de données : le shell. Il contient un interpréteur JavaScript complet, ce qui vous permettra notamment d’écrire de petits scripts pour manipuler les données. Une fois que mongod s’exécute en tâche de fond sur votre machine, il vous suffit de vous placer dans le répertoire stockant les fichiers exécutables et d’exécuter la commande suivante pour vous connecter à votre base de données :

mongosh 

Par défaut, vous serez connecté sur le port 27017 de la machine hôte. Pour attribuer une valeur différente au port, il faut simplement ajouter l’option port suivie du numéro de port ciblé, exactement comme vous l’avez déjà fait avec l’exécutable mongod. Si votre mongod écoute sur le port 27777, votre shell s’y connectera avec la commande :

mongosh --port 27777 

Vous pouvez également vous connecter au port de votre choix sur une machine hôte distante en utilisant l’option host :

mongosh --host mongo.monsite.fr --port 27777 

Lors de la connexion, vous voyez s’afficher trois informations importantes :

Maintenant que vous êtes connecté, vous pouvez afficher le nom des bases de données existantes grâce à ces deux commandes, qui sont équivalentes :

show databases 
 
show dbs 

Si vous avez déjà utilisé le système de gestion de bases de données relationnelles MySQL, show databases va sûrement vous rappeler des souvenirs !

Lorsque vous venez d’installer MongoDB, vous avez trois bases de données à votre disposition :

admin 
config 
local 

Ces bases de données servent à gérer les rôles et autorisations, la gestion interne de MongoDB ou des informations sur le démarrage de vos instances. À de très rares exceptions près, vous n’aurez pas l’occasion d’y faire quelque modification que ce soit, ce sont généralement les administrateurs qui y effectuent des opérations.

Pour savoir sur quelle base de données vous êtes connecté, il vous faut taper :

db 

Par défaut, vous êtes connecté sur la base de données nommée test.

Pour lister l’ensemble des collections et des vues présentes dans une base de données, la commande est identique à celle qui affiche le nom des bases de données :

show collections 

Enfin, pour changer de base de données, vous disposez de la commande use, elle aussi utilisée dans MySQL. Si l’une de vos bases de données se nomme madb, vous vous y connecterez en exécutant la commande :

use madb 

Contrairement à MySQL, vous pouvez très bien cibler avec use une base de données qui n’existe pas, aucune erreur ne se produira, elle attendra sagement que vous y créiez des collections !

Se connecter à MongoDB en utilisant le contrôle d’accès

Si vous avez eu la curiosité de regarder la sortie générée par l’exécution de mongod sans aucune option, ou bien d’aller dans le fichier journal /tmp/mongodb.log si vous avez choisi d’utiliser logpath, vous avez sans doute aperçu cet avertissement :

{"t":{"$date":"2024-02-21T10:33:13.920+01:00"},"s":"W", "c":"CONTROL", 
"id":22120, "ctx":"initandlisten","msg":"Access control is not enabled for 
the database. Read and write access to data and configuration is 
unrestricted","tags":["startupWarnings"]} 

Ceci signifie que vous n’avez actuellement aucun contrôle d’accès à votre base de données et que n’importe quel utilisateur peut s’y connecter... Ce n’est pas très rassurant, n’est-ce pas ? Qu’à cela ne tienne, nous allons y remédier de suite !

Tout d’abord, nous allons nous connecter à la base de données admin dont nous avons parlé un peu plus haut et nous allons ensuite créer un utilisateur nommé mongosensei auquel nous attribuerons deux rôles : userAdminAnyDatabase appliqué à la base de données admin et readWriteAnyDatabase qui lui permettra de lire et d’écrire dans toute base de données qui n’est ni local ni config.

Voilà la commande de création de cet utilisateur, qui nous servira dans d’autres exemples à venir, il faut d’abord se connecter...

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 :

2. Créer une collection

Vous savez maintenant que les collections se créent automatiquement lorsqu’un premier document y est inséré ou qu’un index y est créé. Il existe toutefois une méthode nommée createCollection dédiée à la création d’une collection depuis la base de données dans laquelle vous souhaitez qu’elle réside. L’utilisation de cette méthode est conseillée lorsque des options particulières doivent être utilisées à la création, comme par exemple signaler que la collection devra être de type plafonné (capped), que sa collation devra avoir une valeur précise ou bien que les documents qu’elle s’apprête à contenir devront être soumis à une validation préalable avant insertion.

Nous verrons certaines de ces options plus tard, mais pour le moment, nous nous contenterons de créer une collection sans aucune option. Pour créer une collection nommée macollection dans la base de données à laquelle vous êtes actuellement connecté, il vous suffira d’écrire :

db.createCollection("macollection") 

Si vous souhaitez faire usage d’une collation (comme fr) lors de la création de cette collection, vous pourrez le préciser comme suit :

db.createCollection("macollection", {"collation": { "locale": "fr"}}) 

Si nous nous basons sur les paramètres de collation énumérés plus haut, ceci revient à écrire :

db.createCollection("macollection", ...

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 avec insertOne, mais il est évidemment possible d’en insérer plusieurs simultanément en les plaçant dans un tableau avec insertMany. La syntaxe simplifiée d’insertOne est la suivante :

db.collection.insertOne(< document>) 

Celle d’insertMany est :

db.collection.insertMany(< tableau de document>) 

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.insertMany([ 
 {"nom": "durand", "prenom": "robert"}, 
 {"nom": "dupont", "prenom": "france"} 
]) 
 
{ 
  acknowledged: true, 
  insertedIds: { 
    '0': ObjectId("65d5cd6e5a1b646dba13e33c"), 
    '1': ObjectId("65d5cd6e5a1b646dba13e33d") 
  } 
} 

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.

La méthode insertMany gère les insertions non ordonnées : ce type d’insertion garantit que si une erreur se produit durant l’insertion de plusieurs documents, l’opération n’est pas interrompue et les documents restants sont insérés. L’insertion non ordonnée est réalisée en passant en paramètre un second document contenant le booléen false à la clé ordered, comme suit :

db.personnes.insertMany([ 
 {"nom": "durand", "prenom": "robert"}, 
 {"nom": "dupont", "prenom": "france"} 
], {"ordered": false}) 

Par défaut, l’insertion de plusieurs documents se fait avec ordered valant true. Il est conseillé de laisser ce paramètre à true pour garantir la cohérence des données et ne pas risquer l’insertion d’une partie seulement des documents souhaités.

Voyons à présent une insertion multiple qui échouera parce que deux identifiants (de type chaîne de caractères cette fois, pour changer !) ont la même valeur. Nous utilisons les options par défaut, c’est-à-dire que l’insertion se fait de manière ordonnée : le premier document est inséré, le deuxième ne le sera pas, car son identifiant est identique à celui du premier, et le troisième ne sera pas inséré car le deuxième document a provoqué l’interruption de l’opération d’insertion.

db.personnes.insertMany([{ 
     "_id": "pers1", 
     "nom": "durand", 
     "prenom": "robert" 
}, { 
     "_id": "pers1", 
     "nom": "dupont", 
     "prenom": "france" 
}, { 
     "_id": "pers2", 
     "nom": "dupont", 
     "prenom": "eric" 
}]) 

Voilà la réponse du shell, qui confirme une erreur liée à un doublon d’identifiant lors de la tentative d’insertion du deuxième document. Le document retourné vous donne la valeur du champ ayant provoqué l’interruption de l’insertion ainsi que le document « fautif » à la clé op et nInserted, le nombre total d’éléments insérés, qui vaut bien évidemment 1.

Result: BulkWriteResult { 
  result: { 
    ok: 1, 
    writeErrors: [ 
      WriteError { 
        err: { 
          index: 1, 
          code: 11000,  
          errmsg: 'E11000 duplicate key error collection:  
test.personnes index: _id_ dup key: { _id: "pers1" }', 
          errInfo: undefined, 
          op: { _id: 'pers1', nom: 'dupont', prenom: 'france' } 
        } 
      } 
    ], 
    writeConcernErrors: [], 
    insertedIds: [ 
      { index: 0, _id: 'pers1' }, 
      { index: 1, _id: 'pers1' }, 
      { index: 2, _id: 'pers2' } 
    ], 
    nInserted: 1, 
    nUpserted: 0, 
    nMatched: 0, 
    nModified: 0, 
    nRemoved: 0, 
    upserted: [] 
  } 
} 

Supprimons notre collection et tentons à présent une insertion avec ordered à false de manière à exiger une insertion non ordonnée. Cette fois-ci, le deuxième document provoque toujours une erreur, car la valeur de son identifiant reste inchangée, mais le troisième sera inséré !

db.personnes.drop() 
 
db.personnes.insertMany([{ 
     "_id": "pers1", 
     "nom": "durand", 
     "prenom": "robert" 
}, { 
     "_id": "pers1", 
     "nom": "dupont", 
     "prenom": "france" 
}, { 
     "_id": "pers2", 
     "nom": "dupont", 
     "prenom": "eric" 
}], {"ordered": false}) 

L’exécution de cette insertion provoquera le même message d’erreur que celui vu plus haut, mais nInserted vaudra cette fois 2, preuve que le dernier document a bien été inséré !

Pour n’insérer qu’un seul document, nous avons aussi à notre disposition l’instruction insertOne. Sa syntaxe est similaire à celle d’insertMany, mais simplifiée puisqu’elle ne prend qu’un document en paramètre :

db.collection.insertOne(< document >) 

Les informations qu’elle affiche diffèrent légèrement de celles que nous obtenions jusqu’à présent :

db.personnes.insertOne({"nom": "durand", "prenom":...

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 à présent une capped collection nommée coll_plafonnee en spécifiant une taille de 5 000 octets :

db.createCollection("coll_plafonnee", {"capped": true, "size": 5000}) 

La méthode isCapped, applicable à une collection, indique à l’aide d’un booléen si la collection ciblée est plafonnée ou pas. Ici, c’est bien le cas et elle renverra true :

db.coll_plafonnee.isCapped() 

En visualisant une partie des propriétés de cette collection à l’aide de la méthode db.coll_plafonnee.stats(), nous voyons que la taille a effectivement été arrondie au prochain multiple de 256, à savoir 5120 :

{ 
  ns: 'test.coll_plafonnee', 
  size: 0, 
  count: 0, 
  numOrphanDocs: 0, 
  storageSize: 4096, 
  freeStorageSize: 0, 
  capped: true, 
  max: 0, 
  maxSize: 5000, 
} 

Il est également possible de définir un nombre maximal de documents admissibles dans une capped collection à l’aide de l’option max. Attention cependant, cette option ne dispense pas d’avoir à spécifier la taille de la collection, qui reste malgré tout obligatoire. Avant même le nombre de documents qu’elle contient, c’est le fait que la taille maximale de la collection a été atteinte qui va décider de la suppression des documents les plus anciens.

Détruisons notre ancienne collection plafonnée et recréons-la en requérant explicitement un nombre maximum de 1 000 documents :

db.coll_plafonnee.drop() 
 
db.createCollection( 
   "coll_plafonnee",  
   {"capped": true, "size": 5000, "max": 1000} 
) 

Si nous affichons à nouveau les statistiques de notre collection, nous constatons que le nombre maximum de documents que nous avons requis a bien été pris en compte :

{ 
  ns: 'test.coll_plafonnee', 
  size: 0, 
  count: 0, 
  numOrphanDocs: 0, 
  storageSize: 4096, 
  freeStorageSize: 0, 
  capped: true, 
  max: 1000, 
  maxSize: 5000, 
} 

2. Particularités des capped collections

Constituant un type de collection particulier, les capped collections possèdent elles aussi un champ identifiant _id indexé par défaut.

Ce type de collection ne peut pas faire l’objet de sharding.

Une collection standard peut être convertie en capped à l’aide de la commande convertToCapped :

db.macollectionstandard.insert({"cle": "valeur"}) 
{ 
  acknowledged: true, 
  insertedIds: { '0': ObjectId("65d5e3eaf784f3fca7ee210a") } 
} 
db.runCommand({"convertToCapped": "macollectionstandard", size: 5000})  
{ ok : 1 } 

Suppression d’un document dans une capped collection

Depuis la version 5 de MongoDB, il est possible de supprimer un document contenu dans une capped collection, ce qui n’était pas le cas avant. Pour y parvenir, vous pourrez tout simplement utiliser deleteOne !

Mise à jour d’un document dans une capped collection

La mise à jour d’un document se fait de la manière la plus naturelle qui soit, avec updateOne :

db.coll_plafonnee.updateOne({"cle": "valeur"}, {$set: {"cle": 
"nouvellevaleur"}}) 

Le shell nous répond bien en disant qu’un document a été ciblé ET modifié par la requête :

{ 
  acknowledged: true, 
  insertedId: null, 
  matchedCount: 1, 
  modifiedCount: 1, 
  upsertedCount: 0 
} 

Pour que les mises à jour soient efficaces, il est recommandé d’utiliser des index sur ce type de collection afin d’éviter d’avoir à parcourir l’intégralité de la collection.

Modifier la taille d’une capped collection

Depuis la version 6 de MongoDB, il est possible de changer la taille d’une collection plafonnée au moyen de l’option cappedSize de la commande collMod. Cette taille s’exprime en octets et doit être supérieure à 0 et inférieure ou égale à...