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...

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...

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 :

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...

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 à...